開源項目的可持續性:四大問題

本文翻譯自做者 VM BRASSEUR 的文章 Sustainability for Open Source Projects: 4 Big Questions安全

"可持續發展"這個詞在自由和開放源碼軟件(FOSS)中被常常提起。什麼是可持續性,它對你的項目意味着什麼?測試

可持續發展的概念並非起源於20世紀80年代,但它在那個時候得到了最爲普遍的關注,這要歸功於 Brundtland 的報告,該報告是聯合國在1987年發佈的,由一個跨職能的科學家、政策制定者和商業人士組成的團隊通過三年的研究所造成的。該報告將可持續發展定義爲"既知足當代人的需求,又不對後代人知足其自身需求的能力構成危害的發展"url

雖然咱們在這裏所說的可持續發展指的是全人類這個範疇,但這個定義也適用於自由和開放源碼軟件的開發。然而,在不一樣的項目中,對這個定義的實際解釋會有很大的不一樣。一方面,對於一個小而流行的 Python 庫來講,可持續性可能意味着經過將核心貢獻者的數量增長一倍來增長總線因素,從而避免維護者的倦怠,以確保老是有人能夠爲項目工做。實現這一點可能須要額外的文檔、自動化以及培訓,以指導新的貢獻者,因此這不必定是一個項目能夠在一晚上之間完成的事情。spa

另外一方面,有像 Blender、Let's Encrypt、Inkscape 和 Signal 這樣的項目。相對於這些項目的用戶數量(一般以百萬計),他們的貢獻者不多(不超過幾百人)。吸引更多的貢獻者多是這些大型項目的一個目標,但它可能比提供社區、財務獨立、擴大基礎設施或關鍵開發的合同等項目的優先級低。.net

一般,關於 FOSS 可持續性的討論最終都是以財務情況的好壞來形容,但正如你從上面的例子中能夠看到的那樣,這並非那麼簡單。維護者支付必定的報酬是很好的出發點,可是若是維護者僅僅只是在爲基本的項目和社區維護而拼命工做的話,這對項目的可持續發展是沒有任何幫助的。翻譯

四大問題

事實上,通過對許多項目的仔細檢查,可能會發現它們的可持續發展之路涉及到人員和財務要素的結合,須要加以平衡和優先考慮。這種檢查自己多是一個困難的過程,但若是項目社區經過自由和開放源碼軟件可持續發展的四大問題來進行檢查,就會變得相對容易一些。圖片

  1. 項目如今在哪裏?項目如今的真實狀態是什麼?它的痛點和瓶頸是什麼?有多少貢獻者,他們的感覺如何?項目揹負着怎樣的技術債務,包括文檔、用戶體驗、安全和可訪問性等重要但常常被忽視的東西?
  2. 項目想要達到的目標是什麼?每一個項目維護者的腦海中都有一幅"有一天......若是...... "的項目圖片。與社區分享這些圖片——不管它們如今看起來多麼不切實際。進行公開對話,將全部這些圖片凝聚成一個共享的圖像,能夠做爲"咱們但願項目長大後是什麼"的答案。這個形象並非現實,可能幾年內還不會成爲現實,但它可讓社區朝着一個共同的目標團結起來,並幫助設定一個方向,以更好地確保項目以可持續的方式發展。
  3. 項目如何從如今的位置發展到咱們但願的位置?這就是優先級和平衡的做用。你可能很熟悉爲軟件開發建立一個路線圖,列出要作的功能計劃和順序。在回答這個問題時,你正在建立項目開發的路線圖。"核心貢獻者數量翻倍"是該路線圖的一個好功能,但它可能有"增長貢獻者文檔"和 "增長測試覆蓋率"的前提條件和依賴性。一樣,"每一年的捐款達到25000美圓"能夠幫助支付擴展基礎設施的費用,但它有本身對"建立一個非營利組織"或"找到一個財政贊助商"的依賴性,由於管理這筆錢和涉及的稅收不是一件小事。就像軟件同樣,提早考慮好這些依賴性可讓項目開發減小挫折感,提升成功率。
  4. 項目如何保持在咱們想要的地方?最後,這就是可持續性問題。若是不回答前面三個問題,你就沒法回答這一個問題,即項目如何在不影響將來需求的狀況下知足如今的需求。值得慶幸的是,在回答前三個問題的過程當中,大多數項目發現他們已經在逐步解決這個問題。回答這個問題就變成了坐下來收集全部現有的想法,與社區分享,並按期從新審視它們,以確保項目仍在朝着可持續發展的方向前進。

規劃

咱們如今在哪裏,咱們要去哪裏,咱們將如何到達那裏,以及咱們將如何保持在那裏?可以回答這些問題可使項目和社區更強大、更加具備可持續性。ip

回答這些問題須要多長時間,這在很大程度上取決於項目、需求和文化。有些人會對更敏捷的東西感到舒服,制定最小可行的計劃,而後按期對它們進行迭代。其餘人可能更喜歡瀑布式的方法,提出一個詳細的路線圖來打動潛在的贊助商和貢獻者。惟一錯誤的方法是根本不作,錯誤地認爲項目的可持續性是能夠推遲到之後的事情ssl

相關文章
相關標籤/搜索