开源，不仅仅只是需要把代码开放那么简单，而是怎么样用自己的代码去解决实际的需求、进行不断地迭代更新、以及构建开源项目的交流社区。根据过去一两年的开源经历，聊一聊我从开发者角度思考开源的观点以及对开源行为的一点想法。
个人开发者参与开源的开始，应该都是从玩具代码起步的，觉得自己做了个有点用的东西，就放到Github上，如果恰好被人看到，觉得有用，可能就会在自己的项目中尝试使用。如果开发者能坚持对项目进行迭代、更新，会积累起一些真正使用它到实际项目中的用户。这是个人开源项目的正常发展过程，不同于大公司内部开源的项目，项目本身在内部就已经经历了很多的迭代之后，在某个时间点开源出来，而且有大厂的背书，对项目会产生很强大的推广作用，但是个人开发者只能靠混迹相关的技术社区，靠使用的人口口相传了，传播速度和广度则比较受限。
在我看来，如果以功利的心态去看待开源是肯定做不好的（KPI项目），基本开源行为是没什么实际收益的，好好做开源要耗费的精力十分巨大，大多数项目都是靠情怀支撑的。
而且会因为项目慢慢用的人多了，对项目的功能、适用度、稳定性都有要求，可能改动了一点点代码就会对一波不同情况的用户产生影响，更新起来就不能那么随心所欲，提交之前还是要尽可能地经历一些测试流程的，是比较耗费精力的，测试的时间可能比开发的时间还要长，不过我觉得在这个阶段，开源项目才真正摆脱了只是在Github存一下代码的状态，才真正对其他的用户产生了价值。
对于开源项目而言，版本迭代的文档管理也是非常重要的，在项目能够具有基础功能之后，补充清晰的文档能够节省上手的时间，并且文档也是需要跟着项目的开发迭代来持续更新的，在项目迭代一段时间之后，可能内部实现、使用流程都出现了比较大的变化，拿着旧版说明书来操作新的项目，那肯定是会遇到很多问题的，持续更新和迭代的文档在很多开源项目中也是比较缺乏的。但是也是比较现实的原因，项目和文档的即时同步更新也是比较麻烦和耗费精力的事，我个人觉得还是靠养成良好的记录习惯。
其实有了清晰的文档，也不一定就能够起作用。不知道为什么，感觉大多数人都不喜欢看文档，有些项目中基础的概念和操作在文档中都有清晰的描述，却总是有源源不断的人直接联系作者询问，一个人的精力总归是有限的，不可能大部分精力都耗费在当客服回答一个项目的基础操作上。所以，这时候就需要考虑以什么样的方式来建立一个有相同需求的人的交流渠道，因为对于一个开源项目在不同类型的项目中使用，总有需求相同的地方，能够把一群有相似需求的人聚合起来，就能发动一群人的力量来相互帮助解决相似需求的问题。
如何构建开源项目的用户社区？首先项目是要能够经过简单的变动来解决不同的需求的，因为不同的业务中的需求也不可能是完全相同的，在业务层面也没有万能药，所以，开源项目只会够考虑通用的需求，这应该也是大多数开源项目真正应用到工程中仍需要进行裁剪和适配的原因。这也就造成了一种情况：把通用的方案改造到不同的具体需求时，总会遇到需要了解具体实现或者修改开源项目等等的问题，所以就会有很多的人会问“这个功能能实现吗？”、“能不能把xxx改成yyy吗？”，对于动手能力比较强的开发者来说，既然是开源的，上手翻一遍代码就可以了解的七七八八，但是有些人可能迫于业务时间压力想要找现成的方案，这就需要有一群相似需求的开发者来给出建议了，这也是开源项目技术社区的意义吧。
这样也能够让作者来节省出更多的时间，因为开源作者主业也是要工作的，对项目功能和文档的更新基本都是抽出休息时间来做的，如果再做“技术客服”的工作，相比实现功能会花费更多的时间，所以最好的结果是把有相同需求的人都聚合起来，能够在社区内进行项目和相关技术的交流，这样才是良性可持续的。
其实开源项目，绝大多数情况下都是不能得到真实的物质奖励。但是我觉得，自己做出来的东西能够解决别人的需求，能够真的产生价值，就是非常exciting的事情了，完全不功利化地来看待开源这个事情，才是真正回归了技术共享本身吧。
我认为开源带来的满足感有两部分：一是能够解决别人的需求，二是能够获取到认可。从而能够觉得自己的工作对别人产生了价值，这两点是激励做开源的主要动力。而且在我看来，技术是一定要共享的，共享才能促进整体的进步。其实回顾CS的发展历史，那些伟大的黑客都无私地奉献了自己的聪明才智，才造就了当今的计算机时代。我也愿在一个开发者力所能及的范围内，尽力地做技术共享的事情。
人生有涯而知无涯，以有涯而随无涯如何不殆己，需要共享精神！
