最近很開心收到 Apache Ozone 社群 (PMC Chung En) 的邀請，成為 Apache Ozone Committer。從今年四月底開始貢獻，到現在大約半年。
想趁這個機會，分享一下這半年參與 Ozone 的經歷，以及自己的一些心得。
為什麼選擇 Apache Ozone？
雖然我平常工作就會貢獻開源，但主要集中在 Web 技術上，因為我已經相對熟悉它。我想在工作之餘學習不同領域的技術，特別是在這個快速變化的 AI 時代，感覺需要持續成長。
當時看了不少專案，有些是自己用過的，如 Airflow、Kafka，但很多專案規模都很大，要找到合適的 Issue 感覺很多人都在搶，目前不想這麼卷（未來再說…）。
相比之下，Ozone 對我來說更容易找到切入點。加上過去有使用 S3 的經驗，也曾經嘗試開發過類似的應用，對物件儲存有一些基本認識，而分散式儲存又是我認為長期來說很重要的技術領域，在看過相關文件後，覺得能夠理解也覺得有趣，因此最後選擇了 Ozone。
最後其實也沒有什麼特別的契機，就是某一天決定，不如真的開始動手試試看。
AI 讓學習陌生技術變得容易許多
雖然我有多年的開發經驗，但我其實不是一個很熟悉 Java 的開發者。
不過我一直認為，解決問題的思考方式在不同程式語言之間有很多共通之處，語言本身只是工具。而 AI 的出現，也確實降低了跨入陌生技術領域的門檻，降低了需要學習工具的門檻，讓我們能夠專注於解決問題。
我開始貢獻時，讓 AI 閱讀 README 和 Contribution guide，以了解專案架構和開發流程，還協助我在 Jira 搜尋合適的任務，並創建一些技能來幫我尋找問題。
我最初主要從修復 Tests 開始。
因為測試通常有相對明確的範圍，也比較不容易直接影響 Production 的行為。透過閱讀測試與相關程式碼，可以逐漸理解系統的運作方式，也能順便熟悉專案的開發流程。
當然，AI 並不是永遠正確。
有時候它會忽略邊界條件，或是沒有注意到修改可能造成的其他影響。所以我覺得最重要的，還是要先能夠自己思考、看懂問題。
我一般來說遇到不熟的問題，大部分會先請 AI 解釋資料流、畫架構圖，或是從不同角度說明問題，直到我可以理解為止，再回頭閱讀實際的程式碼，確認這些解釋是否合理。
另外，了解程式碼的修改歷史也很有幫助。有些 Bug 並不是原本的實作有問題，而是後續的修改沒有注意到其他地方的交互影響。
像是 Flaky tests，可能因為背景服務或非同步操作，讓測試結果受到執行時序的影響。最近處理的一些 Metrics bugs，也有類似的情況：原本正確的指標，隨著功能演進，卻沒有同步調整。
即使有 AI 幫忙，有時候還是需要花上好幾個小時理解問題、探索不同的解法，但至少現在能夠更有效率地找到相關程式碼，降低理解大型 Codebase 的成本。
把貢獻當成一種習慣
對我來說，Ozone 有很多值得探索的地方。
分散式系統中充滿各種精巧的設計，例如非同步處理、平行化，以及如何利用 RocksDB 的特性來改善資料處理的效能與吞吐量。
有些設計直到現在我可能都還沒有完全理解，但在閱讀程式碼的過程中，常常能感受到這些設計的巧妙之處。
這也是我很享受參與 Ozone 的原因。
我通常會盡量每天花一點時間在專案上。有時候找 Issue，有時候閱讀程式碼，有時候則是 Review 別人的 PR。當然偶爾還是會因為工作或其他事情而錯過，但也不會因此苛責自己。
遇到比較困難的問題，也不一定要強迫自己立刻解決。真的沒有頭緒，就先放一邊，等之後有更多理解再回來看看。
我覺得這跟運動有點像，重要的是找到自己能夠長期維持的節奏。
我一直相信，卓越來自於每個微小的當下。
Code Review 也是很好的學習方式
另一件讓我覺得很有幫助的事情，就是去 review 別人的 PR。
透過 Review，可以接觸到原本不一定會主動研究的模組，也能了解其他人正在解決哪些問題。
除了閱讀程式碼，我也會試著思考：這個問題為什麼會發生？為什麼選擇這個解法？有沒有其他方式？不同做法之間又有哪些取捨？
每個 PR 都像是一個小型的技術案例，即使不是自己親自實作，也能從中學到很多東西。
隨著參與越來越多，也開始有其他 Committers 主動邀請我 Review PR。這讓我感覺自己不只是提交修改，也逐漸能夠透過自己的經驗幫助其他人。
關於品質與信任
我覺得開源協作中很重要的一件事，就是信任。
當我們提交一個 PR，其實也是希望其他人能夠相信，這個修改是經過認真思考與驗證的。
現在 AI 可以幫助我們完成很多工作，但它也經常會產生一些冗長的註解、不必要的抽象，或是沒有考慮完整的實作。
我自己也會利用 AI 協助 Review、測試，但最後仍然會確認每一處修改是否真的理解、邏輯是否合理，以及是否符合專案的程式碼風格。
另外，我覺得 PR description、Doc comments 也是很重要的細節。
如何讓 Reviewer 容易理解這個 PR 要解決什麼問題、為什麼需要修改，以及採用了什麼解法，其實都會影響協作的效率。
溝通也是如此。我不認為每個人都需要在幾個小時內回覆，但至少應該盡量在合理的時間內回應，而不是讓 PR 長時間沒有消息。
我也不認為一個 Contributor 一開始就必須做得很好。
相較之下，我覺得一個人對品質的態度，以及能不能從 Review 中持續學習、改善更為重要，而不是反覆犯同樣的錯誤。Ozone 社群裡大多數人都相當友善，也有社群成員經常協助 Review，提供許多細節上的建議。
我覺得這些日常的互動，就是社群信任逐漸建立的過程。
成為 Committer 之後
成為 Committer 之後，我目前仍在思考自己如何承擔更多責任。思考可以怎麼更主動協助其他 Contributor，或是整理一些適合讓其他人參與的 Issue。
在 Review PR 時，也需要更謹慎地考慮修改 Merge 之後可能造成的影響，以及是否需要更多熟悉相關模組的人一起確認。
另外，也希望未來能夠更關心 Ozone 長期的發展方向，看看自己能在哪些地方提供更多幫助。
Ozone 裡還有很多我尚未完全理解的設計，也有很多值得繼續探索的地方。
最後
回頭看這半年，其實就是從玩玩看 ozone、閱讀文件、修復 Tests 開始，逐漸接觸不同的問題，也開始參與更多 PR Review。
如果有人想開始參與開源，我會覺得不一定要先完全理解一個專案。
可以先從使用者的角度開始，閱讀文件、測試功能，看看有哪些地方可以改善。很多理解，其實是在實際參與的過程中慢慢建立起來的。
對我來說，能夠參與一個持續發展、真正被許多人使用的專案，本身就是很有價值的事情。
這半年學到了很多，也很感謝 Ozone 社群一路上的協助與信任。
期待接下來能繼續學習，也為這個社群帶來更多貢獻！
若您也對開源有興趣，十分推薦加入台灣本地開源開發者社群 「源來適你 」社群。
發佈留言