Ten Rules for Open Source Success
《開源項目成功的十條準(zhǔn)則》
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年來的開發(fā)經(jīng)驗，總結(jié)為開源軟件的十條成功法則。
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】教給我的。我們要建立的是社區(qū)而不是軟件。沒有社區(qū)，你的代碼就會用來解決錯誤的問題。然后這些代碼會被拋棄、忽略，最后死去。正確的做法是把人集結(jié)起來，給他們協(xié)同工作的空間，給他們充分的挑戰(zhàn)。切記不要親手來寫代碼！
注1：Isabel Drost-Fromm是Apache軟件基金會的成員，Apache Mahout的創(chuàng)立者之一。
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.
“以相同方式共享”是開源的安全帶。在遇到嚴(yán)重的事故之前，你大可吹噓自己完全不需要它。一旦出現(xiàn)事故，你就會發(fā)現(xiàn)自己滿臉污垢，或者‘輕微擦傷’，不要成為一個“傷員”。使用“以相同方式共享”的許可證吧，如果你覺得GPL/LGPL太過于政治化，那就用MPLv2。
3、Use an Zero-Consensus Process
3、使用一個無需達(dá)成共識的協(xié)作流程
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已經(jīng)干掉了事前共識，所以在2015年的今天你沒有任何借口堅持事前共識。你應(yīng)當(dāng)像維基百科那樣接受修改。先合并，再修復(fù)，同時單獨討論。所有工作應(yīng)當(dāng)在master分支上進(jìn)行，不應(yīng)當(dāng)讓大家等待。有了既成事實，共識會隨之而來。
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.
教育自己和其他人，聚焦于問題而非功能特性。每一個補(bǔ)丁都必須是解決某個實際問題的最小化的解決方案。勇于嘗試，勇于接受瘋狂的想法。你還需要幫助他人，確保他們干的事情不會導(dǎo)致實驗室的爆炸。收集好的解決方案，拋棄那些糟糕的方案。在各個層面上都應(yīng)當(dāng)寬容失敗。這是學(xué)習(xí)過程中不可缺少的一部分。
5、Contracts Before Internals
5、首先約定，然后再完成內(nèi)部實現(xiàn)
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與協(xié)議）并加以測試。要使用持續(xù)集成工具測試所有的公開約定。代碼覆蓋率是無關(guān)緊要的，代碼文檔也是無關(guān)緊要的。真正重要的是代碼實現(xiàn)了哪些約定，以及它們是如何實現(xiàn)的。
6、Promote From Within
6、從內(nèi)部提拔
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.
將貢獻(xiàn)者提拔為維護(hù)者，將維護(hù)者提拔為負(fù)責(zé)人。以流暢、輕松且無畏地方式來做。保留干掉‘害群之馬’的最終權(quán)力。鼓勵大家開始自己的項目，尤其是基于已有項目，或者與已有項目競爭的項目。每天持之以恒地檢視并剝奪那些不再貢獻(xiàn)者的權(quán)力。
7、Write Down the Rules
7、將規(guī)則寫下來
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.
當(dāng)你制定規(guī)則時，請將他們寫下來，以便人們可以了解他們。事實上，你甚至都不需要親自動手——如果你愿意，可以直接套用我們?yōu)閆eroMQ制定的規(guī)則C4.1，再按需簡化。
8、Enforce the Rules Fairly
8、公平地執(zhí)行規(guī)則
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.
用你的權(quán)力去執(zhí)行規(guī)則，但不要強(qiáng)迫別人認(rèn)同你對于項目發(fā)展方向的“愿景”。最要緊的是，你自己必須遵守規(guī)則。最糟糕的事情莫過于維護(hù)者自己形成了小圈子，僅僅因為“不喜歡”就拒絕其他人的補(bǔ)丁。好吧，這樣說有點夸張了。不過，很多情況其實更加糟糕。還是那句話，小圈子對項目是有害的。
9、Aim For the Cloud
9、以“云”為目標(biāo)
Aim for a cloud of small, independent, self-organizing, competing projects. Be intolerant of large projects. By “l(fā)arge” 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.
以小型的、獨立的、自組織的、競爭性的（一群可以自由協(xié)作的）項目為目標(biāo)，（市場）不能容忍大項目。所謂“大”，我的意思是一個項目包含了2~3個核心想法。要拒絕子模組那樣花哨的依賴關(guān)系。讓大家去挑選，并將他們選擇的項目放到一起（工作）。這是經(jīng)濟(jì)學(xué)的常識。
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.
也許你注意到了，“創(chuàng)新”并不在我的建議列表中。它很可能排在第11或12點。總之，你需要在你的社區(qū)里培養(yǎng)一種積極的、愉快的氛圍。愚蠢的問題，愚蠢的人都應(yīng)當(dāng)被踢出去。就算有“老鼠屎”，也會在清楚的規(guī)范下自動消失。剩下的人是則有價值的，我們歡迎有朋自遠(yuǎn)方來。
ps. 在諸多朋友的幫助下，再修訂了一遍，有了不少自己的思考，僅僅是反映在了譯文之中，沒有一一說明，見諒。詳細(xì)的修訂比對記錄，在我的博客里，因為實在瑣碎，就不再這里羅列了。
