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. 第一次試著翻譯，求各位朋友幫忙指正，多謝了！
