開源專案是什麼在開源專案之前要了解什麼

開源專案是什麼

貴公司將內部專案作為開源發布。恭喜你！您知道您的**已經準備就緒，但是您準備好承擔所有新職責嗎？

專案作為開源發布後，您的公司不僅要對該專案負責，而且還要對將圍繞該專案形成的社群負責。這通常需要更改開發/構建/發布工作流程。這與**本身無關；涉及使開源專案成功的**的所有過程和基礎結構。

發布開源專案之前，這是您需要了解和期望的。

在繼續進行之前，請花一點時間評估您公司發布專案的目標。該公司將投入大量時間和精力來準備發布該版本，並將投入更多的精力來維護專案和圍繞它形成的社群。儘管這些努力可能是無私的，但公司更有可能期望其投資。

在進入專案及其社群之前，請確保您已意識到這些目標。採取步驟確保您的公司能夠滿足他們的要求，不僅對公司有幫助，而且還從總體上幫助了自由和開源軟體（foss）。不知道或不滿足其開源專案目標的公司完全退出了foss的參與，這對任何人都沒有幫助。

儘管您的公司可能仍掌握王國的鑰匙，並決定合併哪些貢獻以及何時**發布，但所有開發都必須與周圍的社群進行公開溝通和協調。

換句話說，該專案必須根據社群對開源專案的期望而運作。這些期望包括（但不限於）：

開源專案會產生很多任務作，儘管實際上通常只做專有軟體開發工作。儘管如此，仍然需要付出巨大的努力來轉換流程和文化，以在開放式系統中有效，高效地工作並支援開源社群。

如果工作量很大，為什麼要這樣做？

正如我之前提到的，企業通常不會全心全意地發布專案。他們之所以這樣做，是因為他們希望從希望在專案周圍形成的社群中受益，但是只有當公司贏得，建立並保持社群的信任時，這些收益才會發生。

這種信任是通過與社群進行公開，溝通和協作來完成所有工作而實現的。公司做出的任何完全單方面或私人的決定都將違反這種信任並疏遠社群。當社群疏遠時，他們離開了（有時分叉**以從其他地方重新開始）。

無法從消失的社群中受益。這就給公司留下了一堆開放的**，但是沒有人使用或關心，更不用說不能滿足其開源專案時設定的目標。

專案發布後，所有錯誤報告（以前的和新的錯誤報告）都必須在專案的公共問題***中可用。這是您需要做的一些事情：

決定是否將已關閉的錯誤/故障單/問題移至公共***。

建立乙個新的工作流，以便將所有錯誤/票證/問題都有效地路由到公共問題***並通過公共問題***。

專案作為開源發布後，其開發路線圖和所有相關討論將公開可用。

請注意：儘管路線圖和有關它的所有討論都是公開進行的，並得到了社群的意見，但除非做出其他調整，否則公司可能仍然對路線圖的內容，時間和原因擁有最終決定權。應當以尊重專案現在服務和支援的社群的方式來完成此工作。

如果公共路線圖包含與專有功能互動或依賴於專有功能的要素，則與專案互動的每個人都必須小心，不要在討**共路線圖時洩漏專有資訊。

專案作為開源發布後，所有對該項目的貢獻都必須使用乙個面向公眾的工作流程，無論該貢獻來自原始公司還是社群。

這是典型工作流程的示例：

每個專案都必須考慮並決定其特定的捐助需求和工作流程，並在專案的contributing.md檔案中將其公開。

在計畫開放內部專案的源**時，通常會忽略構建過程。這是不幸的，因為一旦專案發布，構建過程也會公開進行。

開啟構建過程時需要確保以下幾點：

所有構建過程都必須與公開可用的**（主/頭或為構建而維護的穩定分支）一起工作（無論對專案和產品最有意義的是什麼）。

所有構建工件應在構建完成後立即公開提供。

專案發布後，所有影響專案或其社群的決定都必須公開做出，包括治理的變化，對工具的調整（例如版本控制或持續整合）以及對通訊路徑的更改或新增。

這並不一定意味著每個微小的決定都必須傳送給委員會或需要整個社群的充分討論。通常，從社群中徵求建議和反饋並在決策時考慮它們就足夠了。

所有最終決定，其背後的原因及其預期結果必須公開宣布，可用，並記錄在專案用於此類事務的任何跟蹤系統中（通常是郵件列表加上文件系統或wiki）。

您現在知道了：

與專案有關的所有事情都需要公開進行。

專案作為開源發布後，它不再屬於公司「 you」，而是現在屬於「我們」社群（公司是公司的一部分）。這意味著必須在所有方面將社群包括在內。

本文中的任何和/或所有缺陷都是我的。

翻譯自:

開源專案是什麼

開源專案是什麼 在開源專案之前要了解什麼