2.1 開源項目的核心特征

在自由軟件運動的早期，項目開放的特征僅僅與代碼的許可證有關，即它是否在允許人們查看、修改和分發代碼的許可證之下？當時，這個想法本身就是新穎的，而所面臨的主要挑戰是專有軟件的增長與黑客和創客文化的背道而?馳。

我在寫本章的時候重讀了“大教堂與集市”，在閱讀過程中，我能感受到Eric Raymond在看到Linux的早期開發時的頓悟時刻。在那個時期，通常一個軟件是由一個開發人員或一小群開發人員開發的，他們對代碼有很高的要求，與你所認為的強迫癥傾向一樣；在精心構建的代碼中，只有完美的代碼會被發布，雖然他們歡迎別人提意見，但代碼貢獻門檻很高，要經過嚴格的審?查。

在你怒視這個問題之前，請考慮一下時間和地點。當時許多軟件的開發仍然在很大程度上依賴于學術的發展。由于硬件相當昂貴（1990年，平均成本接近4000美元），許多人仍然無法觸及這些工具。學會編程不是參加六周的訓練營就可以完成的事情，而是需要經歷多年的高等教育。你不能責怪早期的項目維護者采取的方法，這在很大程度上是務實的，而且其中許多項目已成為當今自由和開源軟件的基?石。

然而，Raymond看到了Linus在Linux中采取的一些新穎的方法，具體如?下。

● 他不是從頭開始寫所有代碼；相反，他從Minix中借鑒了相當數量的代碼（以及概念和想法）。

● Linux發布的第一個版本實際上是Beta質量的代?碼。

● 他公開鼓勵他人提供反饋并參與工?作。

如果你看一下Linus在1991年8月25日發布的關于Linux的帖子，就可以感受到他對待社群時的謙遜。如果你看一下目前一些受歡迎的開源項目，就能夠發現它們都有意識地效仿了Linus在Linux上采取的方式；Linux被視為開源項目的最佳案例之一。那么該項目有什么特征呢？下面我們將詳細討?論。

2.1.1　用戶是開發過程的一部分

“用戶是開發過程的一部分”是我們在后面章節中深入討論開源角色時會更深入研究的問題，但很明顯，開源的意圖是讓用戶參與到開發過程?中。

回想一下我在第1章分享的關于汽車密封式引擎蓋的軼事，這使得人們幾乎不可能看到或修改汽車內部零部件。如果沒有這種限制，用戶就可以了解更多關于汽車的信息，例如，汽車是如何工作的，設計的弱點在哪里，以及哪些地方可能容易升級與哪些地方會更復雜。

在汽車愛好者社群中，我們經常可以看到用戶參與開發的情形。我對別克Grand National的愛好者社群非常感興趣，這款車在1986年和1987年最火爆（1989年的龐蒂亞克Trans Am Pace車型也使用了這款車的傳動系統）。此后的幾年里，我們看到愛好者社群將這個車型推向了遠超通用汽車預期的高度。他們認為這款車的進氣口很局限，于是添加了更大的進氣系統。同時他們認為渦輪增壓器、噴油嘴和排氣系統還有一些提升空間，于是為其制造了適當的配件。現在，他們正在使汽車能夠適用于新型燃料，許多人將汽車從使用93號汽油改為使用E85乙醇汽油。這些行為都是由現實世界的需求推動的，無論是性能、適應現代需求，還是普通的技術改進，都是由那些擁有汽車的人以及供應商和機械師共同參與完成?的。

開源中有句話叫“水漲船高”，這在用戶參與開發的過程中得到了充分體現。雖然從目前的情況來看，這似乎非常常見，但在當時，這種讓核心開發人員之外的人也能貢獻新想法的方式還挺新鮮的，這正是Linus對待Linux的方式，并且幾十年后我們仍然能看到類似的情況。

2.1.2　早發布，常發布

想讓用戶參與開發過程，首先需要一種能夠讓用戶參與的方式。通常，在開源項目中，個人起初只是作為旁觀者（或者有些人可能稱之為潛水者，但我們還是保持積極的態度吧）。這些個人往往不會考慮成為貢獻者，而是更多地考慮項目對他們是否有用，提出諸如“它能解決我的問題嗎？”“它與其他解決方案相比如何？”“我該如何入手？”這樣的問題。隨著時間的推移，他們逐漸成為用戶，然后在郵件列表和論壇上參與交流。然而，正如之前討論過的，開源項目的意圖不是讓用戶遠離開發過程，而是使他們融入這個過?程。

