近年來，中國開發者已經成爲全球開源體系中的重要力量。據不完全統計，中國的代碼在全球開源社區的比重已佔 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 裏做子項目。
開源社區裏匯聚的各個開發者的不同需求和背景，會幫助代碼釋放它們的設計者在寫下時都不能預見的潛能。
開放協作正是開源的價值所在！
