1. 好的開源項目

1.1. 好的開源項目絕不是一個簡單的概念

1.2. Linus在Linux中採取的一些新穎的方法

• 1.2.1. 他不是從頭開始寫所有代碼

• 1.2.1.1. 他從Minix中借鑑了相當數量的代碼（以及概念和想法）

• 1.2.2. Linux發佈的第一個版本實際上是Beta質量的代碼

• 1.2.3. 他公開鼓勵他人提供反饋並參與工作

1.3. 在自由軟件運動的早期，項目開放的特徵僅僅與代碼的許可證有關，即它是否在允許人們查看、修改和分發代碼的許可證之下

1.4. 並沒有一種固定的方式來運營一個開源項目，也沒有一個社羣應該採用一種固定的工作方式

1.5. 不同的文化、不同的行業領域、開發的速度和進度、項目的成熟度以及參與項目的人等諸多因素都會產生影響

2. 開源項目的核心特徵

2.1. 用户是開發過程的一部分

• 2.1.1. 開源中有句話叫“水漲船高”​，這在用户參與開發的過程中得到了充分體現

2.2. 早發佈，常發佈

2.3. 透明和動態的決策

• 2.3.1. 相關的資金不僅來自學區資助，還來自私人資助與籌款

• 2.3.2. 開源項目蓬勃發展既依賴有意的透明度，又依賴快速動態地做出決策的能力，這通常會使開發速度變快，並讓項目保持活力

• 2.3.3. 開源項目既可以成為推動協作和創新的機制，也可能成為無意建立社羣而僅僅推送代碼的一種方式

3. 發佈開源代碼與創建開源項目

3.1. 有一種特別的趨勢，那就是公司將開源代碼視為一種使源代碼可用的方法，但並不一定希望圍繞它構建一個開源項目

3.2. 智能代碼轉儲

• 3.2.1. 那些之前可能是商業產品或其他不開源的代碼，現在以開源許可證的形式被共享，但貢獻代碼的組織並沒有打算繼續維護它，更不用説構建項目或社羣了

• 3.2.2. 非常有用的轉儲原因

• 3.2.2.1. 幫助那些仍在使用較舊版本軟件的公司，使他們能夠繼續運作

• 3.2.2.2. 允許其他人使用過時的文件格式構建轉換器或連接器

• 3.2.2.3. 通過為社羣的愛好者和發燒友提供過時的軟件來表達善意

• 3.2.3. 發佈開源代碼但不創建開源項目不僅適用於過時的軟件，也適用於所有希望獲得更大用户羣的軟件

3.3. 開放核心

• 3.3.1. 意思是公司發佈一個基本的、精簡的但功能齊全的產品版本進行開源，然後採用專有許可證發佈一個功能更全面的商業版本

• 3.3.2. “嘮叨軟件”(nagware)

• 3.3.2.1. 共享軟件

• 3.3.2.2. 它們會彈出煩人的窗口，提示用户購買商業版本

• 3.3.3. 主要的開發工作並不是在開源社羣中進行

• 3.3.4. 代碼發佈只是傾倒到社羣中供人們使用

• 3.3.5. 儘可能擴大用户羣體，其策略是隨着軟件在組織中使用量的增加，用户可能會考慮購買其商業版本

• 3.3.6. 通常是在供應商中立的基礎上，將下游生態系統建設的概念視為幫助解決變現問題的一種進化方式

3.4. 以開源方式發佈代碼時的期望

• 3.4.1. 開源對下游用户和開發人員負有道德責任

• 3.4.2. Linux基金會主持的項目TODO Group提供了一個合作論壇，名為開源項目辦公室(Open Source Program Office，OSPO)，它提供了一個很好的資源

• 3.4.3. 儘早讓其他有興趣參與或貢獻的外部組織和人員參與進來

• 3.4.4. 建立協作基礎設施並將其公開

• 3.4.5. 定期舉行社羣會議，並尋找自然的見面機會，例如參加活動或當地聚會

• 3.4.5.1. 不僅為社羣設定了預期，也為作為維護者的你設定了預期，讓你始終牢記這些重要的事情

• 3.4.6. 啓動一個開源項目意味着你需要有意識地支持其成功

• 3.4.6.1. 前期投資可能會很高，甚至比內部非開源項目還要高，但如果做得好，這種投資會得到回報，你能夠以更低的投入獲得驚人的技術回報（其他人也可以）​

4. 成功的開源項目的模式和反模式

4.1. 適用於一個項目的方案可能不適用於下一個方案，因為每個項目的人羣、文化、行業動態和速度都不同

4.2. 開放式溝通（和過度溝通）

• 4.2.1. 最大挑戰是溝通

• 4.2.2. 溝通的缺失會導致混淆和誤解，甚至有時事情本身會被誤解

• 4.2.3. 待辦事項永遠不會完結，需求不斷，用户經常給你“踢皮球”

