开放原子开发者工作坊

在工作中使用过一些开源软件，有过一些美好的体验，也有一些不好的体验。

对于那些纯粹开源，不掺杂任何商业考量的贡献者，我感激他们的辛苦工作，但仍然希望他们的作品可以更好。
对那些借助开源社区力量，着眼商业的各种组织，我仍然感激他们的辛苦工作，也希望他们的作品可以更好。

我想澄清一件事情，那就是：

并不是因为一个软件开源，并且没有直接从我的手里获得收益，我就不能指责它的缺点和不足：

也许存在一些特别的例子，某些个人和组织，故意把开源软件的文档写的晦涩难懂，以此来逼迫客户购买技术支持服务。

当节约成本成为强大的压力，客户、开发组织需要开发者、使用者使用某些流行开的开源软件的时候，
开源软件的不足，需要各方加以重视，如此才能促进其发展。否则，就变成了以势压人了。

一个软件没有流行开时，它有再多缺点都无所谓。但是流行开来后，如果有人跟我说：
人家是开源的、免费的，你怎么不知感恩，反而挑三拣四呢。我是不赞同的。
谁知道这些开源软件背后，站着哪些力量呢？

开源软件开发者也要生存，开源软件软件背后的商业组织，也需要生存，
但是，除了用低劣文档、复杂配置逼迫用户就范之外，就真的没有其他生存之道了吗？

世上软件千千万万，为何使用者要选择这个而不是那个，都有各种理由，
我认为，长期为普通开发者所不喜的，其前景是黯淡的。

想想也很容易理解：你如果总给别人制造麻烦，还能指望别人感激你，喜欢你吗？

当然，开源软件的使用决定，有时候是客户做出，有时候是公司高层作出。
很多时候作出决定的人和实际使用的人是不同的两个群体。
但是即便如此，如果一个软件长期使用不便，配置复杂，甚至常常出错。如果出现更好的替代者，长期看结局也是可以预知的。

开源软件也应当与时俱进，在我心目中，它应当是这样的：

第一：Contributor Open

一套开源软件，可以由少数核心开发者控制，但不应当被他们所恶意把持，不过这估计很难。
因为，大多数人是自负的，不愿意放弃手中的权利。
所以，可以预计，在不久的将来，git hub 那种没有核心控制的开源方式将成为主流。

第二：Design OPen

好的开源软件，不仅仅应当是代码开放；它为何这样设计代码，它的设计意图如何，应当是有明确的说明。
有的时候，因为后来者对之前的各项参数的意义不熟悉，导致改乱了程序结构，破坏了原有参数的含义。pgpool是其中的典型。

第三：Test Open

无论哪种软件，不管它是否开源，都受到到工程规律的支配。
如果一个小的组件没有经过充分测试，那么没有人可以保证在更大范围内它会引发意想不到的问题。

打上开源标签，也不能保证它就是对的，如果出现错误，即便是很快出来补丁，也很可能改正错误的代码，由于没有充分的测试，会再次引入更多的错误。最近PostgreSQL的安全补丁事件就是这样。

所以说一套可以信赖的软件，理想情况下，应当附带一整套完整的自动测试套件和测试用例文档，

当然，还不仅仅是测试，广义上讲，在代码级别进行良好的检查，对开源软件一样十分必要。

我在这里再特别提出一点：对于内存泄漏方面的检测，是十分必要的。
应当有相关的测试套件，有测试文档专门对本软件的内存泄漏检测方案加以说明。

例如那种很多国外大型软件中，西方老程序员们很喜欢用的 strdup，
如果没有极为特殊的理由，是否应当用代码检查工具直接拒之门外？

第四：Architecture Open

现代软件的体系越来越复杂，就像软件设计应当遵循低耦合的原则一样，软件的各个组合部分应当在体系上易于分割，易于替换。让好的功能组件，不断脱颖而出，这样才能保持一个开源软件内部良性竞争，保持其旺盛的生命力。MySQL配备各种引擎算是一个例子。

第五：Documentation Open

一个软件，如果想走上与使用者或者开发者互动的良性循环，文档的质量是必须加以考虑的。一个开源软件如果对待文档如同对待代码一样上心，允许大家来共同有序地维护文档，将会使减少用户的障碍，降低门槛，使用者更多，这个软件也将更有分量。

最后回到开源软件的赚钱模式上来：

恐怕有人会问，如果开源软件本身十分优秀出色，用户用起来很容易，它怎么赚钱？

我的看法是：

如果一套软件非常重要，比如7x24小时需要维护。
无论它使用起来多么方便，恐怕公司也要找服务商来负责支持吧。

现在BSD协议方式，允许进行基于开源软件的二次开发。
用社区赚取眼球扩大签字用户基础，用高级商业版来赚钱，有是可行之道。Redhat的做法与此类似吧。

开源软件 不等于 一定是好软件，它仍然必须遵守软件工程的规律。所以它需要更加开放以获得更好的产品质量和用户体验。