开源软件的未来

自己一直在做开源方面的工作，包括源代码的搜集整理。同时也看过不少源代码。不过当前开源界的代码大部分处于无注释或少注释状态，有的代码只有license是注释.....如果是少数几个人开发，大家都相互认识，只不过是借用了开源这个壳来完成自己的事情的话，无注释也没有什么大不了的。开源的代码的很多，不过成功的太少。也有很多代码写得很烂，也少人问津。

开源项目的类型大概有四种，可能总结的不是很全面。1，已经有相关功能的实现，但是没有开源。2我或者周围的人知道某种需求并没有人实现。3为完成推广活动，而开源。4，just for fun.

开源项目是否要依照经典的软件过程来走？答案是不确定。很少有开源软件有自己的蓝图，连linux都没有！也就是说开源软件大部分时间处于无设计阶段。因为没有明确的需求，也就没有明确的设计。大部分需求是几个核心组织者拍拍脑袋得到的idea以及以前版本中得到的用户反馈。

那么今后的开源应该做成什么样子呢？我个人认为第一至少API化。读源码然后做逆向工程，然后再更改少量代码，除了用来骗钱，增强个人能力外，对真正意义上的快速开发作用并不大。如果有编程API可用，为何不直接调用，还要读大量的相关源码呢？公司会傻到先让程序员看linux核心代码再编c程吗？第二要有软件蓝图。此开源软件的未来究竟是什么样子的，应该明确一下。有啥功能不再升级应该说一下。否则使用了某个功能模块，结果下个版本说因为含有系统漏洞而不再支持。那借助此开源软件的开发者就疯了。第三相关功能的融合。A开源软件有下载模块，B开源软有下载模块,C....,为啥不整合到一起，形成API呢？当然会有人说因为使用不同，下载方式及流程可能有不同。但是我想一个gcc有约上百个参数供人调用，一个下载模块提供几十个参数应该也就够用了。分散力量做某事，往往做得不好。第四，当前软件的框架结构、文档和注释应该整齐。开发者往往不屑于文档，这是通病。“代码就是文档”这只对开发此代码的人适用。另外某些公司把自己的代码开源了，结果代码里只有license是注释。我觉得这些代码还不如用混淆器混淆一下然后再宣布自己支持开源来得痛快。我个人认为开源应该是为别人提供方便，而不仅仅为了做个代码的网上备份。不过当前为了宣传和推广开源，这些同学的做法还是欢迎的。但是这样的做法肯定不是推崇的。第五，开源项目应该有专门的培训人员。现在大部分项目都宣称来IRC上问问题吧，大家都会解答。这其实是一种责任分散的做法。心理学上讲当责任分散到每个人身上，那每个人也就没有责任了。例如大家都围观落水者或者急需救助的人，而不提供援手。所以我建议开源项目应有专人培训新人。

回顾自己的文章，好像是对开源软件的建议，并没有和题目所写的开源软件的未来相联系。我个人能力有限，的确很难预测未来。未来还是靠我们共同创造吧。:)

欢迎开源人士评阅。但言辞不要激进，smile again:)