对于开放源码软件协同开发原理的经典论述来自开源社区之一的Eric Redmond的《大教堂与市集》一文，在该文中作者形象地将传统的严格管理的软件开发活动比喻为构筑大教堂的行为，而将分布于Internet之上的开放源码社区的协同开发活动则看作是市集行为，作者根据亲身经历系统地论述了市集型开发的基本方法和哲学问题，阐释了开放源码社区成功的内在原因，对于传统软件开发不无借鉴之处，比如“早发布、常发布、听取用户的建议”、“把用户当做协作开发者和Beta测试人员”、“聪明的数据结构和笨拙的代码要比相反的搭配工作的更好”、“好的设计不是再也没有什么东西可以添加了，而是再也没有什么东西可以去掉”、“好程序员知道该写什么，伟大的程序员知道该重写（和重用）什么”等等。

　　目前，人们对于基于开放源码的Internet协同开发实践还缺乏深入研究和理解，但是已经得到越来越多的软件工程人士的关注，并取得一定的研究成果。一个软件工程研究小组在过去5年中深入研究了几个大型的开放源码系统的体系结构和进化过程，包括Linux、GCC、VIM、Mozilla和Apache，发现他们与类似的商业系统之间表现出令人感兴趣的不同之处，比如，开放源码软件的体系结构通常是可浏览的以允许开发人员进行交互，对于那些可能阻碍程序理解（因为程序员通常是分布在Internet上各个角落互相独立的工作）的体系结构部分进行特殊声明；从同类的开放源码软件如Web服务器中可以提取其共性的参考体系结构，而在商业软件公司中却难以通过Web服务器体系结构获得几种不同的实现；开放源码软件的体系结构和开发模式是导致其超线性增长的主要因素，并且被尽可能设计的易于移植，其发行版通常不是针对特定平台，而是将各种平台的共性抽象到一个发行版中，通过配置工具来帮助构建系统。

　　另外，针对如何借鉴开放源码项目的经验用于指导商业软件项目也有相关研究成果，该项研究表明，尽管完全利用开放源码开发模式来代替传统商业软件开发模式目前看来还不太可能，但无疑可以相互借鉴经验教训而获得收益。研究人员认为，一些可供商业软件项目借鉴的开源项目经验包括：

　　人员组织——开源项目通常由很少的核心成员完成多数开发和升级任务，这一点与商业软件开发类似，但差别在于这些任务是如何在核心小组内分配的。开源项目通常是自发形成，职责的分配是基于对开发人员如何看待他们在项目中的角色的推理而确定，并不是硬性指派产生，这一点无疑对于商业软件的管理具有借鉴意义。

　　非正式交流——在Internet协同开发活动中非正式交流对于项目成员间的协调极其重要，邮件列表、论坛等是常用工具，无论开发人员在文化、地域和时区方面是否存在差异。商业软件应借鉴这种做法，而不必拘泥于严格的、形式化的交流渠道。

　　增强的用户支持——许多用户都同意这种观点，即多数商业软件公司在进入售后支持阶段时可能面临悲惨的失败命运。而开源项目的用户支持工作却有良好成绩，因为大量的用户愿意提供关于开源产品的反馈信息。因此，商业软件项目应增强用户之间、用户与开发者之间的交互，从而获得改进的售后支持以及更有意义的错误报告。

　　显然，随着人们对于基于开放源码的Internet协同开发模式的不断研究和深入理解，必将对未来的软件工程实践产生极其深远的影响。以下按照传统软件工程领域的常规做法，对于开放源码软件的协同开发活动总结出所谓“佳实践”，以增进读者的感性认识：

（一）技术交流

　　软件开发人员需要花费大量时间用于相互之间的通讯交流，清晰和高效的技术交流对于维持团队间的同步和允许掌握关键知识的个人在需要时利用其知识都是必需的。开放源码社区的一个基本原则是技术交流应当在公共论坛中进行，邮件列表是开放源码交流的基石。不仅如此，开放源码项目需要在精确交流技术细节和小组决策方面得到支持

（二）版本控制、文档管理和发行

　　任何软件开发项目都需要版本控制，开放源码项目在这方面更是需要强大灵活的支持，以使得许多并行的开发人员可以同时工作在相互重叠的文件集上。开放源码项目也需要设计文档、技术文档和用户文档方面的标准模板，并需要一个良好组织的Web站点来发行这些文档。但是，开放源码项目的本质要求这些文件可供全世界访问，同时日常管理成本则被小化，维护工作被分配给整个开发社区中的成员。