Ten Rules for Open Source Success
《开源项目成功的十条准则》
Everyone wants it, lots of people try it, yet doing it is mostly painful and irritating. I’m speaking about free software aka open source. Today I’m going to summarize 30 years of coding experience in ten management-proof bullet points.
每个人都想去做，也有很多人跃跃欲试，但是真做起来却常常会令人痛苦和愤怒——我说的是自由软件，或者更宽泛一些的开源软件。今天我要将自己30年来的开发经验，总结为开源软件的十条成功法则。
1、People Before Code
1、人比代码重要
This is the Golden Rule, taught to me by Isabel Drost-Fromm. Build community, not software. Without community your code will solve the wrong problems. It will be abandoned, ignored, and will die. Collect people and give them space to work together. Give them good challenges. Stop writing code yourself.
这是一条黄金法则，是Isabel Drost-Fromm【注1】教给我的。我们要建立的是社区而不是软件。没有社区，你的代码就会用来解决错误的问题。然后这些代码会被抛弃、忽略，最后死去。正确的做法是把人集结起来，给他们协同工作的空间，给他们充分的挑战。切记不要亲手来写代码！
注1：Isabel Drost-Fromm是Apache软件基金会的成员，Apache Mahout的创立者之一。
2、Use a Share-Alike License
2、使用“以相同方式共享”的许可证
Share-alike is the seat belt of open source. You can boast about how you don’t need it, until you have a bad accident. Then you will either find your face smeared on the wall, or have light bruising. Don’t become a smear. Use share-alike. If GPL/LGPL is too political for you, use MPLv2.
“以相同方式共享”是开源的安全带。在遇到严重的事故之前，你大可吹嘘自己完全不需要它。一旦出现事故，你就会发现自己满脸污垢，或者‘轻微擦伤’，不要成为一个“伤员”。使用“以相同方式共享”的许可证吧，如果你觉得GPL/LGPL太过于政治化，那就用MPLv2。
3、Use an Zero-Consensus Process
3、使用一个无需达成共识的协作流程
Seeking upfront consensus is like waiting for the ideal life partner. It is kind of crazy. Github killed upfront consensus with their fork/pull-request flow, so you’ve no excuse in 2015. Accept patches like Wikipedia accepts edits. Merge first, fix later, and discuss out of band. Do all work on master. Don’t make people wait. You’ll get consensus, after the fact.
寻求事前的共识就像是在等待理想的人生伴侣，这简直就是疯狂。借助fork/pull-request这种模式，Github已经干掉了事前共识，所以在2015年的今天你没有任何借口坚持事前共识。你应当像维基百科那样接受修改。先合并，再修复，同时单独讨论。所有工作应当在master分支上进行，不应当让大家等待。有了既成事实，共识会随之而来。
4、Problem, then Solution
4、首先是问题，然后才是解决方案
Educate yourself and others to focus on problems not features. Every patch must be a minimal solution to a solid problem. Embrace experiments and wild ideas. Help people to not blow up the lab. Collect good solutions and throw away the bad ones. Embrace failure, at all levels. It is a necessary part of the learning process.
教育自己和其他人，聚焦于问题而非功能特性。每一个补丁都必须是解决某个实际问题的最小化的解决方案。勇于尝试，勇于接受疯狂的想法。你还需要帮助他人，确保他们干的事情不会导致实验室的爆炸。收集好的解决方案，抛弃那些糟糕的方案。在各个层面上都应当宽容失败。这是学习过程中不可缺少的一部分。
5、Contracts Before Internals
5、首先约定，然后再完成内部实现
Be aggressive about documenting contracts (APIs and protocols) and testing them. Use CI testing on all public contracts. Code coverage is irrelevant. Code documentation is irrelevant. All that matters is what contracts the code implements, and how well it does that.
要积极地记录约定（API与协议）并加以测试。要使用持续集成工具测试所有的公开约定。代码覆盖率是无关紧要的，代码文档也是无关紧要的。真正重要的是代码实现了哪些约定，以及它们是如何实现的。
6、Promote From Within
6、从内部提拔
Promote contributors to maintainers, and maintainers to owners. Do this smoothly, easily, and without fear. Keep final authority to ban bad actors. Encourage people to start their own projects, especially to build on, or compete, with existing projects. Remove power from people who are not earning it on a daily basis.
将贡献者提拔为维护者，将维护者提拔为负责人。以流畅、轻松且无畏地方式来做。保留干掉‘害群之马’的最终权力。鼓励大家开始自己的项目，尤其是基于已有项目，或者与已有项目竞争的项目。每天持之以恒地检视并剥夺那些不再贡献者的权力。
7、Write Down the Rules
7、将规则写下来
As you develop your rules, write them down so people can learn them. Actually, don’t even bother. Just use the C4.1 rules we already designed for ZeroMQ, and simplify them if you want to.
当你制定规则时，请将他们写下来，以便人们可以了解他们。事实上，你甚至都不需要亲自动手——如果你愿意，可以直接套用我们为ZeroMQ制定的规则C4.1，再按需简化。
8、Enforce the Rules Fairly
8、公平地执行规则
Use your power to enforce rules, not bully others into your “vision” of the project’s direction. Above all, obey the rules yourself. Nothing is worse than a clique of maintainers who act special while blocking patches because “they don’t like them.” OK, that’s exaggeration. Many things are much worse. Still, the clique thing will harm a project.
用你的权力去执行规则，但不要强迫别人认同你对于项目发展方向的“愿景”。最要紧的是，你自己必须遵守规则。最糟糕的事情莫过于维护者自己形成了小圈子，仅仅因为“不喜欢”就拒绝其他人的补丁。好吧，这样说有点夸张了。不过，很多情况其实更加糟糕。还是那句话，小圈子对项目是有害的。
9、Aim For the Cloud
9、以“云”为目标
Aim for a cloud of small, independent, self-organizing, competing projects. Be intolerant of large projects. By “large” I mean a project that has more than 2-3 core minds working on it. Don’t use fancy dependencies like submodules. Let people pick and choose the projects they want to put together. It’s economics 101.
以小型的、独立的、自组织的、竞争性的（一群可以自由协作的）项目为目标，（市场）不能容忍大项目。所谓“大”，我的意思是一个项目包含了2~3个核心想法。要拒绝子模组那样花哨的依赖关系。让大家去挑选，并将他们选择的项目放到一起（工作）。这是经济学的常识。
10、Be Happy and Pleasant
10、开心愉快最重要
Maybe you noticed that “be innovative” isn’t anywhere on my list. It’s probably point 11 or 12. Anyhow, cultivate a positive and pleasant mood in your community. There are no stupid questions. There are no stupid people. There are a few bad actors, who mostly stay away when the rules are clear. And everyone else is valuable and welcome like a guest who has traveled far to see us.
也许你注意到了，“创新”并不在我的建议列表中。它很可能排在第11或12点。总之，你需要在你的社区里培养一种积极的、愉快的氛围。愚蠢的问题，愚蠢的人都应当被踢出去。就算有“老鼠屎”，也会在清楚的规范下自动消失。剩下的人是则有价值的，我们欢迎有朋自远方来。
ps. 在诸多朋友的帮助下，再修订了一遍，有了不少自己的思考，仅仅是反映在了译文之中，没有一一说明，见谅。详细的修订比对记录，在我的博客里，因为实在琐碎，就不再这里罗列了。
