From History to Apache
從歷史系到阿帕契﹣轉職仔的開源之路
回歸
好久沒寫技術部落格了，沒想到上一篇已經是一年前了，這似乎是大多數技術部落格的宿命。技術日新月異令人振奮，但作為軟體工程師，感受到的更多是焦慮和迷失，於是要學的基礎忘記了，承諾的部落格堆滿灰塵，這個職業走在科技的前沿，卻也更容易在刺激中迷失。為了壓抑焦慮，我們不斷在網路裡浮沉，試圖尋找憂慮的解答。
我很幸運，在焦慮的海浪裡看到了岸，於是我沒有在軟體工程裡不斷革新的浪潮裡被淹沒，也找到了努力的方向，如今也達成了一個小小的里程碑。所以接下來我會寫一些關於這一年沒寫部落格之後我在做什麼，我是如何透過開源社團「源來適你」投入到開源貢獻，進而取得開源技術頭銜。
如果你也正因為職涯的不確定性而感到無比焦慮，希望這篇文章可以給你一點啟發，發展職涯的方式不是只有刷題，軟體工程師還有其他條路可以增進自己並讓其他人看見。
文章主要分為 「開源貢獻」和「心路歷程」兩部份，前者主要專注在參與開源貢獻的好處，後者主要是開始參與貢獻後一路以來的感受。
開源貢獻
這個章節說明我這一年透過「源來適你」參與 Apache Kafka 的貢獻所得到的改變和益處，還有給想參加開源貢獻的人一點建議。
關於作者
我是紀登耀（GitHub / LinkedIn），畢業於臺北大學歷史學系，是俗稱的轉職仔，在兵役之後就去了資策會開辦的 Java 培訓班，之後就開始當一個 Web 仔騙吃騙喝。
在職場載浮載沉幾年後，2024 / 04 / 20 發出了在 Apache Kafka 的第一支 PR，從此開啟了自己的開源貢獻之旅，在社群的這一路上從懵懂到熟悉，從道歉到下跪，我能清晰地感受到自己一點點的在進步。而經過這一年的貢獻，我在 2025 / 04 / 04 受邀成為 Apache Kafka Committer 。我在這段期間總共提交了 171 個 commits，這其中也包含了一些大型的貢獻，比如 Log4j2 的遷移等等，而這一切都不是一年前的我可以想像的。
為什麼開始貢獻開源
其實在一開始從培訓班結業時並找到工作後，我並不覺得寫程式是一件很困難的事情，甚至覺得工作算是很輕鬆，完全處於達克效應的愚昧之峰，但是因為一些契機開始參與技術社群之後，才認知道軟體工程是一門高深的技藝和學問，且這些年經歷了 COVID-19、區塊鏈爆發和 AI 的興起，這些大事件的為軟體產業帶來了一波一波的革新浪潮，無一不讓我感到很焦慮，我曾經嘗試隨著海浪起舞，不斷追逐新技術，但我發現海浪終究會平息，而且下一波海浪到來並不一定是往同一個方向，為此我開始找尋可以真正讓我在這些海浪中存活下來的方法。
也就是在這時，我接觸到了「源來適你」這個社團，並且發現相較於其他開源社團著重推廣，這個社團是以實作、貢獻為主，而且還有對應專案的專家作為 Mentor 指導社團成員，最重要的是這些貢獻和知識都是帶得走的，所有的努力也都會作為 commit history 留下，於是在參與過幾次線上會議後，我下定決心要開始投入。
為什麼選擇 Apache Kafka
時也運也，Kafka 本身就是 Event Streaming 裡非常熱門且廣泛印用的領導專案，彼時的我正在以 JD 為導向進行學習，而 Kafka 是一個出鏡率非常高的單字，所以我也在 Udemy 上修習 Kafka 的課程。
恰逢 蔡嘉平 和 Luke Chen 兩位 Kafka PMC 作為 Mentor 在社團的香菜饅頭營裡開辦了 Kafka 小隊，這對於我來說這是千載難逢的機會，除了我比較熟悉 Java 和 Kafka 本身很熱門之外，我也想要從書本以外的地方更加深入地了解分散式系統，所以就順勢投入了 Kafka 的貢獻。
參與開源帶來的好處
這裡會說明參與開源貢獻給我帶來什麼好處。
- 提昇自己對於閱讀程式碼的能力
Kafka 有著 140 萬行程式碼，單論 Java 就有 120 萬行，在這麼大的 Code Base 裡 trace code 並不容易。在初期還是菜鳥的時候，光是找到關鍵程式碼就必須花費大量時間，這也迫使我花費大量時間去閱讀程式碼，為了更有效率的 trace code，也特別再去研究 IDE 有什麼更進階的功能可以幫助我，而這些訓練都不只是侷限在這個專案裡，Kafka 給了我更大、更有挑戰性的環境讓我鍛鍊自己的技巧。
- 了解大型系統的設計哲學
以 Backward Compatibility 為例，Kafka 是一個超過十年的大型系統，積累了龐大的使用者群體，在不斷加入新功能的同時，也必須考慮舊版本的使用者，因此每個 feature 都必須在極大程度上保證兼容性。
在 Kafka 4.0 版本以前，Kafka 可以跟任意舊版本的溝通而不會出現故障，直到 4.0 才因為架構大規模改變才捨棄 2.1 以前的版本。因此，任何一個改動最前提的要求就是考量到兼容性，這樣對於兼容性的要求是在日常開發經驗中很難遇到的。
- 練習技術提案
Apache 專案通常都有 Improvement Proposal 的制度，以 Kafka 來說，因為對於兼容性的高度要求，只要涉及到公共 API 的改變，都必須撰寫 KIP (Kafka Improvement Proposal) ，這些提案根據專案不同都有自己要遵守的格式，撰寫完成之後，還必須把 KIP 丟到 Dev Mail Channel 進行公開討論，而作為提案者，會受到來自各方的詢問甚至挑戰，為了讓提案通過必須一一解決這些問題，而後再發起投票來爭取支持，這些都通過之後才能把提案付諸實現。這是個非常寶貴的經驗，除了可以練習用撰寫技術提案，我也必須替自己的提案辯護，而這些都是使用英文進行，除了鍛鍊思維也對英文寫作能力有很大的幫助。
- 走出舒適圈，接觸自己不熟悉的技術
以往在工作中，不知道大家怎麼使用 build tool？以我來說，Maven 和 Gradle 都有使用經驗，但僅僅只限於非常簡單的定義依賴，但是在 Kafka 這樣發展很久的大型專案來說，基礎的使用是沒辦法滿足需求的。
Kafka 是使用 Gradle 作為 build tool，為了解決對於建構順序和專案需求，Kafka 使用了很多 Gradle 的進階功能，有些用法甚至可以稱之為 hack，如果不是參與了開源，我這輩子大概很少有機會用到 implmentation 以外的關鍵字。
再比如 Python，在參與 Kafka 之前，我完全沒有使用過 Python，但是在 Kafka 之中，System Test 相關的程式碼是用 Python 編寫的，我在貢獻的過程中，也「被迫」要去了解 Python 如何運作，這樣才能解決相關的 issue。雖然我依然不算熟悉 Python，但透過一個現實中的大型專案作為學習入門是非常有趣的，這是很多線上課程都沒有的真實用例。
- 免費向大公司的資深工程師學習
這是一個顯而易見的好處，在這種大型專案的 Committer 或 PMC，通常都已經是在各自公司裡的 Staff Engineer，更有甚者有些人甚至本身就是多個專案的 PMC，堪稱開源神獸，而在開源的世界裡，只要提交自己的 PR，就有機會被這些大神 Review，而他們也能夠針對我們 PR 的不足之處提出洞見，這樣的機會是非常難得的，尤其是他們對於專案都非常熟悉，對於程式碼的品質也有很高的要求，因此在 Review 過程中常常會有出乎意料的收穫，而這些已經在各自領域裡十分傑出的工程師，他們看待問題的思維模式非常值得我們好好學習的。
- 自己上門的工作機會
即使還沒有取得頭銜，在不斷貢獻的過程中就會有一些意想不到的機會自己找上門。因為開源的貢獻是完全公開的，所有人都可以透過 GitHub 或是其他公開管道知道你的貢獻，也因此很多公司的招募人員其實都會透過這些這些公開資訊去尋找潛在的候選人。以我自己的經驗來說，在成為 Committer 之前就有陸續收到 5 ~ 10 個左右的面試邀約，而這些機會是在台灣求職網站基本上是沒辦法接觸到的。
- 自我實現
並不是所有軟體工程師都是在開發大眾會使用的產品，且很可能無法決定技術走向，只能遵循公司既定技術路線，這些因素都很容易讓工程師無法連結自己本身的價值而產生異化感。但是開源不會，不管是選擇大型熱門或是新興的的開源專案貢獻，都可以透過各種方式自由地針對專案裡的技術走向發揮自己的影響力，這樣不僅可以證明自己的實力，也可以在可以明顯地把產出和價值連結，一舉數得。
會遇到的困難 ＆為什麼該加入社團
上一個章節說了很多參與開源的好處，但過程中並不是只有好處，也會遇到種種困難，這裡說明加入「源來適你」可以給你在開源路上帶來什麼幫助，讓你的開源之路更加平坦順暢。
- 初期學習曲線較陡
作為初入開源的小白，第一個要面對的困難就是龐大的 Code Base 但不知道要從哪裡開始，除非是新興的專案，否則這裡是最容易放棄的地方，但是如果能堅持過去，接下來就會順暢很多。如果是社團中有在 Own 的專案，就會有 Mentor 餵食ㄧ些 Good First Issue，可以很好地在前期幫助新手了解開發流程、建立信心。
- 沒人 Review
新手另外一個容易放棄的點就是興致沖沖提交了第一個 PR 但是放三個月了都沒人來看。關於這點可能的原因很多，可能是大家單純很忙、你的 ID 太陌生或 PR 格式不對，人家連看都懶。在社團中，Mentor 通常是有專案寫入權限的人，因此可以保底有人幫你 Review，持續地回饋才能維持住較高的動力。
- 修 Comments 修到中離
我看過很多新手，在社群裡提交了 PR，但是可能是因為和專案不熟，導致程式碼品質低落，因此 Reviewer 每次 Review 都會留下一狗票的 Comments，很多新手來回幾次之後就會放棄。
這裡更加體現 Mentor 的作用，社團裡每週都有週會，在 Issue 上遇到問題都可以詢問，也可以通過 Slack 頻道進行非同步溝通，其他夥伴也會回應他們知道的知識，幫助你可以更容易解決 Issue 並提交高品質的 PR。
- 找不到 Issue 解
這通常是有一定經驗的貢獻者會遇到的問題，一般的 issue 已經沒什麼問題，但是孤狼一隻，常常會拔劍四顧心茫然，空有滿腔熱血但沒有 issue 可以做，久了很容易熱情消失。
社團中除了 Mentor 會不定時丟出 Good First Issue，偶爾也會有其他同儕分享較大型、可拆分的題目，因此不必擔心沒有事做，只怕自己手速太慢。
開始貢獻之後應有的預期
如果你看到這裡已經很心動，相信你多少對於開源貢獻有點躍躍欲試了，可以找找看社團專案列表有沒有心儀的專案。這邊以個人經驗來說說該以什麼心態、預期來投入。
- 開源貢獻是需要長期且耐心地投入
不管是來練功還是以頭銜為目標，都要認知到開源貢獻至少必須以半年為單位的持續投入才可能建立個人形象，有了好的形象才可以形成正循環。
我覺得開源的世界就像是一個真實的 MMORPG，每個人的行為最中都會為自己建立一個品牌，而這個品牌的好壞會很大影響你在一個專案的推進進度的速度，因此為自己建立好名聲是非常重要的。名聲的建立可以從各方面著手，比如不要只是開 PR，而是好好撰寫 PR 描述，表達思路，或是提前在 PR 裡面標注需要討論的地方，提前留下問題，這樣都可以為讓其他人對你留下好印象。
- 初期投入時不要太挑 Issue
來開源貢獻其實就是希望能夠在技術上有所突破，所以在初期不要太挑 Issue 做，多方涉略，一個大專案中會有許多模組，初期多方嘗試，會對各個模組比較有基礎的認識，等變成熟手之後再考慮要專攻哪個部分。
- 做，做就對了
如果你還在因為各種因素或未知而遲遲沒有行動，我的建議是不要在躊躇，因為很多顧慮是會在過程中迎刃而解的，就算最後發現開源貢獻不適合你，也不會有任何損失，反而是在猶豫中浪費的時間是最可惜的。
總結
最初的我其實只是抱持著學習的心態來參與社團，但隨著投入的越深越能感覺到自己的成長，而獲得頭銜對我來說更像是社群對我貢獻的肯定。雖然現在有了頭銜，但我完全不覺得自己是一個 Kafka 專家，反而更覺得由於多了頭銜，自己必須要更努力去了解這個系統才能不辜負這個榮譽。
非常感謝「源來適你」提供了一個這麼好的環境讓我可以用最低的阻力參與世界級專案的開發，五年前我從資策會離開時連 Camal case 和 Snake Case 都還分不太清楚，更想像不到的會有今天。
我也誠摯地邀請所有渴望證明自己或是因為焦慮而迷失的工程師來參與到開源之中，這條路雖然在台灣不是顯學，但絕對值得嘗試。
社團目前除了寶寶照顧級的開源貢獻指導之外，也舉辦各種線上、線下活動，除了是讀書會、科技開講等固定節目之外，還有實體工作坊等等，即使你不參與開源貢獻也可以從中學到很多。另外，社團目前也透過 OCF（開放文化基金會） 開設了捐款帳戶，如果你覺得社團很讚，行有餘力也請不吝支持。
另外社團已經培育了多位 Committer，較為近期的就有： 哲佑、Nary 等社團的明日之星，而且社團也由於驚人的能量而被國內和國外的媒體採訪：
- 戰鬥力最強的取暖小圈圈：專訪源來適你社群蔡嘉平 — 軟體自由電子報
- kafka community spotlight: TAIWAN — 2minutestreaming
心路歷程
這篇會更像是這一段旅程的一個總結，所以沒興趣可以跳過。
楔子
2024 年初，彼時我還在和自己私人讀書會群組裡的夥伴每天刷題，討論更面試常被提及的演算法，除此之外，我還在密集準備 AWS SAA 的考試，企圖在這些大家習以為常的賽道裡實現彎道超車。每天的任務除了刷題以外，還會過濾 JD，根據 JD 內容來找到自己不足之處，並且抽空閱讀分散式系統的書籍，這是我和夥伴每天的日常。雖然日子充實，但接連幾次面試的失利卻開始讓我懷疑自己，LeetCode 難免會碰到自己不會的問題、熟讀知識卻被說沒有實務經驗、證照加分有限，雖然有拿到幾個 Offer 卻始終不是心儀的機會，這讓我開始思考，到底有其他條路來拓展職涯，可以把書上的知識跟實際的產出做結合來加強自己？
此時，在網路衝浪時看到了一則活動訊息，成為我開始投入開源的起點。
當頭棒喝
我有想過之後可能會遇到挫折，但沒想到這麼快。我的麻煩在第二支 PR 就來了，這個 issue 還是我在「微醺饅頭」的活動現場領到的。當時我以為是簡單的 Scala to Java 改寫，沒想到由於缺乏關於專案上下文的知識，我拖了整整 17 天才合併，期間喜提 124 的 comments。
當時除了社團 mentor ＠蔡嘉平 以外還有一個國外大公司的 Staff Engineer 在幫忙審閱，每次提交一次 commit 就會收到 10 個左右的 comments，真的讓我很焦慮也很灰心，直接開始懷疑人生。
最終合併之後，嘉平請我思考要不要繼續貢獻。當時是我最接近放棄的一次，我也確實覺得很丟臉，但是我想了一想，我要因為自己可悲的自尊心放棄這種機會嗎？丟臉是丟不死人的，但抱大腿的機會是真的很少，所以我決定繼續厚臉皮的留下來參與貢獻。
擺正心態
有了前面的教訓之後，我真正的認識到這是一個長遠的學習過程，我開始投入更多的時間在專案上，除了貢獻程式碼之外，更多地去了解專案本身，每次社團裡的週會也都積極的參加，這很像是大學時期的 office hour，我都盡量把問題整理好，一次提問。
沒有 Issue 做的時候我就會閱讀相關書籍，補充知識，比如 《Apache Kafka: The Definitive Guide》和 《Designing Data-Intensive Application》都是在貢獻初期讀完的。
順帶一提，「源來適你」除了各大開源專案的社團之外還有其他活動，比如讀書會，那時透過讀書會的指定書本也是 DDIA，透過參與讀書會不僅加快了學習進度，也更了解分散式系統，更是在貢獻 Kafka 的過程中跟書中的知識互相印證，形成了正向循環。
步入正軌
開始貢獻兩三個月之後，跟相比初期，我處理一個 issue 的時間有顯著的下降，能夠更快地 trace code，找到問題的核心。也就是在這個時候，我開始覺得「取得頭銜」不再是一個不切實際的目標。考量到如果佛系參與的話，會花費很久的時間才能達成目標，為了加速這個過程，我開始給自己訂 KPI，也就是每個月至少要被 merge 10 支 PR。
現在回顧，我很慶幸自己有給自己設定這樣的小目標，以當時來看，這個 KPI 是有點超出我的能力範圍的，我必須更專心的投入才能勉強達成，這逼迫我不能只做社團裡丟出來的題目，如果 JIRA 上有沒人接手的題目我也會去嘗試，更甚者會去注意程式碼有沒有還沒發現的問題。這種壓力幫我養成了上面這些習慣，我開始習慣下班到家就開始做貢獻，假日也可以維持較長時間的專注，根據不精準計算，平日可以至少投入 4 小時，假日則是 8 小時，這樣的投入大大加速了我了解 Kafka 的速度。
開花結果
從開始貢獻到現在，時間過得飛快，我也見證了很多社團和 Kafka 的大事，比如 SITCON 擺攤、嘉平一拳打出本不在規劃內的 3.9 版本、竣陽的明星三缺一、Stan 對於社團的採訪、不斷拖延的 Kafka 4.0 和 黃金流沙饅頭營⋯⋯
即使是在寫文章的當下還是覺得晃如隔世，微醺饅頭營彷彿只是昨天的事情，對我來說，社團的意義已經不只是大家聚在一起貢獻開源、討論技術而已，我真的透過開源結交了來自各個產業、天賦異稟的人，源亦是緣。
到現在成為 Committer 這件事對我來說還是有點不真實。雖然我已經達成了當初設定的目標，但我知道自己還差得很遠，接下來也會努力往 PMC 努力邁進，也很期待未來繼續跟大家、社群一起共事，希望今年大家都可以心想事成，成為 Committer，讓國外知道台灣也有很多強大的開源技術人才。
鳴謝
第一個一定要感謝 蔡嘉平 ，除了技術的指導之外，更常常要幫我闖的禍道歉下跪，如果不是嘉平我早就死在開源路邊了，真的除了感謝還是感謝，另外作為社團的發起人不僅要運營社團還要兼任 Kafka 組的饅頭，還是 Kafka 上最活躍的 Reviewer，這種執行力和活力真的是我從來沒見過的，真心 Respect。
另外也我也要很感謝同時期一起貢獻的夥伴，特別是竣陽、博安、冠博，我們四個一直是社團裡最活躍的四個貢獻者，這一年有舊人離開也有新人加入，但我們四個一直都在這裡，這其實也給了我強烈的競爭心和堅持下去的動力，沒有你們我一定沒辦法這麼有動力。
特別感謝竣陽，從私人讀書會時期就是一直互相鼓勵的夥伴，同是轉職仔我們都堅持到了現在而不是甘於平庸，你真的是我見過最持久最大膽的人（各方面）。
額外感謝生生，在我早期進入社團時就是非常友善健談的人，也提供了很多學習資源給很菜的我。（前職業選手轉來寫 Code 真的太酷了）希望可以早日見面！也祝福你可以在職涯上可以武運昌隆！
最後特別感謝 Luke 大大，雖然因為工作繁忙的原因，比較少在社團出沒，但三不五時就會丟一些 Issue 到頻道裡，根本是頻道裡的聖誕老人。這次能夠過五關斬六將也是多虧 Luke 提供了一個非常大的舞台，希望您生活順遂平安！