• 4.2.3.1. 多一點寬容會有很大幫助，更重要的是，這為你提供了吸引貢獻者和用户的最佳方式

• 4.2.4. 過度溝通在前期需要做很多工作，但它可以節省你以後回答問題的時間，並有可能幫助你接觸到你可能從未聯繫過的用户

4.3. 仁慈獨裁與委員會領導

• 4.3.1. Linux已經由Linus領導了30多年，他是仁慈獨裁領導風格的典型代表

• 4.3.2. 無論是從項目管理的角度，還是從文化和道德的角度來看，仁慈獨裁者模式都給個人帶來了沉重的負擔，這意味着個人必須能夠推動項目向前發展，同時吸引貢獻者和用户，賦予他們能力和權力並推動技術的發展

• 4.3.3. 仁慈獨裁作為一種模式通常屬於“一般不起作用，但在某些情況下，有了正確的仁慈獨裁者和正確的社羣，它就會起作用”的狹窄類別

• 4.3.3.1. 模式的挑戰在於需要正確的人來領導，他們需要有遠見、有組織、有思想，能夠將人們聚集在一起併發揮作用

• 4.3.4. 委員會領導解決了仁慈獨裁者模式的問題，通過將決策和責任分散到多個人身上來提高項目效率，並隨着時間的推移獲得多樣化的貢獻者和貢獻

• 4.3.4.1. 迫使項目進行更好的溝通

• 4.3.4.2. 並不意味着由委員會領導是完美的

• 4.3.5. 仁慈獨裁者可以在自己的腦海中思考關鍵決策，而委員會的方法則迫使每個人都表達自己的想法以達成共識

• 4.3.6. 初創項目更適合採用仁慈獨裁者模式，而成熟項目更適合採用委員會領導模式

4.4. 分支

• 4.4.1. 分支是開源中每個人所擁有的基本權利之一，也是每個開源許可證的核心

• 4.4.2. 分支的缺點在於用户必須承擔一些成本，即對分支的持續維護成本，因為它可能會長期存在（可以持續多個項目版本，甚至是永久存在）​，而且隨着時間的推移，需要將項目代碼倉庫中的更改持續引入分支的版本中

• 4.4.3. 在上游工作是一種更好的方法，這意味着當對代碼倉庫進行更改時，你可以將它們貢獻回項目中，而不是單獨維護它們

• 4.4.4. 在開源社羣中，在上游工作通常是最好的方法，它能夠使你的更改得到更廣泛的測試，節省了將它們合併到後續版本中的時間，並展示了你作為代碼倉庫管理者的能力

• 4.4.5. 社羣中的衝突是健康的，因為它給人們提供了發表意見的機會，並確保社羣內部存在凝聚力和不同的觀點

4.5. 過度治理

• 4.5.1. 如果你遇到一條看起來有點瘋狂的法律或規則，那麼它的背後肯定有一個更瘋狂的故事

• 4.5.2. 一個活的文檔，可以隨着時間的推移而改變以適應項目的不同階段

• 4.5.3. 不要制定處理假設情況的規則，而是針對已知問題制定規則，並隨着時間的推移重新審視它們，並予以修改

4.6. 歡迎競爭對手

• 4.6.1. 開源的一個獨特之處在於，合作是向所有人敞開的，因此即使是競爭對手也可以參與其中

• 4.6.2. 實際上，只要制定適當的基本規則，就可以使開源項目充滿活力並且高速發展

4.7. 把一切都寫下來

• 4.7.1. 書面文化與開放式溝通非常契合，因為實現開放式溝通的一個好方法是通過書面文字溝通

• 4.7.2. 使得重複流程變得更加一致，同時還能找到提高項目效率的機會和需要解決的問題

• 4.7.3. 將事情寫下來不僅有助於與外界進行溝通，還可以協調和確定活動的優先級

• 4.7.4. 把一切都寫下來，雖然有時看起來很煩人，但有助於使項目更加高效和有條理

• 4.7.5. 這樣做還能幫助社羣擴大規模，使新的成員隨時加入社羣，接管這些職責並持續管理這些任務

4.8. 擁抱你的社羣

• 4.8.1. 創建開源項目的主要驅動力是讓各種各樣的人蔘與進來，提供反饋、貢獻代碼並幫助維護項目

4.9. 關注你的優勢，利用工具和其他資源來彌補你的劣勢

• 4.9.1. 作為人類，我們最難做的事情之一就是接受自己的缺點和我們不擅長的事情

• 4.9.2. 技術文檔是一個很好的例子，大多數軟件工程師覺得自己在這方面表現不佳，或者對技術寫作沒有太多興趣，但是有些人在這方面非常擅長，可以為項目製作出出色的文檔

• 4.9.3. 除了找對人，使用正確的工具也是一種提高工作效率，減輕工作負擔的方法

• 4.9.3.1. 像FOSSology這樣的工具可以幫你完成這項工作，並同時生成報告和軟件物料清單(Software Bill of Materials，SBOM)