凡事成功，必有其道理。
开源软件项目的一些实践，拿到组织内部来用，也会改善组织的软件开发过程。比如代码共享、及时交流以及必要的文档。
1. 代码共享
开源项目的代码，甚至是与开发有关的一切东西都是开放下载的。这既可以方便下载使用，也方便对其进行修补完善。
在一个组织的内部，代码以及与其开发相关的东西也应该是共享的。这样既可以方便不同的项目组下载使用，方便相关方定位软件问题，也方便软件的完善。特别是共用组件。
一些组织由于保密的原因，把共享代码设置了诸多权限，在一定程度上阻碍了代码共享使用。组织的领导者应当思考一下这种做法的利与弊。
2. 及时交流
开源项目提供了一个对软件项目进行讨论的途径。使用者和开发者可以自由地对软件的需求和问题进行讨论。
一个组织也应该建立这样交流的平台——开发者之间可以讨论软件设计与实现的问题，开发者与用户之间可以讨论需求。如果没有这样一个平台，当一个开发者遇到问题的时候，只能找人面谈或者电话讨论，会非常的不方便——你可能会因为对方正在忙碌当中而吃到闭门羹。而有了这个平台，当你提出了问题，那么只要对方有时间，就可以回复你了。
3. 必要文档
真正成功的开源项目通常有三个层次截然不同的文档。第一个是README：项目是干什么的，谁参与了项目。第二个层次是如何使用：如何安装，运行时的依赖是什么样的。文档中不会事无巨细什么都记，而是会说：“通常可以按下列方式入手使用。”第三个层次是贡献者信息：人们应该如何自己构建新版本的软件，需要哪些依赖，如何做贡献等。注意这符合社区中三种完全不同的人：用户、项目贡献者、代码提交者。README帮人们决定是否要成为用户，安装信息帮人们成为用户，而贡献者信息可以让一个用户成为贡献者。
对于组织内部的软件其实也是需要这些文档的。
对于Readme文档来说，有了这个文档，内部用户就会知道这个软件是谁开发的，谁测试的，那么当他遇到问题的时候，就知道直接去找谁问，就不用去找部门领导、项目负责人这样一层一层地问过来。
对于使用文档，尽管是必须的文档——特别是具备GJB5000A资质的组织更有TS过程域的专用实践要求，但是，实际上这一文档并没有得到很好地应用。一方面，即便已经有了这个文档，内部用户也不看，他会把开发人员叫过去操作软件；另一方面，这些文档写的内容也不完善，比如运行时的依赖就没有写清楚，以至于提交测评的时候还会发生软件运行不起来的情况。所以，组织应当改善使用文档的编写和应用。
对于贡献者信息这类文档，是给开发者看的。如果组织想要发展软件重用的能力，这类文档也是必不可少的。
总之，我们可以从开源项目中学习到一些优秀实践，帮助组织改善软件开发过程。
这正是：
开源项目有所长，内部开发有榜样
优秀实践多应用，开发过程得改良
参考文献：程序之美系列：团队之美、项目管理之美，Andrew Stellman,Jennifer Greene,Scott Berkun，机械工业出版社
联系客服
