良好的软件是通过优秀的软件开发人员开发的。它涉及到大多数程序员没有找到一门学科。严格的版本和配置管理，样式和审查清单，“书桌”检查之前提交评论，自动化（连续）建立，并完全自动化测试框架是成功的所有必要步骤，可靠地提供可执行的软件作品。而最重要的，当软件出现故障，你确切地知道你是如何从什么来源和工具链（和令人信服的工具链的什么版本）使用的配方是什么版本创建的，所以你可以可靠地重建故障并修复它和测试环境。大开发商可能是巨大的建筑师，但每一个伟大的开发者是一个很好的纪律开发商第一，他们真不知道怎么否则构建软件。软件工程学科是良好的软件基础。每一个伟大的软件产品和成功的项目有近维护的必要的软件建设学科水平上至少一个开发商。而且，由于文化来自任何组织的最高层，它通过文化的提交落下下来。我已经跨越〜25年中，我大约是软件开发项目（IT）和产品（ISV）总是有该组织的至少10％，有时甚至高达30％，是这样的开发人员足够幸运。该团队的其他成员有一个简单的时间在顶部设置由少数人贡献适当，因为文化。 We all know what needs to be done — just few of us do it. (I don't do it easily — I had to work bloody hard even to attempt the discipline, literally dragging myself through a check list.) So what does this have to do with free and open source software? While I have no proof that the statistics are linked, I find it interesting that the general statistics around failed IT projects (~80% are never deployed) and moribund projects on forges like SourceForge (~90%) are very close. I have encountered the rare and the few disciplined software developers in many places — corp IT, product teams, FOSS projects. But most developers I know aren't like those disciplined developers. Without such discipline at the top, I believe no project can succeed regardless of whether it's ISV, academic, IT, or government, and whether open or closed. Said another way, only a strong disciplined developer culture can lead to a successful project, FOSS or otherwise. So lets link this idea of disciplined software construction to a collaborative community. Everyone seems to agree with O'Reilly's observations that one needs an参与“架构”成功打造充满活力的社区。这适用于任何社会，而不是简单的开源项目。我认为，如果没有在软件建设学科的基本接地，你不能建立这样通过社区介入的架构。这里的原因。每个项目社会需要为更广阔的天地涉足该项目使得社区的增长一个简单的方法：需要有坡道是一个。我们的目标是让任何旧陌生人与你建立什么订婚足以成为激情足够贡献的兴趣。如何使这个简单的是：
- 标记的源抽点，你在任何时候都可以做必须建立。
- 有一个简单的脚本/工具/ Makefile文件/是构建来源配方。
- 有一个测试环境(无论多么简单)至少可以确认构建在已知环境中工作。
在这一历史时刻，说陌生人已经能够下载并生成项目，然后以一般确认他们建什么“运行”。我的工作是转子团队在微软在2003年我们发布了一个万行代码在代表通过.NET CLR符合ECMA标准CLI工作切一个共享源代码项目。它平凡建，并有一个测试工具，该平凡的证明，什么是建立在Windows XP，Mac OSX版，和FreeBSD的工作。该只有随软件一起发布的文档只有几页，告诉您设置环境的脚本、构建命令、测试命令，以及关于如何组织源树的简短讨论。在24小时内，我们收到了对大约20行代码的第一次有效增强，它使JIT性能提高了10%。在接下来的24小时内，我们收到了我们的第一个格式良好的错误报告，正确地修复它的代码，以及演示修复的测试用例。我们让参与变得非常简单。可能感兴趣的陌生人可以专注于做一些他们感兴趣的事情，而不是费力地创建有用的东西。浪费潜在贡献者的时间不会给他们留下好的第一印象，而且在这个时间至上的世界里，你可能会永远失去他们。优秀的开发人员可能不想把时间浪费在连基本的东西都做不好的项目上。认为你在淘汰那些“不懂”的人会浪费巨大的潜力。现在我们进入下一步。
- 对于代码需要如何格式化，有一个已发布的指导原则。
- 有什么最小的酒吧需要传递的贡献已发布指南（例如格式化，问题记录，测试工具通过干净利落，也许新的测试用例）
- 如何投稿已发布。(什么是一个好的bug报告，如何提交，等等)
如果没有这些指导，现有的项目提交者本质上是在浪费时间在糟糕的提交上，并且一遍又一遍地回答同样的问题，不管他们使用什么实际的通信工具(例如IRC，电子邮件分发，等等)。甚至建立一个FAQ来回答这些应该由自动化脚本处理的基本问题也是浪费时间。最后。
- 告诉人们什么贡献。
一些潜在的社区成员将简单地想用这个项目为自己的研究/学习。大！出这样的实验，新的创新和方向就会出现，并希望如果第一六个步骤的存在，即使它只生活在一个侧枝或边树工作将贡献。一些潜在的社区成员将要使用的项目为自己的日常工作，并给他们的能力，手背bug报告和修复或扩展是项目的质量和功能如何改进。有些人关心，并希望使用该项目在日常生活中，也希望积极贡献，在这里你想给他们一些方向，不知道该做什么。是否有一个未来的功能列表？路线错误列表？您会偏好反映代码的翻译贡献？（做的项目选择合理的策略，让人们对信息的添加新的“语言包”等你发表关于如何添加一个语言简单的指令？）你需要更好的图标？有没有如何 - 列表到文档，你会喜欢呢？（你发布的模板或可用意见？说明）如果没有软件建设学科交付前三个步骤，你将无法提供接下来的三个步骤或者更确切地说 they won't work well and will consume more resource than the value they bring. If you don't get those steps in place, the last step becomes a waste of time. For me, looking back, if you don't get the simple developer discipline in place for steps 1-3, then the software project (FOSS, IT, academic, government or otherwise) is doomed to failure because it will rapidly degenerate into an unsustainable mess, completely incapable of supporting growth in the contributors and potential committers, and ultimately unable to sustain a growing number of users. It will always be "that toy/experiment in the corner" for which commercial products will always appear to do a better job. You see this level of construction discipline in successful FOSS projects. As the Apache project grew and evolved into the Apache Software Foundation, it has published a rigorous development methodology. So too with the evolution of the Eclipse Project into the Eclipse Foundation. The Linux kernel project would never have become what it is without the discipline at it’s core. This to me is the critical problem. There are lots of cool problems to solve on the planet. Without passion, however, you won't solve them. When you find someone with passion, even if that passion is only for getting their unique personal job done with the FOSS project in front of them, you have to make it so trivially easy to contribute that they're already hooked before they even realize it. Without developer discipline at the core, that on ramp won’t exist. The interested don't get to discover they're passionate. Culture comes from the top, even in a meritocracy.