企業開源指南:參與開源社群
最大限度優化組織中執行開源計劃或啟動開源專案的實踐。這些資源由 Linux 基金會與 TODO Group 合作開發,代表了我們的員工、專案和成員的經驗。
不僅僅在技術領域,在各個行業,開源已經成為開發軟體的實際途徑。隨著公司使用開原始碼來開發自己的商業產品和服務,他們也看到了開源貢獻回饋給開源專案的戰略價值。
然而,這些公司如果不瞭解這些專案,不瞭解專案所處的開源社群以及專案是如何運作的,就參與開源的話,可能會給公司本身和開源社群帶來不利影響。沒有確立戰略就接觸開源貢獻的話,可能會影響公司在開源社群中的聲譽並招致法律風險。
本指南說明了作為一個組織為開源做貢獻意味著什麼,並指明瞭如何成為一個優秀的開源社群企業公民。通過閱讀本指南,可以瞭解開源專案是如何構建的,如何進行開源貢獻,為什麼內部開發者參與開源貢獻是重要的,以及為什麼為開源參與和開源管理制定戰略是重要的。
本指南的撰稿人
- Stormy Peters - Red Hat 開源社群領導者高階經理
- Nithya Ruff - Comcast 開源實踐高階經理
為何進行開源貢獻
在今天,幾乎不可能找到一個沒有從開源軟體中以某種方式獲益過的組織。一些公司,如英特爾、IBM 和三星,所有的開源專案都為開源社群做出貢獻。當系統管理員或開發人員將軟體帶入開源社群時,其他公司幾乎無意中便成為了開源的消費者。
許多公司取得商業上的成功,開源軟體對其至關重要。因此,為開源軟體專案做貢獻變得有益(且必要)。自 2005 年起,已經有來自 1,300 多家不同公司的超過 13,500 名開發人員為 Linux 核心做出了貢獻,而這,僅僅只是一個專案!
“我們知道,對於許多大型專案來說,我們的大多數貢獻者將會是那些需要使用像 Ceph 和 Gluster 這樣專案的公司的員工。我們有很多客戶,客戶會為開源軟體做貢獻,是因為他們需要使用這些軟體。不論是個人蔘與貢獻還是企業參與貢獻, 我們都將它們視為成功的案例。”
Stormy Peters – Red Hat開源社群領導者高階經理
Linux kernel developers contributing to each kernel release over time. Source: The Linux Foundation’s Linux Kernel Report, 2016.
比起開源社群中一些受益於企業回饋的貢獻,有很多強有力的商業原因顯示貴組織內部所使用的開源軟體專案會從開源社群受益更多。這裡有幾點開源貢獻的益處:
- 吸引人才——當您依賴開源軟體時,找到了解該專案內外部情況的人員的最佳地點就是在該專案的開源社群中。通過在社群中公開地工作,您可以吸引那些意識到他們可以為自己最喜歡的開源專案工作並獲得報酬的人。當您的員工每天與這些人並肩工作時,他們可以幫助您找到適合貴公司的人才。(請參閱我們關於招聘開發人員的指南)
- 降低維護成本——那些沒有將新特性或新功能貢獻回饋給上游專案,就開始修復漏洞或者為開源專案增加新特性和新功能的企業,很快就會認識到,新功能增加或應用安全修復的升級滯後,可能會成為一場驅使維護成本不斷上升的噩夢。而將您的變更貢獻回饋給上游專案,意味著這些變更會自動包含在之後的更新中,而不會產生額外的維護成本。
- 影響方向——在開源專案中,新的特性和功能源於貢獻,而且這些貢獻會影響專案的方向。如果您希望專案能夠擁有對貴組織來說至關重要的功能,那麼您就需要有能夠實施任何潛在變更的活躍貢獻者。只要您的變更與專案目標保持一致,您就可以通過您的貢獻對專案方向產生一定影響。
但是,您需要注意一下您參與這些社群的方式,以避免您的貢獻被錯誤認知或出現其他問題。每個開源專案在規範、期望和流程上都有細微的差別,所以在貴組織開始提供貢獻之前,需要全面地瞭解這些專案。可以通過讓人加入社群並花一些時間觀察專案,或者聘請已經在社群中具有良好的參與記錄的人等方式來實現對專案的全面瞭解。
如何管理開源專案
第一眼看上去,開源專案可能顯得很混亂。完全不瞭解開源軟體的人常常會想知道,隨機的一群人寫出的程式碼如何能做出被數百萬人使用的穩定產品。但他們很快就會意識到,這並不是開源軟體的運作方式。幾乎每個開源專案都有一定的結構,而最好的專案都會在專案網站或檔案中清晰地闡述其結構和專案治理。(GitHub 的貢獻者指南提供了很好的專案解析概述。)
儘管專案之間確切的管理模式有很大差異,但還是存在一些共同點:
- 負責人:最起碼應該有專人負責效能、釋出以及其它活動的最終決策。在某些情況下,這些活動由一個人負責,例如,Linus Torvalds 是原創人員,並且對與 Linux 核心相關的任何事務擁有最終發言權。而在其它專案中,可能有一個或多個委員會負責專案的各個方面,如管理 Node.js 專案的核心技術委員會。
- 維護人員:大多數領導者會將一些決策委託給那些負責維護專案特定部分的人員,而在大型專案中,這些維護人員還可能將其中部分工作委託給其他負責人員。例如,Linus Torvalds 將 Linux 核心檔案決策權委託給 Jonathan Corbet。
- 提交者:一些專案中,有一些曾為專案做貢獻的人,他們被認為足夠可靠且負責任,所以被允許直接提交至專案的全部或部分內容,而不必提交給維護人員審查。而對貢獻存有疑慮時,這些提交者的貢獻仍然需要由維護人員或專案領導者進行審查,而且這些貢獻可能被拒絕。
- 貢獻者:許多人通過程式碼、檔案和其他方式為開源專案做貢獻。這些貢獻在被採納之前通常需要一位經驗豐富的提交者和/或維護人員的審查。
- 使用者:開源專案中最重要的一群人可能就是實際使用該產品的人,因為使用者給予專案一個目標並幫助其發展。這些有價值的社群成員可以提供有關效能、漏洞及其他更多方面的反饋。
社群是可以成就一個開源專案,也可以搞垮一個開源專案的因素之一,所以擁有一個強大的、充滿活力的且多樣化的開源社群對專案的成功至關重要。上文列出的角色中的所有人都是這個社群的一部分,同時還有人在專案中填補了檔案編制、市場營銷、使用者支援和其他多方面的關鍵角色崗位。
貢獻過程如何運作
貢獻過程在開源專案之間有所不同。例如:
- 專案擁有帶有關於編碼風格、語言、格式、漏洞/工單號、釋出時間等資訊的不同的指南。
- 有些專案要求籤署貢獻者協議,而其他專案則要求釋出人的署名或其他流程。
- 有專案可能要求將修補程式釋出到郵件列表中,而其他專案會提出合併請求。
這些只是貢獻形式可能會有所不同的幾個方面,因此以閱讀有關如何貢獻的檔案作為開端是非常重要的。許多專案都會將此檔案以“貢獻指導(CONTRIBUTING
)”或“自述檔案(README
)”的形式,包含在程式碼儲存庫的主目錄中,但如果沒有,您可能需要深入到網站的檔案或社群部分來尋找這一檔案。為了確保您能夠準確理解一個特定專案所期望的貢獻行為,如果能獲取的話,閱讀一些其他的檔案、社群指南和行為規範也是一種好方法。
如果您是第一次為專案做貢獻,您可能需要考慮找一位導師或經驗豐富的專案成員,他們可以在您準備您的第一次貢獻時審查您的工作並提供一些反饋意見。
在按照文件中描述的流程提交貢獻後,您將需要能夠對反饋做出迴應。常見的反饋可能包括有關某些事物如何運作或您為何選擇某個特定方法的問題,以及改進建議或變更要求。這種反饋有時可能會是難以迴應的,因此假定這些反饋的本意是為了讓您的貢獻變得更好,並且避免讓自己陷入防備狀態會對回饋反應有所幫助。在您的程式碼被採納之前,您可能需要經過幾輪的重新提交和補充反饋,甚至在某些情況下您的貢獻可能會被拒絕。有些事物不被接受可能有多個合理的原因,所以如果您的程式碼被拒絕,不要介意,而且如果可能的話,嘗試瞭解更多關於您的貢獻未被接受的原因,以幫助增大您下一個貢獻被採納的機會。
請記住,如果您的貢獻被採納了,您可能會被期望來長期維護這個貢獻。對於較大的貢獻、新效能的提出或獨立的程式碼而言尤其是如此,例如一個特定硬體的驅動程式。而對於較小的貢獻和漏洞修復而言,則不太可能被期望有任何長期維護。
組織如何進行開源貢獻
多年來,一些開源專案與那些使用或貢獻於這些專案的公司或其他組織之間的關係有點難以明確。組織通常建立業務關係的方式不太適合開源專案,因此一些組織很難了解如何以富有成效的方式進行開源貢獻。另一個挑戰是,當組織的需求與開源專案的需求不一致時,組織會表現得比較自私或讓人感到棘手,這會導致開源社群對組織的貢獻的背後動機產生懷疑。過去,一些組織曾嘗試做出與開源專案目標不一致的巨大貢獻,而且在某些專案中,這樣的歷史教訓可能會讓開源社群更加難以信任組織。
但是,也有許多成功案例,例如 Linux 核心,該專案中的組織就以有意義的方式進行了開源貢獻。組織為開源專案做貢獻的最常見和最簡單的方式,就是向花費大量時間投入開源專案的員工支付薪酬。為了讓這個方式取得成功,這些員工需要了解該專案的貢獻流程和規範,以提高他們的貢獻被接受的可能性。如果您的組織剛開始接觸一個開源專案或者剛開始接觸開源,則您應該考慮聘請已經參與過貢獻並且在您所想要進行貢獻的開源專案中廣為人知的人員,以便他們能夠為組織提供關於更可能在專案中取得成功的貢獻方式的指導。經驗豐富的貢獻者可能很願意作為導師來幫助您的員工, 因為他們追求開源職業發展之路。(參閱我們關於招募開源開發人員的指南)
在大多數專案中,組織都有其他的方式來參與其中,但這些方式可能會因專案的不同而有所差異。開源專案和支援這些專案的基金會常常需要組織可以提供的資源,包括基礎架構、資金、市場營銷服務、法律服務等等。許多專案允許企業通過向開源專案提供資金和/或人員,來以更加正式的方式贊助或參與專案,作為回報,企業可以獲得專案中的一些顧問的角色或提升企業的曝光度。
例如,Node.js 基金董事會由企業成員代表、技術指導委員會代表和個體成員選出的代表組成。含董事會部分成員在內的企業成員為小型組織支付的費用從 5000 美元到 250,000 美元不等。雖然每個專案的贊助資格或會員資格的獲取方式略有不同,但為開源專案提供資金有助於開源專案支付其費用開支並且可以幫助專案取得成功。
一群多樣化的組織為雲原生計算基金會的 Kubernetes 專案做出了貢獻
在參與開源專案時,如何成為良好的企業公民?
一般而言,如果說本指南和開放原始碼有一個潛在主題的話,那就是每個專案都是不同的。每次您加入一個開源專案時,您都需要花一些時間來確定自己在專案中的定位並學習專案是如何運作的。對於參與開源專案的組織來說,每個員工都需要為他們參與的每個專案完成這個學習過程。這裡有一些可以幫助您正確地邁出第一步的建議。
- 加入社群——每個社群有著稍微不同的參與方式和不同的溝通渠道。請閱讀檔案以瞭解社群並加入關鍵溝通渠道。這些渠道可能包括郵件列表、論壇、網際網路中繼聊天(IRC)、Slack、漏洞追蹤器、原始碼庫等等。
- 先潛心學習——加入社群後,您需要先潛心花費大量時間去閱讀檔案資料,在您開始進行開源貢獻之前先了解和吸收社群文化。您將希望在參與社群之前瞭解這個社群的規範和期望。您花費在閱讀和傾聽上的時間越多,您的第一份貢獻被很好地接受的可能性越大。
- 瞭解專案管理——在進行貢獻之前閱讀有關專案管理和領導的文件或網站內容。您將希望瞭解專案中的決策是如何制定的,以及是誰為各種型別的貢獻做決策的。
- 從小事開始——以解決一個簡單的漏洞或檔案修復作為開端。瞭解貢獻過程並修正對貴組織的需求來說無關緊要的小貢獻中的錯誤是會更容易的。在不太重要的較小貢獻上犯錯誤,及時修正並積累經驗,然後逐步發展到有能力做出組織需要的更為複雜的貢獻。
當您的組織理解了剛開始時如何做出那些較小的貢獻後,您將需要在這些貢獻的基礎上,開始為專案做出更大的貢獻,並對專案產生更大的影響。
- 在活動中建立關係——個人層面和組織層面的關係是參與開源社群的一個重要方面。與其他專案成員建立長久關係的最佳方式之一就是參加活動。我們作為他們電子郵件或線上操作另一端的人, 沒有任何方式可以像親自見面這樣,有助於瞭解他們。這些活動有著來自許多組織的專案負責人和產品熱心使用者的多樣人員構成,他們會直接參與到活動當中,通過贊助、展位和樣品來展示其所在組織是如何進行貢獻的。如果沒有贊助組織的資金支援,這些活動中的大多數活動將不可能允許我們聚集在一起互相學習同時幫助實現專案目標。
- 儘早並經常性地參與社群——一些組織會犯的錯誤是在內部開發大量程式碼,然後將它們轉儲到開源專案中的錯誤,這並不是參與社群的積極方式。事實上,開源專案可以很複雜,看起來似乎顯而易見的變更,可能會對專案的其他部分產生持續的副作用。任何重大變更在實施之前可能都需要經過一些社群討論,以確保其沒有副作用,並且確保解決方案與專案更廣泛的目標保持一致。在您花費過多時間在建立一套程式碼之前,與社群討論它,這將有助於您把注意力集中在問題本身,而不是特定的解決方案上。(請參閱 JonCorbet 的關於如何參與 Linux 核心社群的指南 )
- 向上遊做貢獻——這一點是指將您對開源專案所做的任何更改反饋給原始維護人員,以便更改能夠被納入之後釋出的軟體版本中。如果貴組織剛剛接觸開放原始碼,您可能需要花費一些時間教育您的員工關於向上遊做貢獻的重要性。在某些情況下,人們可能認為做一個快速而又隨性的補丁來在您的基礎架構中運作會更容易,而且這樣做不用費心去清理它,也不用經過使之被上游專案接受的過程。
但是,從長遠來看,比起讓上游專案接受它所耗費的精力,速成補丁需要在每個升級週期中被測試、更新與重新應用幾乎總是需要耗費更多的時間和精力。這種行為也可能在社群中被看作是自私的,因為別人也可能從您的修復中受益,所以它可能會損害貴組織在開源社群中的聲譽。
向上遊貢獻程式碼的最佳方式
在您的組織內部:
- 基於正當理由而決定向上游貢獻。
- 設計和執行程式碼時,要考慮到上游。
- 採取“上游優先”政策。先將補丁提交給上游,然後再在自己的下游產品中使用補丁。
- 保持您的開發人員一直參與到開源專案中,即使是軟性參與。
面向專案外部:
- 確保您的貢獻對他人是有用的。
- 遵循恰當的編碼風格。
- 參與專案提交過程的工作。
- 提供關於您的貢獻的檔案與說明。
- 聽取反饋並採取相應行動。
- 保持耐心並反覆修改程式碼直至被接受。
對於組織來說,最具挑戰性的事情之一就是學會如何在開源專案中獲得影響力。僅僅因為您的組織很重要,並不意味著您可以期待在沒有贏得開源社群的尊重的情況下就像重要人物一樣被對待。影響力源於參與,而且一些貢獻於開源專案的人在證明他們是可靠且負責任的後,最終將隨著時間的推移贏得具有更大影響力和領導力的地位。
您還應該預計出現一些意見衝突,並準備好專業地去解決這些衝突。當有人不同意貢獻的決策、方法或風格時,審查過程可能會變得非常激烈。確認反饋始終是聚焦在貢獻上而不是變得個性化,同時保持冷靜和專業是很重要的。請記住,您在開源專案的參與過程是公開的,且可能會永遠留在網際網路上,一次失控的激烈討論,可能會以組織或個人的形式在往後又返回來困擾您。因為所有的這些參與過程都是非常公開的,所以為您的員工提供一些關於與難以相處的人打交道與解決衝突的培訓可能是一個好方法。
如何制定您的開源貢獻戰略
擁有一個仔細斟酌且周到的開源貢獻戰略,不僅有助於在參與開源專案時為您的員工提供指導, 還可以幫助您向貴組織內的高階管理層說明開源專案的參與過程。開始時要看看組織的整體業務目標,以確定您的開源工作該如何適應貴組織的更廣泛的戰略,這是很重要的。(請參閱我們關於制定開源業務戰略的指南。)通過明確地將您的開源貢獻戰略與組織的戰略性工作掛鉤,您可以向高階管理層展示為什麼這項工作對組織至關重要,並幫助您的員工瞭解其貢獻的影響。
“領導層的支援以及對開源是您戰略的業務關鍵部分的認同都是非常重要的。您應該真正理解公司的目標以及如何在您的開源戰略中實現這些目標。”
Nithya Ruff – Comcast 開源實踐高階經理
一旦您確定了一些與業務目標一致的目標和戰略,您就需要制定一個實施計劃。以下這些問題將有助於您思考您的計劃中可能需要被解決的一些問題:
- 為什麼這些貢獻很重要?
您很容易直接進入就開始談論您計劃要做的所有大事,所以不要忘記先列出為什麼這些工作對組織來說至關重要且具有戰略意義的有力論據。
- 我們在組織內使用哪些開源專案?
花一些時間去評估目前已經在整個組織中使用的開源專案,以確定哪些開源專案對您的業務具有戰略意義。您可能想要將您的評估聚焦在幾個地方:關鍵業務基礎架構(運營)、影響您產品釋出能力的開發和部署工具,以及對於面向客戶的產品或服務非常重要的軟體。
- 我們應該以什麼專案作為貢獻目標?
大多陣列織使用許多開源專案,因此確保您的貢獻計劃著力於那些最重要的專案是非常重要的。一個專案不在您的貢獻目標清單上並不意味著人們不可以貢獻於這個專案,這只是表示這個專案不是貴組織所重點關注的。如果一個開源專案對於您的業務至關重要,並且有可能導致嚴重的工作停止或中斷您為客戶提供服務的能力,那麼這個開源專案很可能就是您進行開源貢獻的一個良好的備選目標。
- 我們已經做了哪些貢獻?
在某些情況下,您可能已經讓人對開源專案進行了變更。他們可能正在建立內部使用的補丁,或者他們可能已經在將這些補丁貢獻回上游專案以避免維護它們。在評估您的員工中是否已經有人可能具備開源貢獻的技能和興趣的同時,請花一些時間與您的內部團隊交流以找出您可以作為發展基礎的潛在貢獻。
- 我們是否已經擁有相關專業知識,或者我們是否需要聘用專業人員?
正如本指南前文所述,尋找有能力做出貢獻的人與有能力與社群工作並促使社群接受貢獻的人是非常重要的。如果貴組織中已經有人為這些專案中的一部分專案做出了貢獻,那麼您可能可以利用現有的員工基礎。如果沒有,您應該考慮聘請已經為專案做出成功貢獻的人。與任何計劃一樣,您需要確保您擁有成功所必需的資源和僱傭預算。
- 我們需要哪些資金用於專案贊助資格/企業會員資格?
檢視您所選擇的專案的管理模式,以確定是否有企業會員資格、專案贊助資格或專案負責基金會的選項。這些選項提供了資金來幫助專案取得成功,而且在某些情況下,這也可以幫助貴組織以顧問的角色更多地參與專案或提高貴組織對專案的影響力。大多數開源專案都會舉辦會議,而且除了直接為開源專案提供資金支援之外,您還應該考慮贊助專案會議,這可能是一個很好的宣傳您工作的方式,同時也是與您可能想要招募的人才見面的好地方。
- 我們應該如何提升我們的開源工作?
對您的組織來說,營銷或提升您的開源貢獻可能會非常麻煩,這就是為什麼在您的實施計劃中包括如何營銷或提升您的開源貢獻,以確保每個人都知道您計劃如何向公眾介紹您的貢獻是非常重要的。贊助專案會議或其他活動和在這些會議及活動上進行報告,可能是提升您正在進行的開源工作並招募貢獻者的一個好方法。特別是不要忽略在您擁有員工的本地使用者群體中的參與。贊助這些本地群體並讓貢獻者進行報告可能是招募熱衷於特定開源專案的本地人員的好方法。
- 我們需要什麼樣的貢獻指南或流程?
這些指南及流程應該更多的是關於幫助人們為開源專案做出成功貢獻,而關於規章制度的內容則較少。如果人們有指南和清單的話,可能有助於確保他們擁有所需的一切條件,從而可以在沒有發生許可或保密問題的情況下做出成功的貢獻。尤其是對於新的貢獻者來說,這也有助於他們在進行貢獻之前有一個可獲得的內部審查流程來作為獲取反饋意見的安全之處。
- 我們需要提供什麼培訓?
針對開源貢獻最佳實踐案例的培訓,以及一些關於開源社群參與的許可、管理、以及規範的一般性開源培訓將會對人員有所幫助。有關衝突解決、和難以相處的人打交道以及其他人員技能的培訓也有助於避免之後的問題。您的培訓計劃還應包括提供經驗豐富的開源貢獻者作為新貢獻者的導師的專案,以此作為隨著時間的推移擴大您的貢獻工作的一種方式。
- 我們將如何確定計劃是否成功?
每個計劃都應該有成功標準和一個用於衡量您是否實現目標的計劃。這應該直接來源於您的戰略,以確保您正在追蹤的是那些對貴組織而言最重要的活動,而不是那些最容易測量的活動。如果您需要測量和指標工具,開源 GrimoireLab 專案是一個很好的開始。(請參閱我們關於衡量您的開源專案的成功的指南。)
- 我們是否需要一個開源辦公室來管理所有的開源工作?
所有這些都需要思考,而且擁有一個開源專案辦公室或負責實施開源計劃的專職人員將會有所幫助。至少,您會希望有專人負責將流程和培訓落實到位,提供許可證指導,回答高階管理層或貢獻者提出的問題,以及將更新內容傳達給整個組織。(請參閱我們關於建立開源專案辦公室的指南。)
精通開源貢獻的 11 個技巧
如何為組織中的開源貢獻構建一個健康的環境:
- 建立政策和流程來指導開源貢獻
- 成立一個團隊來監督所有開源貢獻的審批
- 將貢獻集中在可以啟用您的技術的領域
- 為貢獻者提供所需的IT基礎架構和工具
- 為您的員工提供最佳開源貢獻案例的培訓
- 追蹤貢獻,衡量影響,改進與溝通
- 建立導師專案以培訓經驗不足的開發人員
- 提供貢獻指南,說明如何做、該做什麼和不該做什麼
- 為開發人員提供無障礙的開源法律支援
- 從您認為最有價值的開源社群中招募員工
- 始終遵循每個專案特有的社群流程/實施規範
結語
開源專案會留在這裡,而且它們在大多陣列織向客戶提供產品和服務的能力方面發揮著關鍵作用。作為一個組織,如果您想要影響驅動您的業務取得成功的開源專案,您就需要參與其中。為貴組織制定可靠的貢獻戰略和實施計劃,將助您走上通往成為一名優秀的企業開源公民之路。祝您好運!
這些資源是與 TODO(Talk Openly,Develop Openly)組織合作建立的, 該組織是 Linux 基金會中專業的開源網路組織。特別感謝奉獻自己的時間和知識來製作這些綜合指南的開源專案負責人。參與制作的公司包括 Autodesk,Com- cast,Dropbox,Facebook,Google,Intel,Microsoft,Netflix,Oath(Ya- hoo + AOL),Red Hat,Salesforce,Samsung和VMware。如想了解更多資訊,請訪問:todogroup.org
訂閱“Linux 中國”官方小程式來檢視
相關文章
- 開源社群指南
- 趣說開源|為什麼要參與到開源社群中?
- 企業開源指南:建立一個開源專案
- 企業開源指南:啟動一個開源專案
- ONAP開源社群
- 江民科技加入尤拉開源社群,與開源生態共同發展
- 參與開源專案很難嗎?
- 開源無疆|京東雲參加2019開源年會,助力開源
- 如何去參與一個開源專案
- 5W1H聊開源之Why——為什麼要參與開源?
- 5W1H聊開源之Who和How——誰、如何參與開源?
- 開源社群從未如此繁忙!
- 誰在主導開源社群
- [深圳] 華為開源軟體部招聘開源社群專家
- 開源聖樹“建木”完成捐贈木蘭開源社群
- 龍蜥社群&龍蜥理事長分獲 2023 開源創新榜“優秀開源社群、優秀開源人物”獎項
- 人人都可以參與開源!龍蜥社群最不容錯過的開發者活動來了
- 【 FlutterUnit 食用指南】 開源篇Flutter
- HTTPDNS開源 Android SDK,賦能更多開發者參與共建httpdDNSAndroid
- MySQL等開源軟體企業版MySql
- ThinkSWN開源社群問答系統 免費開源 歡迎使用
- 國內87.4%企業使用開源技術,開源風險如何規避?
- 大咖說·對話開源|企業如何用好開源資料庫資料庫
- 開源電子書回饋社群
- 無需搭建環境、全開源,潮汐開源社群為安全從業人員增效賦能
- 微軟開始擁抱開源社群 exFAT檔案系統向Linux開源微軟Linux
- 開源依賴項管理指南
- 百億級企業級 RPC 框架開源了!RPC框架
- Focus 聚焦社群 v0.2.0,GoFrame 開源社群專案GoFrame
- 一刻社群程式碼開源啦
- 我參與 Seata 開源專案的一些感悟
- 尋找在 GitHub 上參與開源專案的方法Github
- 【新晉開源專案】內網穿透神器[中微子代理] 加入 Dromara 開源社群內網穿透
- 你願意成為開源的見證者嗎?歡迎參與2018開源調查報告
- 參與到開源的發展建設中開源的建設也需要日拱一卒
- 參與開源之夏 x OpenTiny 跨端跨框架 UI 元件庫貢獻,可以贏取獎金?!這份《OpenTiny 開源貢獻指南》請收好?!跨端框架UI元件
- 紅帽:《企業開源狀態》年度報告
- 阿里開源軟體替換指南阿里