我是 Stan，過去幾年貢獻跟維護一些 Ruby 的官方專案，像是 IRB（官方 REPL）、RDoc（官方文件產生器）、debug.gem（官方 debugger），以及 ZJIT（Ruby 的新 JIT 編譯器）等等。去年底很幸運地透過累積的貢獻成為了 Ruby 的 committer，以及獲得 2025 年的 RubyPrize。
我自己沒有資工背景（大學念公共行政），也沒有出國留學過，一路上是受到很多人的幫助才能走到這裡。作為台灣人想透過開源專案建立職涯，真的不是件容易的事。語言、時區、文化差異都是挑戰。但如果我可以走到這裡，或許也能給其他人一些經驗參考。
這篇文章整理了我這幾年的心得，大部分內容來自我和 Ruby Taiwan 社群的一場 AMA，所以內容會比較鬆散一點。
我的背景
2013 年在大學開始自學寫程式，畢業前就陸續在 flyingV、愛料理、貝殼放大實習跟工作。2017 年從台灣找到一份英國公司的遠端工作，做了四年後搬到英國，半年後加入 Shopify 的 Ruby Developer Experience team，一直到現在。
我的工作內容是改善 Ruby 開發者的體驗 —— 開發維護 Ruby LSP、type checker、debugger、還有各種開發工具。
認識開源社群是在愛料理工作的時候。那時開始用 Ruby on Rails，偶爾會去看 gem 的 source code，意識到自己「好像可以貢獻些什麼」，並在當時 CTO Richard 的鼓勵下開始嘗試做些小的貢獻。
而我比較積極參與 Ruby 社群，則是在 2015 年夏天去了新加坡的 RedDot RubyConf，年底又去了第一次的 RubyKaigi 之後。那時在會場看到差不多年紀的工程師說「我維護這個專案」、「我是 Rails 前 100 個貢獻者」，覺得靠寫程式跟開源專案就能對一個社群有影響力，是很酷的事情。
給想開始認真貢獻的人
幾個實際的建議：
選跟工作相關的專案
這代表你已經知道一部分的 context，不用額外花時間建環境。你甚至可以跟公司討論：讓我花一部分上班時間修這個 issue、upstream 到原本的 gem，會比在專案裡加 patch 更好維護。這件事情我即便到現在在 Shopify 都還很常做。
用 AI 幫助你了解 codebase
去年我開始貢獻 ZJIT，一個用 Rust 寫的 JIT compiler。我之前沒做過任何 JIT compiler、沒貢獻過 Ruby 本身、也沒寫過 Rust。 但靠 AI 幫我快速了解 codebase，大幅降低了語言不熟的門檻，讓我能夠專心學習 JIT 相關的知識跟快速跟上開發。
以前這些全部都要自己慢慢摸索，現在用 AI 可能半天到一天就能知道專案的架構、每個部分在做什麼、測試怎麼寫。
從小地方開始貢獻
如果你找了一個專案但不知道從何開始貢獻，這些會是我的建議：
- 改善測試 —— 例如把重複的 setup 抽出來變成 helper method、重寫難懂的測試等等。測試不會影響使用者，maintainer 更容易 merge。
- 找 TODO comment —— 那些放在那邊很久沒人修的東西。
- 消掉 deprecation warning —— 讓畫面看起來乾淨。
這些小事可以讓你增加對 codebase 的了解，同時建立和 maintainer 之間的信任。
現在有了 AI，偵測這些東西變得容易許多。但是切記自己要驗證、review 過再開 PR。如果維護者覺得你發 AI slop，沒人會想認真 review 跟接受你的 PR。
反過來說，有些東西不太適合拿來當第一次的貢獻：
- 變更 dependency —— 一個專案的 dependency 對開發流程跟使用者都有很大的影響，在不熟悉專案前很容易做出不正確的判斷。
- 變更 linting rules —— 每個團隊有自己的開發文化跟偏好，在不熟前不適合介入。
投資 40 個小時在同一個專案上
大概要花到這個時間，你才能真的說你了解這個專案的一部分，包括開發慣例跟流程。走到這個階段，你貢獻的東西會比較能放上履歷，學到的東西也會比較多。
在你貢獻滿一定時數之後，你很可能會發現：
- 相關的專案好像也有類似的問題，可以順便貢獻
- 相關經驗可以寫成一篇文章
- 維護者在找人幫忙維護，你是少數有足夠貢獻量的人選
（40 小時是個人經驗，實際數字會因人而異）
用公開的工具問問題
用 GitHub issue 而不是 email。你問的問題別人可能也會有，公開之後 maintainer 只要回答一次，之後有人再問就指向這個 issue。
不用擔心問問題會麻煩 maintainer。任何人變成 maintainer 都知道回答問題是維護的一部分。只要有人願意參與，我們都看得到，這些都是好的。
不過有時候你問了問題或開了 PR，maintainer 很久沒回，不代表他沒看到 —— 很多時候是他知道這很重要，但需要花時間思考，或是有更緊急的事要先處理。大部分專案等一兩週才有回覆是很正常的，避免過兩三天就留言追問。
短期專注，長期開放
如果你已經有貢獻經驗，而且考慮把開源專案變成你職涯的重心，我會建議：短期（1-2 年）專注一個領域，但長期保持開放，不要死守單一專案。
舉例來說，過去五年我的貢獻路徑是這樣：debug.gem → Ruby LSP → IRB → RDoc → ZJIT。
一開始貢獻 debug.gem 時，花了超過 200 個 PR 成為第二大 contributor。後來因為工作接觸 Ruby LSP，開始了解 LSP server 跟編輯器。接觸 IRB 後又慢慢從成為 maintainer 到變成第一貢獻者。接著是 RDoc，從 2024 年到現在已經兩度幫它換皮，現在則是重寫並增加它的功能。去年中也密集貢獻了 Ruby 的下一代 JIT compiler（ZJIT），學習了不少程式語言底層的實作跟優化。
如果剛要開始貢獻的話，目標最好是平常會用的東西，這樣學習的成本會小很多。
像我 2019 年貢獻最多 Rails，那時候還在做 Rails 開發，可以在自己公司的專案裡實驗 patch，確認可以動再送上去。2022 年加入 Shopify 做 Ruby DX 之後，碰不到 Rails 了，自然就轉向貢獻 Ruby 本身和周邊工具。
但過一段時間上手後，也應該試著拓展貢獻的領域。原因有兩個：
第一，如果你的專長太局限，會很難把它跟公司變動的需求做連結，導致你能發揮的場域受限。第二，當你有意識地拓展接觸的專案類型，會幫助你從不同的專案汲取靈感。像我是從 debugger 到 LSP server 再到 REPL，慢慢地從一個單一工具的專家，變成大部分開發者工具都是我熟悉的領域，甚至進一步整合不同的專案。
最近的例子是 AI 開發工具成為主流後，我也開始嘗試開發相關的工具，例如 cctop、ruby-skills、rubydex 的 MCP server 等等。
光寫 code 不夠
這點很重要：光寫 code 其實不夠，還需要透過部落格、活動、演講讓別人看見你的貢獻。
開源社群裡很重要的一點是信任。你要變成 maintainer、要得到別人的幫助，這些全部都是基於「我信任你這個人」。如果你平常不講話，沒有人知道你是誰，信任就會來得比較慢。
我做了幾件事讓社群認識我：
去 Conference
從 2015 年開始，除了疫情那三年，我每年都去 RubyKaigi。不管公司有沒有贊助，我都會自己買機票。每一天都一定會去一個活動 —— 不管是喝酒的還是 coding party。
RubyKaigi 的 coding party 很多 Ruby 和 Rails maintainer 都會去。你可以坐在他們旁邊，跟他們一起討論、一起修 PR。我之前就有一次在 coding party 開了好幾個 Rails PR，maintainer 直接就 merge 了，因為就坐在旁邊嘛。
我第一年去 RubyKaigi 不敢跟 Matz（Ruby 發明者）講話，第二年開始跟他打招呼，之後每年都去 say hi。在 RubyKaigi 見一次、在台灣 RubyConfTW 再見一次、在新加坡 RedDot RubyConf 再見一次。慢慢地他也認識我了。
我當初會加入 Shopify，其實也是因為 2021 年在線上的 Euruko 認識了現在的同事，幾個月後找工作時靠他內推才拿到面試機會。
寫部落格
你可以寫公司裡做了什麼、用了什麼 gem、今天貢獻了什麼 PR。不用很長，分享你學到的東西就好。我建議用英文，因為理論上越多人看到越好。你都已經花時間了，用 AI 把它翻譯成英文，讓更多人看到。
寫完之後分享到 Reddit、X 或其他地方，慢慢就會有人知道你的 ID、知道你是誰。
上台演講
這可能是壓力最大的，但也是最有效的。
我第一次上台演講就是在 RubyKaigi 講我自己做的很爛的程式語言。多虧了慕凡跟龍哥給我很多幫助和鼓勵。講了第一次之後，就慢慢知道自己做得到這件事。
當公司在看履歷的時候，他們可能沒辦法點進去看你 5 個 Rails PR 的討論串。但如果你跟他說你在 RubyConf Taiwan 講過 30 分鐘，他可以快速滑一下你的影片、點過你的 slides。用這個方式來證明你的能力很有效。至少我會對你的溝通能力有一定的信心，因為你敢站上台分享你學的東西。
不要因為英文退縮
很多人問我：英文不好怎麼辦？
我英文一開始也不好。為了貢獻開源專案、參與社群、到國外找工作，額外花了很多時間練英文。我現在還找得到我第一個 PR，描述裡兩句話就有三個文法錯誤。
但那完全沒關係。
社群裡很多 maintainer 來自西班牙、法國、非洲，英文也都不是他們的母語，寫英文的時候常常會有文法錯誤。台灣人並沒有比較劣勢。
比較劣勢的是：因為覺得自己英文不好，所以就不敢講話。
英文不好不是問題，但不要因為英文不好讓你不敢講話、不敢上台、不敢在 issue 上面回覆訊息。如果真的因為英文不好而不敢開口，那就投資時間改善它 —— 不是為了達到別人的標準，而是為了說服你自己：我英文夠好，我敢講話。
台灣的教育讓我們讀寫應該都沒問題，其實只差嘴巴講出來的自信心跟流暢度。每天唸英文新聞、讓嘴巴肌肉習慣那個發音，三個月你就會發現差很多。
這需要很大的前期投入
我每年大概花 500 到 1000 個小時的個人時間在各種開源專案上面。
這個職涯對我來說很有用，但我其實不推薦給大部分的人。因為它的背後是這麼大量的時間投入，而且不保證有回報。你可能花一兩百個小時刷 LeetCode，就能拿到同等級的 offer。
我一開始貢獻開源專案，其實是想要展現我寫程式的能力。我是非本科出身、沒上過任何課、完全沒有相關背景。我不想用 LeetCode、不想刷演算法（我刷演算法超爛）。我想用公開的成果，讓別人看我花 8 個小時寫的 code，而不是用我 30 分鐘壓力下寫出來的 LeetCode 來判斷我的能力。
後來我的職涯也確實都是這樣。從第一份實習之後，我幾乎都不用投履歷，都是靠別人的 refer。即便到 Shopify，也是別人介紹、用開源專案來面試。
但如果你對這件事情沒有熱忱，就不值得花這個時間。最好是因為真的喜歡才做。
最後
用開源專案建立職涯，對我來說是一條很值得的路。但它需要很大的前期投入、需要你願意曝光自己、需要跨過語言和文化的障礙。而且不保證有回報。
如果你正在想這條路適不適合自己，希望這篇文章能提供一些參考。