[[121367]]

循序漸進的指導

你有這個問題：你已經權衡了開源代碼的優劣勢，你也已經知道你的軟件需要成為一個開源項目，但是，你不知道怎么做好的開源項目。

當然，你也許已經知道如何創建Github帳號并開始，但是這些事實上是做開源比較簡單的部分。而真真正正難的部分是如何讓足夠多的人，關注你的項目并給你的項目做貢獻。

接下來的原則是會指導你構建和發布其他人愿意關注的代碼。

基本原則

選擇開源可能有許多原因。也許你希望吸引一個社區來幫助編寫你的代碼。也許，總所周知，你明白“開源--一個開發小團隊內部編寫代碼的倍增器。”

或者你只是認為這是必須做的事，如同英國政府一樣。

無論何種原因，為了開源能夠成功，是必須要做很多的計劃去給將來使用這個軟件的人們。如同我在2005寫道，如果你“需要大量的人做貢獻（bug修復，擴展等等）”，那么你需要“寫一個好的文檔，使用易于接受的編程語言，和使用模型架構”。

對了，你也需要寫人們在乎的軟件。

每天思考你依靠的技術：操作系統，web應用框架，數據庫，等等。遠離像航天這樣，特殊行業的小生態技術，讓開源擁有更多的可能性以便外部的（人的）產生興趣和做出貢獻。更廣泛的應用技術，找到更多的貢獻者和用戶。

總的來說，任何成功的開源項目有以下共同點：

1.***的時間時機（解決市場實際需求）

2.一個健壯，包括開發者和非開發者的團隊

3.一個易于參與的結構（更多詳見下文）

4.模塊化編碼，使新貢獻者更容易找到一個項目損壞的部分去貢獻，比強迫他們理解巨大的代碼的每一部分要好

5.代碼可以廣泛應用（或者達到一個狹窄的流行都比一個“自生自滅的”小生態更吸引人）

6.很好初始源碼（如果你放垃圾在Github，你也只會得到垃圾回報）

7.一個自由的許可證-我個人更愛Apache型的許可證，因為它讓開發者采用時障礙***，當然許多成功的項目（如Linux和MySQL）使用GPL許可證也有很棒的效果。

上述幾項，是一個項目成功邀請參與者最難的部分。這是因為他們不是關于代碼而是關于人。

開源不單是一個許可證

今年，最棒的一件事是我讀到是來自 Vitorio Miliano (@vitor_io)的文章，他是用戶體驗交互設計師，來自德州的奧斯丁。Miliano指出，那些不在你的項目上工作的人才是“外行”，從本質上說無論他們技術能力的級別，他們僅僅懂一點代碼（也沒關系）。

所以你的工作，他認為，是使人加入，為你貢獻你的代碼變得簡單。當闡述如何涉及非程序員到開源項目中，他指出項目的一些事項，項目領導應需要有效地得加入一些任何技術或不懂技術的人到開源項目。

1.一種方法去了解你的項目價值

2.一種方法去了解他們可以為項目提供的價值

3.一種方法去了解他們可以從貢獻代碼獲得的價值

4.一種方法去了解貢獻流程，端到端

5.貢獻機制適用于現有的工作流

經常，項目***想要集中于上述的第五步，卻不提供理解1到4的路徑。如果潛在的貢獻者不欣賞“為什么”，“如何”共享就變得不重要了。

注意，至關重要的，Miliano寫道，建立擁有一個通俗易懂的簡介的項目很有價值，如同任何時候通過簡介給每一個人演示可訪問性和包容性。他斷言道，這增加了額外的好處，文檔和其他的版本介紹的內容變得通俗易懂。

關于第二點，程序員或非程序員同樣地需要能夠明白到底你需要什么，這樣他們就可以認識到他們的貢獻（方向）。有時就像MongoDB解決方案架構師Henrik Ingo告訴我那樣，"一個聰明的人可以貢獻很棒的代碼，但是項目成員不能理解它（代碼）"，如果在組織內承認這個貢獻并且研究后理解，那么這就不是一個糟糕的問題。

但是不會經常發生。

你真的想領導一個開源項目嗎？

許多開源項目的領導提倡包容性，但是他們擁有任何事除了包容。如果你不想要人們做貢獻，不要假裝開源。

是的，有時這是老生常談的話題。就像HackerNews最近的報道一個開發者的開發工作。

小項目可以得到很多，基本不需要很多人合作來完成。我看到了他們的進步，但是我沒有看到我自己的進步:如果我幫助了他們，顯然，如果我花費了有限的時間在與那些計算機科學的碩士管理合作上，而沒有參與編碼，這不是我想要的。所以我忽略了他們。

這是一個保持理智的的好方法，但這個態度并不能預示著這個項目會被廣闊的分享。

如果你確實很少關心非程序員設計的貢獻、文檔，或者無論其他什么，那么請首先了解那些。再次強調，如果這是實情，你的項目就不能成為一個開源項目。

當然，排除感覺不總是可靠的。 就像ActiveState的副總裁Bernard Golden告訴過我，“一些將會成為開發人員將會對現有的“小集團”開發團體這種感覺感到恐懼，雖然這不一定正確。”

現在，若使了解開發人員為什么要貢獻并邀請做開發，意味著更多的開源項目投資，更長久地生存。

本文鏈接：http://www.cocoachina.com/programmer/20141020/9970.html