良好的软件是通过优秀的软件开发人员开发的。它涉及到大多数程序员没有找到一门学科。严格的版本和配置管理，样式和审查清单，“书桌”检查之前提交评论，自动化（连续）建立，并完全自动化测试框架是成功的所有必要步骤，可靠地提供可执行的软件作品。而最重要的，当软件出现故障，你确切地知道你是如何从什么来源和工具链（和令人信服的工具链的什么版本）使用的配方是什么版本创建的，所以你可以可靠地重建故障并修复它和测试环境。大开发商可能是巨大的建筑师，但每一个伟大的开发者是一个很好的纪律开发商第一，他们真不知道怎么否则构建软件。软件工程学科是良好的软件基础。每一个伟大的软件产品和成功的项目有近维护的必要的软件建设学科水平上至少一个开发商。而且，由于文化来自任何组织的最高层，它通过文化的提交落下下来。我已经跨越〜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％第一义增强。在我们收到我们的第一个结构良好的bug报告在接下来的24小时内，代码正常修复它，和测试案例来证明此修复程序。我们做了相当轻松参与。这可能有兴趣可以集中精力做一些有趣的事情给他们，而不是努力地去打造什么有用的陌生人。浪费了潜在的贡献者的时间不会使一个良好的第一印象，在一个世界里，时间是非常宝贵的，你可能会失去他们在挫折中为好。优秀的开发人员可能不希望在项目甚至不能正确的基本浪费时间。思考你是淘汰人认为“不能弄清楚”浪费巨大的潜力。现在，我们进入下一个步骤。
- 有关于如何格式化代码需要公布的指导方针。
- 有什么最小的酒吧需要传递的贡献已发布指南（例如格式化，问题记录，测试工具通过干净利落，也许新的测试用例）
- 如何推动出版。（是什么让一个好的bug报告，如何提交等）
如果没有这个集合指导，现有项目的提交基本上是问浪费时间与提交差，他们制定任何物理通讯科工具（如IRC，电子邮件分发等）回答同样的问题一遍又一遍。甚至建立了一个常见问题回答这个问题应该由一个自动化的脚本来处理这些基本的东西是浪费时间。最后。
- 告诉人们应该贡献什么。
一些潜在的社区成员只是想把这个项目用于他们自己的研究/学习。太棒了!在这样的实验中，新的创新和方向将会出现，并且如果前六个步骤存在，即使工作只存在于边分支或边树中，也有希望做出贡献。一些潜在的社区成员希望将项目用于他们自己的日常工作，而给予他们提交错误报告、修复或扩展的能力，就是提高项目质量和功能的方式。有些人关心并希望在日常生活中使用这个项目，但也希望积极地做出贡献，这里您想给他们一些指导，告诉他们该怎么做。有未来的特性列表吗?bug列表的方向?您喜欢反映代码翻译的贡献吗?项目是否选择了合理的策略来允许人们添加新的消息“语言包”等等。你发布了如何添加语言的简单说明了吗?) Do you need better icons? Is there a list of how-to docs you would love to have? (Did you publish the instructions for templates or useable submissions?) If you don't have the software construction discipline to deliver the first three steps, you will be unable to deliver the next three steps or rather 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.