〈 Producing Open Source Software 〉閱讀筆記 1
因為想了解 Open Source 的一些經營和法律問題，所以找了這本書來讀。
針對裡面的一些重點作筆記，主要還是會偏向對開源專案的看法，一般性的討論就比較少。
怎樣判斷一個專案的失敗？
本書作者首先從如何判斷開源專案破題：
我們一般都不會聽到 Open Source 失敗，大部分就是維護者離開而停止維護
而這個離開是漸漸地，甚至是以另開一個新項目的方式結束，
又或是可以用專案使用的人漸漸變少來判斷呢？這些都顯示判斷一個專案結束很困難
而作者在本書中，想嘗試的就是告知讀者如何「避免專案失敗」
最常見錯誤：過高的期待
作者提到最常見對開源專案的誤解，就是抱有不切實際的期待
所以專案負責人可能不會投入過多的時間在介紹專案和包裝，把這些視為次要的
然而對於不熟悉的人，這些都很重要，但工程師也無可厚非，他們擅長他們擅長的事情
專案管理幾乎不太必要
在一個成功的開源專案中，很多討論和決定都是在檯面下進行
因為專案的組成成員是隨機而來，大家又幾乎沒有見過面，所以很難思考這個情況下會發生什麼事情
專案管理人們可能會相對活躍，但也是以低調和非正式的方式進行
因此多數管理的目標主要就是確定彼此有共同的看法，並設定溝通的規範
確保不會有人被排擠，並且可以讓專案成為貢獻者經常回來的地方
失敗的文化建設
大多數好的專案都會顯示出來他們獎勵、或是懲罰什麼樣的行為
通常專案會鼓勵不再規劃中的事件發生，儘管需要犧牲一些協調溝通的代價
而長期參與者會內化一個標準，使其成為一個貢獻者們共通的大致共識
而不成功的專案通常就是偏離了這個核心文化
使得專案遇到問題時，會突然迅速造成結果惡化，因為貢獻者們沒有對問題有共通的共識來解決分歧
開源是選擇性文化
所有人會參與到一個專案中，是因為他們選擇參與，如果他們不喜歡就會離開
只要他們喜歡就會付出一些時間，但要形成一個具有凝聚力和專注的團隊需要很長時間
同時要失去一個潛在有興趣的人，是很容易的一件事情，例如差勁的第一印象，別人就不會給予第二次機會
要維持這樣的聯繫很不容易，本書給予了一個很好的評量標準：
「參與者必須感受到他們與開源專案的聯繫，以及對專案的影響和他們的貢獻是成正比。」
選擇的技術框架、宣傳模式以及開發語言，都會影響到這一切
兩類不同的專案訪問對象：使用者和開發人員
有必須要思考哪些是使用者和開發人員共同都需要知道的，而那些要分開來
使用者文件和開發文件是否提供對應合適的訊息
如何讓用戶和開發人員放心？願意提出問題，甚至參與到專案中
關鍵就是要讓使用者和開發人員都要感受到：
「如果你插手這個專案，你不會浪費你的時間。」
是否重新發明了輪子
首先應該到各大開源專案平台搜尋，是否有和你類似的專案已經出現
如果有你還是想做，為了累積更多經驗的話也是無訪
甚至說你想對該現有專案做更深入的專業化，而別人可能做不到
通常這些想法都可以接受，但是你可能會發現加入這些項目比從頭開始更好
專案的最低激發能量：讓新人擺脫初始的陌生障礙
一個專案的開始，很重要就是要讓新人能快速擺脫不熟悉且陌生的初始狀況
這是一個專案最低的基本門檻，有人把這個門檻稱作「hacktivation energy」
也就是新人能在回頭來到你專案之前，他被鼓勵到能參與多深的水平