试译：开源项目成功的十条准则
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年来的开发经验，我想要总结以下10条经营要点：
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教给我的。建立社区而非软件，没有社区，你的代码将会去解决错误的问题。然后它将会被抛弃、忽略，最后死去。将人汇集起来，给他协同工作的空间，给他们足够好的挑战，停止自己写代码！
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与协议）并测试它们。使用CI工具测试所有的公开约定。代码覆盖率是无关紧要的，代码文档是无关紧要的。一切的关键都在与约定的代码实现，以及他们是如何实现的。
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制定的规则，再加以简化。
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. 第一次试着翻译，求各位朋友帮忙指正，多谢了！