在我目前參與的開源項目中，我經常幫助設置它們的代碼倉庫。對我來說，repolinter是一個非常有價值的工具，它可以檢查代碼倉庫中常見的問題，例如，查找缺失的許可證文件，確保有貢獻指南，還能在意外提交任何構建產物（如二進制文件、測試文件或構建日志）時進行提?醒。

使用該工具時，我發現了它在檢測拉取請求和發布模板時的一個錯誤（bug）。如果你使用單個文件，如ISSUE_TEMPLATE或PULL_REQUEST_TEMPLATE，該工具會做得很好，但是GitHub也支持在命名為ISSUE_TEMPLATE或PULL_REQUEST_TEMPLATE的目錄下添加多個模板，而repolinter卻無法識別。因為這是一個開源項目，所以我很容易就能得到項目授權，不僅可以提交錯誤報告，還可以提交修復該錯誤的指?南，對repolinter的拉取請求如圖2.1所示。

很快，一個項目維護者查看并批準了拉取請求，修復內容也隨之包含在0.10.0版本?中。

這就是“早發布，常發布”背后的模式和理念。該項目的版本號以“0.”開頭，說明其仍在積極開發中，需要不斷添加新功能。定期發布的新版本會將修復的內容捆綁在一起，并迅速交付給用戶進行測試。此外，用戶可以在代碼倉庫中的主分支（當時名為master，現在名為main）直接拉取最新版本立即開始測試（這正是我所做的）。這加快了反饋循環的速度，因為用戶可以在發布之前測試這些功能，可能會發現廣泛測試中出現的邊緣情況和其他難以重現的問題。幸運的是，我的貢獻相當簡單，所以沒有出現任何此類問?題。

我們會在后面的章節中重點討論如何將用戶轉化為貢獻者，同時探討如何讓項目給人以親切感并讓貢獻者成為項目的維護者，但要知道，這一切都需要建立在一個鼓勵用戶參與的開發模?式中。

2.1.3　透明和動態的決策

我經常在與我合作的非開源組織里看到一個無意的趨勢，那就是外人很難理解這個組織是如何運作的以及他們可以參與其中的方式。我說這是無意的，是因為當我與那些領導或參與這些組織的人交談時，他們常常抱怨其他人不愿意加入或幫助組織，或者說認為從外人那里得到的關于組織的問題往往很簡單，他們的回答是：“嗯，這些問題每個人都知道！”

在我寫這本書的時候，我正在自愿領導我們當地學區的學校舉行征稅活動，目標是重新征收所得稅，該征收是學校校區運營預算的主要收入來源。學校管理人員和那些自愿參加征稅活動的人所遇到的挫敗感來自大量不實信息的傳播，特別是有關為足球場鋪設人工草坪的資金問題。有人質疑為什么這個項目的資金比其他項目更多，這是一個合理的問題。由于缺乏我所提及的透明度，許多謠言開始出現，如“這個城鎮只喜歡足球，而不喜歡其他任何事情”或“學校董事會不知道如何花錢”。

事實是，舊足球場地的狀況非常糟糕，非常不安全，幾乎無法進行任何體育活動。在權衡修復和維護場地與鋪設草皮的選擇時，他們認為鋪設草皮是更好的解決方案。此外，使用草皮可以在一年中地面更潮濕的時候在場地上舉辦更多的賽事，從而帶來更大的收益機會。相關的資金不僅來自學區資助，還來自私人資助與籌款。另外，幾年前建造新學校時，新建筑的一部分包括一個非常先進的體育館，但至今學校也沒有在體育館里舉辦過任何體育比?賽。

學校董事會認為他們是透明的，因為所有的決策都是在公開會議上進行的，財務狀況也是公開的，但在分享“為什么做出這樣的選擇”背后的原因上缺乏透明?度。

開源項目蓬勃發展既依賴有意的透明度，又依賴快速動態地做出決策的能力，這通常會使開發速度變快，并讓項目保持活力。良好的開源項目通常具有強有力的書面文化，注重記錄項目中的所有過程，例如發布的方式、進行代碼貢獻所需的條件以及決策的方?式。

好的開源項目還應公開所有過去討論的內容，并讓當前的討論透明化，以便讓其他人看到決策的過程。對于他們來說，這能讓他們了解組織的文化和動態，并影響他們是否想在未來更多地參與該項目。我們將在第5章、第6章和第7章中深入探討這些概?念。

開源項目既可以成為推動協作和創新的機制，也可能成為無意建立社群而僅僅推送代碼的一種方式。下面讓我們進一步了解以開源方式發布代碼時應該有的預?期。