近年來，中國開發者已經成為全球開源體系中的重要力量。據不完全統計，中國的程式碼在全球開源社群的比重已佔 40% 左右，目前全球 6000 多萬開發者中，至少有 2000 多萬來自中國。
開源是一個公司技術影響力的表現之一，走向社群與其他生態合作，拓寬技術的應用領域，為外部需求貢獻的同時也能讓自身技術走向成熟。
過去的 2021 年，螞蟻的技術同學和全球各地的開發者們，共同參與到開源社群的建設和維護。
2021 CNCF 中國區 TOP10 的貢獻者中，有 4 位來自螞蟻集團。 過去的2021年，螞蟻的技術同學和全球各地的開發者們，共同參與到開源社群的建設和維護。其中兩位技術同學主要參與了 Dragonfly 和 Nydus 這兩個互相關聯的開源專案。
\
Dragonfly
Dragonfly 是一個開源雲原生映象分發系統，主要解決以 Kubernetes 為核心的分散式應用編排系統的映象分發問題，2020 年晉級為全球著名開源社群 CNCF （雲原生基金會） 孵化專案。
Nydus
Nydus 是螞蟻集團發起的 Lazy load 原理的映象加速專案，配合 Dragonfly 做 P2P 加速，能夠極大縮短映象下載時間、提升效率，並提供端到端的映象資料一致性校驗，從而讓使用者能夠更安全快捷地啟動容器應用，目前是 Dragonfly 的一個子專案。
小編與這兩位同學，以及他們所在團隊負責人，聊了聊他們眼中的開源。
@ 百驀｜參與 Dragonfly 開源一年
\
開源本身就是一種值得追求的奉獻精神
我是 2020 年開始接觸 Dragonfly 專案的，現在主要參與專案整體 2.0 升級。我們這個專案的維護者來自不同公司、不同團體，比如阿里雲、位元組跳動、去哪兒、Intel 以及上海交通大學等。
我認為專案開發過程中的首要工作就是制定標準，標準制定好了，結果就更容易達成一致。儘管大家來自不同公司，不論技術如何，對程式碼的理解有何分歧。
最終目的都是對專案質量負責，是一個合作和協作的關係。
目前來看，我認為開源在國內的情況大部分是偏實用，需要更多有奉獻精神的程式設計師參與到開源工作當中。當然近幾年國內也湧現了很多技術創業公司，開始投入到開源專案中，而非僅靠程式設計師自己的興趣，利用業餘時間投入。
開源本身就是一種值得追求的奉獻精神
我做程式設計師的初衷是希望憑藉自己的能力去改變一些事情，做開源也一樣需要有一些技術信念。因為開源是個無償的工作，不是商業化的東西，而是希望從中找到可以突破的技術點。
就像我個人非常喜歡的一位程式 David Heinemeier Hansson(DHH) 說過：
“
Writing open source software and giving it away for free has without a doubt been my most professional rewarding endeavor yet。\"
其實做開源的人都比較包容，做事也比較單純，都是為了把一件事做好。
寫程式碼不是 0 和 1
有的程式設計師比較理想主義，看到有問題的部分，就一定要指出並改掉。比如我自己，對瑕疵的東西看不慣，絕對會堅持正確的事情。
寫程式碼要看具體場景、具體需求，沒有絕對完美的答案，但是要時刻督促自己接近完美。
2021 年 9 月 9 日，Dragonfly 2.0 正式釋出，這是我第一個從 0 到 1 完整參與的開源專案，比較有成就感，也很有感情。雖然從開發到第一個版本釋出持續了一年時間，過程中遇到問題也會爭論不休，但真正釋出的那天大家都非常開心和激動。我們同學們都比較給力，我們會一直堅持把專案維護下去，打造雲原生場景基於 P2P 映象和檔案分發標準解決方案。
我個人的短期目標是希望把 Dragonfly 做到 CNCF 畢業，後期會繼續關注雲原生場景映象和檔案分發還有哪些可以解決的問題，深入去研究。
畢業意味著會有更多的人使用，專案才真正開始。
@ Jim｜參與 Dragonfly 開源一年
打造開源專案的全球影響力，
需要標準化和行業共建
我日常參與的開源工作有功能研發、優化專案效能、提高相容性和穩定性、程式碼優化。也會經常在社群參與線上討論，也會花很多時間和精力在 Dragonfly 開發者群、線上社群，幫別人解答問題。
參與開源，不只是使用
參與開源，不是說使用就算參與了，而是要更積極地反饋一些問題，盡力地讓它朝著好的方向持續發展。
比如說一個專案幫你解決了一個專案問題，但專案自己又有一些問題沒有覆蓋到。這個時候，不應該置之不理，或者說沒有涉及到你的使用覆蓋面就不管，而是需要我們及時去社群反饋問題。
這樣的反饋能讓產品越來越好，也能為開源做更多的貢獻。特別是公司內部使用的專案，有些改進不合到上游社群，是沒有辦法讓社群享受到開源的紅利。
同時推進標準化和參與度
要形成開源工作的影響力，標準化是非常值得重視的。一項技術如果不能作為一項標準，那麼很難往外推廣，獲得行業認同。
同時也需要參與度，只有業界夥伴能使用、參與共建，那麼技術才能獲得認同。
推進標準和參與，才能讓專案茁壯成長起來。比如 Google 想把 K8s 推成業界一個標準的容器編排平臺，花了大量的努力做了一個很好的標準實踐，讓業界共同參與或者認同，最終才形成 CNCF 社群。
“人人為我，我為人人” 才能促進開源社群的正向迴圈。
我希望中國的開源專案，能在社群運營上更上一層樓，讓更多的人使用，創造更多的交流，推向更多的人。
我也希望通過自己的努力把 Dragonfly 專案推成畢業專案，結合其他專案做一些更有意義的事。
@ 王 旭｜Nydus 所在團隊負責人
10 餘年開源經驗
OIF 專案 Kata Containers 聯合發起人
木蘭開源社群 TOC 成員
開源團隊管理應避免將目標捆綁在資料上，
以防贏了 commit 輸了社群
我覺得作為一個團隊管理者，管理好開源，最大的挑戰恐怕不是業務壓力，而是自身的勇氣。
總有人會問我一個問題——
怎樣平衡開源和業務 ？
我的思路是 upstream first，也就是上游優先。
把自己按照上游的要求來工作之後，你會在任何時候都考慮為相關合作方留出空間和介面，會把專案的核心功能和擴充套件功能做合適的解耦，會理智地進行妥協和權衡，但不會對風險置之不理。
在採用 upstream first 的工作方式後，業務支援和開源之間是不會有不可調和的衝突的，否則就要謹慎地考慮是不是選錯專案了。
從目標設定來說，我確實有提升開源影響力和培養新人的目標。但在考察的時候，我們側重的是這一年的工作成果是不是真的提升了開源的質量，而非分解到 commit 排名再去比較。
參與開源的工作，更重要的不是考核數量，而是激發參與者的創新 。
我眼中的開源團隊管理 （團隊開源管理）
從目標看，應該是更加偏向於“激發”的 OKR 方式，避免將目標綁死在某些資料上，以防贏了 commit，輸了社群。
從過程看，要有持續的調整和輔導，幫助專案調整或堅定方向、提升團隊開源社群參與能力。
從工作方式上看，要有開源上游一樣的對正確工作方式的追求，讓開源社群工作和自身業務統一起來。
在過去的一年，Nydus 在自身建設以及和 Dragonfly 專案的合作之餘，也保持了與其他專案間的互動。
Nydus 團隊和其主導維護的 KataContainers 安全容器實現了無縫整合。除此之外，Nydus 團隊還和中國最早的 CNCF 專案、企業級開源映象倉庫專案 Harbor 合作，串聯了雲原生映象的完整生命週期，之後又和 NEC 的國外開發者一起合作，共同推進 OCIImage 標準的演進。
就在今年年初，NEC 把 Nydus 為 containerd 寫的 snapshotter 貢獻到 containerd org 裡做子專案。
開源社群裡匯聚的各個開發者的不同需求和背景，會幫助程式碼釋放它們的設計者在寫下時都不能預見的潛能。
開放協作正是開源的價值所在！
