本週聖彼得堡將舉辦 IT 節 。 理查德·斯托曼 (Richard Stallman) 是演講者之一。 同樣參加這個節日，當然也不能忽視自由軟體的話題。 這就是為什麼我們的一份報告被稱為 。 它將致力於介紹 Embox 作為開源專案的發展歷史。 在這篇文章中，我想談談我認為影響開源專案發展的主要想法。 這篇文章和報告一樣，都是基於個人經驗。
讓我們從簡單的事情開始，也就是開源一詞的定義。 顯然，開源專案是擁有允許存取該專案原始程式碼的許可證之一的專案。 此外，開放項目意味著第三方開發者可以進行更改。 也就是說，如果某個公司或開發人員部分或全部發布其產品的程式碼，這並不會使該產品成為開源專案。 最後，任何專案活動都必須產生某種結果，而專案的開放性意味著這個結果不僅由開發人員自己使用。
我們不會觸及開放許可證的問題。 這是一個太大、太複雜的議題，需要深入研究。 關於這個主題已經寫了很多好的文章和資料。 但由於我自己不是版權領域的專家，所以我只會說許可證必須滿足專案的目標。 例如，對於 Embox 來說，選擇 BSD 而不是 GPL 授權並不是偶然的。
開源專案應該提供進行更改並影響開源專案開發的能力，這一事實意味著該專案是分散式的。 與集中管理的專案相比，管理它、維護完整性和效能要困難得多。 一個合理的問題出現了：為什麼要開放專案？ 答案在於商業可行性領域；對於某一類項目，這種方法的好處大於成本。 也就是說，它並不適合所有項目，開放式方法通常是可以接受的。 例如，很難想像基於開放原理開發發電廠或飛機的控制系統。 不，當然，這樣的系統應該包括基於開放專案的模組，因為這將提供許多優點。 但必須有人對最終產品負責。 即使系統完全基於開放專案的程式碼，開發人員在將所有內容打包到一個系統中並進行特定的建置和設定後，實際上也將其關閉。 該代碼可能是公開的。
創建或貢獻開源專案也能為這些系統帶來許多好處。 正如我已經說過的，最終系統代碼可能仍然是公開的。 為什麼，因為很明顯，任何人都不可能擁有相同的飛機來測試該系統。 這是事實，但很可能有人想要檢查程式碼的某些部分，或者，例如，有人可能發現正在使用的庫配置不正確。
如果公司將系統的一些基本部分分配到一個單獨的專案中，則會帶來更大的好處。 例如，支援某種資料交換協定的函式庫。 在這種情況下，即使協議特定於給定的主題領域，您也可以與該領域的其他公司分擔維護這部分系統的成本。 此外，能夠在公共領域研究該系統這一部分的專家需要更少的時間來有效地使用它。 最後，將一個部分分離成一個獨立的實體供第三方開發人員使用，這使我們能夠使這部分變得更好，因為我們需要提供有效的API，創建文檔，而且我甚至不是在談論提高測試覆蓋率。
一家公司不需要創建開源專案就可以獲得商業利益；其專家參與公司使用的第三方專案就足夠了。 畢竟，所有的好處仍然存在：員工更了解項目，因此他們更有效地使用它，公司可以影響專案的開發方向，並且使用現成的、經過調試的程式碼明顯降低了公司的成本。
創建開源專案的好處不止於此。 讓我們以行銷作為商業的重要組成部分。 對他來說，這是一個非常好的沙盒，可以讓他有效評估市場需求。
當然，我們不能忘記，開源專案是聲明自己作為任何專業化載體的有效方式。 在某些情況下，這是進入市場的唯一方法。 例如，Embox 最初是一個創建 RTOS 的專案。 可能無需解釋，競爭對手很多。 如果不創建社區，我們根本沒有足夠的資源將專案帶給最終用戶，即第三方開發人員開始使用該專案。
社群是開源專案的關鍵。 它可以讓您大幅降低專案管理成本、開發和支援專案。 可以說，沒有社群就根本沒有開源專案。
關於如何創建和管理開源專案社群的材料已經寫了很多。 為了不重述已知的事實，我將盡量關注 Embox 的體驗。 例如，創建社區的過程是一個非常有趣的問題。 也就是說，許多人講述瞭如何管理現有社區，但其創建時刻有時會被忽視，因為這是理所當然的。
創建開源專案社群時的主要規則是沒有規則。 我的意思是，沒有通用的規則，就像沒有靈丹妙藥一樣，即使只是因為項目非常不同。 在為 js 日誌庫和某些高度專業化的驅動程式建立社群時，您不太可能使用相同的規則。 此外，在專案（以及社區）發展的不同階段，規則會改變。
Embox 最初是一個學生項目，因為它可以接觸到系統程式設計部門的學生。 事實上，我們正在進入其他一些社區。 我們可以讓這個社群的參與者、學生對他們專業的良好工業實踐、系統程式設計領域的科學工作、課程作業和文憑感興趣。 也就是說，我們遵循組織社群的基本規則之一：社群成員必須得到一些東西，而這個價格必須與參與者的貢獻相對應。
Embox 的下一階段是尋找第三方用戶。 了解使用者是開源社群的完整參與者非常重要。 使用者通常多於開發人員。 為了成為某個專案的貢獻者，他們首先開始以某種方式使用它。
Embox 的第一批使用者是理論控制論系。 他們建議為 Lego Mindstorm 創建替代韌體。 儘管這些仍然是本地用戶（我們可以親自與他們會面並討論他們想要什麼）。 但這仍然是一次非常好的經驗。 例如，我們開發了可以向其他人展示的演示，因為機器人很有趣且引人注目。 結果，我們得到了真正的第三方用戶，他們開始詢問 Embox 是什麼以及如何使用它。
在這個階段，我們必須考慮文檔，考慮與使用者溝通的方式。 不，當然，我們之前想過這些重要的事情，但為時過早，並沒有產生積極的效果。 效果相當負面。 讓我舉幾個例子。 我們使用了 googlecode，其 wiki 支援多語言。 我們創建了多種語言的頁面，不僅有英語和俄語（我們很難用這些語言溝通），還有德語和西班牙語。 結果用這些語言問起來就顯得很可笑，但我們根本無法回答。 或者他們引入了有關編寫文件和評論的規則，但由於 API 經常發生重大變化，結果證明我們的文件已經過時，並且更具誤導性。
結果，我們所有的努力，甚至是錯誤的努力，都導致了外部用戶的出現。 甚至出現了一位商業客戶，希望為他開發自己的 RTOS。 我們開發它是因為我們有經驗和一些基礎。 在這裡你需要談論好的時刻和壞的時刻。 我將從壞的開始。 由於許多開發者都是以商業為目的參與這個計畫中，社區已經相當不穩定和分裂，這當然不能不影響計畫的發展。 另一個因素是該專案的方向是由一位商業客戶設定的，他的目標不是專案的進一步發展。 至少這不是主要目標。
另一方面，也有一些正面的方面。 我們擁有真正的第三方用戶。 不只是客戶，還有該系統的目標用戶。 參與此計畫的積極性有所提高。 畢竟，如果你還可以從有趣的業務中賺錢，那總是好的。 最重要的是，我們聽到了客戶的一個願望，這在當時對我們來說似乎很瘋狂，但現在是 Embox 的主要思想，即在系統中使用已經開發的程式碼。 現在Embox的主要想法是在沒有Linux的情況下使用Linux軟體。 也就是說，對專案進一步發展做出貢獻的主要積極方面是意識到該專案被第三方用戶使用，並且應該解決他們的一些問題。
那時，Embox 已經超出了學生專案的範圍。 根據學生模式開發專案的主要限制因素是參與者的動機。 學生在學習時參與，畢業時應有不同的動機。 如果沒有出現動力，學生就會停止參與專案。 如果我們考慮到學生首先需要接受培訓，那麼事實證明，他們在畢業時已成為優秀的專家，但由於缺乏經驗，他們對專案的貢獻並不是很大。
總的來說，我們順利地進入了讓我們討論創建開源專案的要點——創建一個可以解決用戶問題的產品。 正如我上面所解釋的，開源專案的主要屬性是它的社群。 此外，社群成員主要是使用者。 但當沒有東西可用時，它們從哪裡來？ 所以事實證明，就像非開源專案一樣，你需要專注於創建 MVP（最小可行產品），如果用戶感興趣，那麼圍繞該專案就會出現一個社群。 如果你只是透過社區 PR 來創建社區，用世界上所有語言編寫 wiki，或者在 github 上糾正 git 工作流程，那麼這在專案的早期階段不太可能重要。 當然，在適當的階段這些不僅是重要的，而且是必要的。
最後我想指出 在我看來，反映了使用者對開源專案的期望：
我正在認真考慮切換到這個作業系統（至少嘗試一下。他們正在積極追求它並做很酷的事情）。
電源打開 我們將收到多達三份報告。 一篇關於開源，兩篇關於嵌入式（其中一篇是實用的）。 在展位上，我們將舉辦一個關於使用微控制器程式設計的大師班 。 像往常一樣，我們會帶來硬體並讓您對其進行編程。 還會有任務和其他活動。 來到節日和我們的展位，一定會很有趣。
來源： www.habr.com