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