[[151765]]

每個人都想要，不少人都在試，但是創(chuàng)造它的過程，說起來卻都是淚。我說的是自由軟件，又叫開源軟件（譯者注：本文重點不是辨析自由軟件和開源軟件的概念，作者如此說，姑且認(rèn)為兩者是一回事）。今天我要用十條行之有效的法則，來談?wù)勎胰甑膶懘a經(jīng)驗。

1. 先有人，后有代碼這是一條黃金定律，Isabel Drost-Fromm教我的。致力于社區(qū)建設(shè)，而不是軟件本身。沒有社區(qū)，你的代碼解決的可能是錯誤的問題。這些代碼會被廢棄、忽略，最終消亡。先吸引人才，再給他們協(xié)作的空間。給他們有挑戰(zhàn)的工作。不要自己寫代碼。
2. 采用強制開源的許可證強制開源（share-alike）的許可證是開源軟件的保險帶。別夸口說你不需要，總有一天你會被打臉，遍體鱗傷。不要被打臉，使用強制開源的許可證。如果GPL/LGPL對你來說政治意味太濃，那么用MPLv2。
3. 別指望達(dá)成共識做決定前尋求共識，就好像指望能找到理想的人生伴侶一樣。有點不切實際。Github拋棄了共識，他們設(shè)計了fork/pull-request流程，所以2015年你已經(jīng)沒什么借口了。你接受補丁就可以了，就像維基百科會接受增補。先合并代碼，再修復(fù)問題，最后再討論。把所有開發(fā)工作都放在主分支上。不要讓用戶等。這樣做你才能得到事實上的共識。
4. 先問題后方案讓你自己和你隊友們關(guān)注問題，而不是功能。每個補丁都必須解決一個實在的問題。歡迎實驗性代碼，歡迎異想天開的創(chuàng)意。但不要讓這些東西過度膨脹。收集好的方案，拋棄壞的。允許失敗，各個層面上的失敗。這是成長的必經(jīng)之路。
5. 先定義后實現(xiàn)積極地為API和協(xié)議的定義寫文檔并進(jìn)行測試。用持續(xù)集成來測試公開的API和協(xié)議。代碼覆蓋率不重要，代碼文檔也不重要。重要的是，定義好的東西代碼要去實現(xiàn)，并且實現(xiàn)得要好。
6. 內(nèi)部挖潛讓貢獻(xiàn)者（contributor）成為維護者（maintainer），讓維護者成為負(fù)責(zé)人（owner）。平穩(wěn)地、放松地做這件事，別害怕。保留權(quán)力把表現(xiàn)糟糕的人踢出去。鼓勵人們創(chuàng)立他們自己的項目，尤其是基于已有的項目開發(fā)的新項目，或者與已有項目構(gòu)成競爭關(guān)系的項目。日常表現(xiàn)不好的人，卸下他們的權(quán)力。
7. 寫下規(guī)則你有了自己的規(guī)則，就要寫下來，這樣大家才能知道。實際上都不用寫了，借用我們?yōu)閆eroMQ設(shè)計的C4.1規(guī)則就行，如果你愿意，也可以簡化這些規(guī)則。
8. 公平地執(zhí)行規(guī)則你的權(quán)力應(yīng)該用來執(zhí)行規(guī)則，而不是威逼別人認(rèn)同項目的愿景。最重要的是，你自己要遵守規(guī)則。有這么一小撮維護者，會僅僅因為他們不喜歡一個補丁而槍斃它，而你如果自己不遵守規(guī)則，就會助長這類小團體，沒什么比這更糟糕了。好吧，這么說有點夸張，更糟糕的事情多著呢。但是這類小團體會對項目造成危害。
9. 細(xì)分項目力爭建立一群小型、獨立、自組織、互相競爭的小項目。不要搞大項目。這里說的“大項目”是指，有兩到三個核心開發(fā)者的項目。不要用submodules（譯者注：git的命令，用于指定外部項目的依賴性）之類的來指定依賴性。讓別人自己選擇想要集成的項目。這是基本的法則。
10. 保持快樂的氛圍也許你注意到，我并沒有提及“創(chuàng)新”。如果要提，創(chuàng)新可能會排在11或12位。無論如何，你要為社區(qū)營造正向快樂的氛圍。不要說某個問題愚蠢，不要說某個人愚蠢。社區(qū)總有一些人表現(xiàn)糟糕，即使規(guī)則很清楚也要違反。除了這些人，其他所有人都值得我們珍惜，我們應(yīng)該像遠(yuǎn)道來訪的客人一樣對待他們。