開源軟體意味著什麼?當你需要向別人解釋時，如何省心又省力地傳達開源的價值和精髓?自從開源這個短語在1997年首次提出以來，業界在開源方面已經獲得了許多來之不易的經驗教訓，我們不應該忘記這些經驗教訓。
為此，我收集了12個文化基因，在我看來它們有助於分享歷史、搭建舞台，並為開源的定義以及它對整個軟體行業的意義提供上下文。
這頭幾個文化基因涉及軟體的構建。我認為，它們定義了我們所認為的成功的開源項目，因為它們就是涉及軟體本身的基本方面。了解這些文化基因的項目才會成功。採用寬鬆許可證、注重社區的軟體可能是我們用來構建和維護優秀軟體的最出色、最高效的軟體重複使用機制。
第一個文化基因：自我們編寫軟體以來就共享軟體。
上世紀50年代末，IBM開辦了一場計算機大會，這個大會一直持續到今天，名叫SHARE。DEC在60年代開辦，支持DECUS社區，你可以在其會議上購買裝滿其他人編寫和貢獻的軟體的磁帶。USENIX起源於70年代，當時適逢使用磁帶發布早期UNIX版本。但是這種共享的做法完全可以追溯到40年代普林斯頓高級研究所的第一台可編程計算機上的開發工作。
第二個文化基因：編寫優秀軟體是艱苦的工作。
我認為，共享歸結為這個簡單的現實：編寫優秀軟體很困難。軟體開發領域有兩大比率：開發人員在一天之內平均可以編寫的代碼行數，合理開發流程出來的每千行代碼的錯誤數量。從語言進化到架構重複使用的所有軟體方面的進展圍繞這個中心思想：用更少行的代碼編寫出更多更優秀的軟體。軟體構建可靠性、配置管理、審查工具和流程以及測試方面的進步，都旨在減少合理的軟體交付流程出來的錯誤數量。
第三個文化基因：沒有毫無章法的規模擴展。
編寫優秀軟體離不開章法。如果你看一下作為成功產品或者開源項目的軟體，構建時通常會由同行審查，實行版本控制和配置管理，構建自動化和測試框架與軟體一同完善。要是沒有審查、配置管理以及構建和測試自動化，軟體無法在用戶社區裡面進行擴展，作為一款產品也無法在成千上萬的用戶當中進行擴展。需要維護軟體的核心小組一定要能夠回答”軟體執行什麼”。
林納斯定律可以籠統地表述為”給予足夠的關注，所有代碼錯誤都會浮現出來。”我認為這實際上表明了提交審查過程的重要性。研究表明，審查環節發現的錯誤比測試環節發現的還多。一個健康的社區勢必在代碼簽入(check-in)方面有一套嚴格的審查流程。
第四個文化基因：軟體天生是動態的。
程序因使用而完善。錯誤被發現後要加以修復。發現新的用途，從而推動新功能。程序不斷得到磨練和加強。程序從一個環境移植到另一個環境。遺憾的是，版權在1980年成了”保護”軟體發布管道的機制。人們也許不明白軟體的發展有多快、衍生版的開發有多快，或者也許不明白物聯網和萬維網問世後，這種動態性只會加快。我們共享網絡帶寬已從磁帶大小的口袋、會議日程表和雜誌出版延遲變成了全天候的實時全球構建、發布和維護。
不妨看一下與開源軟體的社區方面有關的幾個文化基因。
第五個文化基因：你得到的總是多過給予的。
這是社區協作式開發的經濟效率。不斷貢獻可謂是項目軟體發展的生命線。貢獻者貢獻代碼或提供修正版沒有多大的風險，但是得到的好處是，整個軟體可以按貢獻者覺得合適的方式來使用。而至於路過式貢獻，這可能是開發人員給予的唯一重大貢獻，不管他們的經驗和專長如何。
得到的回報大於貢獻既適用於個人，也適用於公司。來自紅帽、英特爾和IBM等幾家大公司的專用資源和投入讓它們得以借助整個Linux操作系統來實行不同的商業戰略。公司可以將優秀的軟體項目變成解決客戶問題的產品。
第六個文化基因：有人吃白食是成功的關鍵。
坊間傳聞，在一個開源項目的每1000個用戶中，有100人可能報告軟體錯誤，其中10人貢獻潛在的修正版，其中只有1人仔細閱讀貢獻準則。實際上，社區成功有三條途徑（社區成功的衡量標準是代碼貢獻）。一個是軟體需要異常容易安裝和使用，那樣項目才會獲得大量用戶。二是用戶群當中會有開發者。軟體需要異常容易構建和測試，那樣想要更改（為了自己的私利）的開發者很容易更改。三是需要異常容易能夠回過頭來向項目貢獻變更，那樣貢獻才會源源不斷。有大量吃白食的人意味著你幹得不賴。這樣，如果有大量用戶，對開發者來說會大有潛力，貢獻的可能性也會隨之而來。但是項目的責任是確保容易。
試圖構建開源項目的公司常常很難了解社區。他們想，有人得為自己提供東西。他們習慣於向社區（比如開發者網站）發號施令，而不是協作。有三個文化基因適用於公司和開源。
第七個文化基因：不混淆產品和項目。
項目其實是一組安裝和運行後可以解決某個問題的切實可行的軟體。它是一種以代碼來說話的協作和交流。你需要了解項目不是產品。產品是以解決客戶的問題來盈利的東西。雖然很多出色的軟體來自於運作良好、為工程技術減少一些工作的開源項目，但是仍有艱巨的工作要做，才能將它變成對客戶而言解決問題的產品。比如Linux內核是項目，Fedora是發行版項目，RHEL卻是產品。產品以滿足客戶對價值的期望來盈利。產品可默認安裝、運行，附帶保證和賠償，還有服務（支持、升級、培訓和諮詢）以及針對特定產品的說明文檔。它們可能是包括硬體和服務的更龐大產品組合的一部分。
這個文化基因的一個推論可能是：”沒有人來為你構建你的產品。”
第八個文化基因：不混淆客戶和社區。
如果說第七個文化基因涉及工程技術和商業模式，那麼第八個文化基因就涉及訊息和銷售。社區和客戶的價值觀不一樣。客戶是花錢來加快解決問題，消除風險，而社區（及社區中的個人）通過合作，構建自己的解決方案。使用開源軟體的一些公司認為，項目社區是產品管道的一部分；他們在社區論壇中找到客戶時，就會進一步這麼認為。他們甚至可能認為，社區項目是一種先試後買的東西。可是，這一切都是錯誤的。
公司與相關社區的交流跟其與付費客戶的交流不一樣。每次交流都有特定的工具和交戰規則，以及需要記錄和考慮的度量指標。社區成員非常具有價值，但他們不是客戶。
第九個文化基因：早在開源定義之前，公司就共享寬鬆許可證的軟體。
Project Athena(X11，Kerberos)始於1983年。開放系統基金會(OSF/Motif，OSF / 1)始於1988年。DEC和Sun從早期的BSD版本分別開發出了Ultrix和SunOS。這不是新的行為。
最後，幾個文化基因涉及開源軟體方面的許可和法律討論。
第十個文化基因：軟體自由和開源許可是不同的討論話題。
爭論軟體自由與開源軟體就好比爭論民主主義是否比資本主義更好，或者爭論言論自由是否比自由市場更重要。它們本身都是重要的討論，人們往往對於某個主題有天然的傾向性，但它們是不一樣的討論。軟體自由語言由用戶權利來界定，開源軟體語言則由許可證的屬性來界定。這些是不同的討論。
第十一個文化基因：每個開源項目都需要許可證。
許可證定義了別人可以如何使用軟體。軟體受版權法保護，需要選擇經OSI批准的許可證。你選擇的許可證聲明了你在社區中想要的那種社會契約。雖然近年來，很多人默認選擇Apache軟體許可證為”對商業友好”的許可證，但它未必就是如此。互惠許可證還是隨意許可證並不是談論自由軟體還是開源軟體。互惠許可證也許是對生態系統友好的最佳許可證。
第十二個文化基因：基金會有一席之地。
非營利性組織可提供公平的競爭環境和IP（知識產權）所有權的中立性，從而讓公司能夠專門致力於一家運行良好的開源項目。
結束語
上世紀90年代中期至末期，我和同事利用寬鬆許可證軟體開辦了一家軟體公司，那時候開源軟體這個術語還沒有問世。這其實沒有太大的神秘性可言。我們收集並移植了大約250個採用25個不同許可證的程序包（這些許可證包括伯克利許可證、MIT許可證和GPLv2），並結合我們自己的軟體，還有一些重要軟體是微軟擁有的，其許可證允許我們使用。我們把它開發成了一款我們公司全力支持的產品，這款產品採用了我們自家產品的許可證。我們以不同方式參與了那些不同的協作社區。作為一批工程師和商界人士，我們能夠在UNIX系統社區中不斷成長，得益於悠久的協作和共享歷史。
回頭看看這些文化基因，我認為它們與我在20年前會寫下來的文化基因一模一樣。
你會補充什麼樣的文化基因?你有什麼樣的經驗之談?歡迎留言交流。
轉載請註明：開發者關係 »
