從入門到上手心路歷程》工程師分享在 GitHub 上學習 OpenSource 經驗

註：本文轉自 PTT Soft_Job 版，作者 huei90，原標題：[ 心得 ] 我在 Github 上學習 Open Source，未經原作者許可不得轉載。

本魯在 Soft_Job 版吸收了各位大大的精華，久而久之也變成了一個 Coding 鄉民，我相信每個鄉民都有自己的專業，賣雞排也是個專業，而我很榮幸成為一位程式開發者！

這篇拖了一年了，我想是時候把兩年多在 GitHub 上開發 Open Source Project 的經驗分享給各位，雖然不及神級的開發者，但我始終相信，分享、自由、開放、討論和開發者是 Open Source 的精神。

如果你不懂什麼是 GitHub，但你多少也應該聽過 Bitbucket, CodePlex, Google Code, GitCafe 等等。如果都沒聽過，那就左轉出去吧～

文長，對著電腦的各位，夜深了，進入正題前，記得泡好咖啡！

• 接觸 GitHub

N 年前聽教授介紹 Open Source 有多威，國外是怎麼玩 Open Source 的，就從那一刻開始，接觸了 GitHub（GitHub Private Repo 要付費，Bitbucket 免費喔）。用過 GitHub 應該可以感受到，大眾還是趨向 GitHub，而不是 Google Code。UI/UX、效率、社群都是 GitHub 優勢的關鍵。

開始玩一玩就立馬上手，根本就是快快樂樂學 Git/GitHub，透過 GitHub 才慢慢瞭解 Git。一開始使用 GitHub 提供的 GitHub Desktop 來 commit push，但後來好像 bug 很多並開始接觸 command line，就一直用到現在，現在已經回不去 GUI 了。

有付費買 GitHub Private Repo 的人和公司也不少，但費用也不便宜。還記得之前在公司直接用 GitHub Importer 把整個公司專案複製一份到 GitHub 上，不費吹灰之力就完成了，如果你的專案是 svn，轉過去 git 也是沒有問題的喔！

• 前輩

兩年前自己很菜（現在還是很菜），前輩開始教我多看看別人的專案、學習模仿等等的，到現在我還是很感激這位前輩，沒有他推我一把，我可能就沒繼續 Open Source 下去了。看了幾個星期後，前輩讓我開一個專案，剛好公司專案是使用 angularjs 當前端架構開發，那就寫一個前端驗證工具吧。定義需求、規則、功能，再來定義最重要的 SPEC，接著開始 Coding 主要模組，其中當然少不了被前輩唸說這怎麼這樣寫等等之類的。

我還記得很清楚，前輩說：那開始寫測試吧，寫測試的時間是寫模組的兩倍喔（嚇！笑）。問題是，我怎麼知道該如何寫測試，而且是用該死的 angularjs，哪懂什麼 protractor，又一堆什麼 BDD/TDD, JUnit, QUnit, Jasmine, Mocha, blablabla。就直接模仿了前輩的程式，也終於把完整的測試給寫出來了。從開始寫到結束大概花了三個月的時間，前輩也已經離職了。大致初步功能也完成了，DEMO 頁面也寫好了，就立馬開源，這裏簡稱 A-V！（原諒我一下 Open Source 一下開源）

• N4J

其實在 A-V 出來之前，我只會 jQuery，正在學習 jQuery 寫第三方套件的時候開發了 N4J 的前端工具，N4J 是純粹學習用的，學習如何使用 GitHub、結構的 Coding 以及書寫 Document。還記得自己寫得很開心，多年回去看還記得那時候的興奮，後來畢業後也用 N4J 拿到了 Offer，無縫接軌畢業沒有失業即馬上就業。

• A-V

先說說 A-V 目前的狀況，有 2xx commits、1x releases、2x contributors，比起大型專案這個數字沒什麼，但對我來說，這些數字都是一個肯定，一個成就，我想這是 Open Source 帶給我的好處之一，也是讓我持續投入時間的原因。

完成第一個版本後就馬上上線了，寫過程式的人都知道，這時候就會出現上線臭蟲，版本 1.0.5, 1.0.6, 1.1.0 後，才開始慢慢穩定下來。

很快的，我試著在各論壇發表自己的作品，也包括台灣的前端社群，分享自己這幾個月下來的成果，但很可惜沒人理我，也許是作品沒有爆炸性，畢竟只是個前端驗證工具。其實不免有點小小的失望，沒有人討論，沒有任何回饋。但有一點值得注意的是，angularjs 在這方面還沒有太多相關的套件和討論，所以我算是進入了對的時間點。

幾個月下來，我持續開發、增加功能、把程式寫得更好，來了第一個 issue，後來也陸續來了幾個，應該是我之前在某個論壇發文，有人看到進來給我意見。當然我就立即回覆謝謝他們的提議，馬上修改或者問說有什麼建議等等之類的。因為有人看到，star 了過後就會更多人看到，甚至有人開始丟 PR 給我，在這裏我學到，有人丟 PR 給你，你一定要接受，除非他的程式充滿問題，但也不能馬上拒絕，要提出自己的理由決定是否要對方修改還是繼續討論下去。其實我在別人的 Open Source 也是這樣，丟了一個 PR，幾天內沒有人回覆會覺得很傷心，但一旦被接受或者回覆，心理會很開心，太棒了，被接受了！這是一種被肯定，支持的動作。所以只要有人丟 PR 我大部分都會接受。

接下來的幾個月，更多的 issue 更多的 PR，一個人無法承擔所有的問題，所以很多我回覆後就沒有繼續了，一旦有時間可能是一個月後，才有時間回來看到底發生什麼問題，就這樣慢慢把 bug 修復。還記得有一次，有個 issue 幾個月下來都解不了，某天晚上到了咖啡廳坐下，瞬間就解掉了，這一定要上一個新 tag 說 “fix feature or major improvement”，其實這是開發 Open Source 的小確幸，只有你知道發生了什麼事，即使你公告了你修復這個功能，會理你的人沒有多少。

中間當然有停下的時候，完全沒有任何聲音自己也沒動力繼續開發解 bug，但突然有人丟了一個 bug 或者 PR 過後，又會瞬間熱血起來，不修掉不行的那種感覺，修掉後會很開心，然後又會安靜一陣子。大概就是這樣來來回回的狀況。

當然如果你的專案是那種爆炸性的，比如說 pageres、express、awesome，不會是以上的故事

前幾個月，因為自覺專案掉入了谷底，很久沒有更新也沒有人問說進度，開了一個 issue 「Looking for Collaborators」，自以為會有人自告奮勇的說：「我來」，結果一個都沒有。在這裏我學習到的是，Open Source 這東西，就是要讓他慢慢的醞釀，果然某一天有人丟了個 PR 幾乎大改了我整個專案的架構，改著改著他的興趣就來了，我就問他說要不要當 Collaborator，他也就馬上說好。後來我們也開了個 Slack 群組，討論著 A-V 的開發。也許有人覺得這沒什麼，但是這種與網友一起奮鬥，討論著彼此的專業，這份經歷是工作永遠無法取代的。

以上故事就是不停的 loop，持續了兩年，直到現在不是一個人在開發修 bug，而是有 collaborators 一起討論，彼此給意見，這就是 Open Source 的魅力所在。

A-V 過後，陸陸續續展開對 Open Source 的興趣，看了很多 license 的選擇（還是覺得迷迷糊糊的），期間也開了不少的專案，像是 I-G、G-E、S.S.S、J-S-D 等等的，雖然沒有像 A-V 那麼精彩，但難免還是有 issue 有 PR（真的很珍貴）。

• A-J

A-J 專案雖然不是我開始的，是我主動寄信給作者要求成為 Collaborator 。A-J 屬於爆炸性的專案，現在已經有四位數的星星，通常這類型的專案 issue 和 pr 會多到你接手軟會想吐，大概會忽略他一陣子，然後一段時間後再來慢慢處理。但是既然是自己主動要求幫忙的，就有責任繼續維護它，Open Source 要學習的其中一點就是－主動，包括提出問題、意見、結果、拒絕，你的任何一個動作都在幫助一個 Open Source 專案的進步，這裏就真的是責任制了。每個專案都有自己的步調，你也可以不要主動，讓 owner 自行決定專案方向。

• Gitter

其實我覺得 GitHub 提供的 Issue 已經很好用了，整個專案的討論都能在 Issue Comment 完成，有必要還能互相 reference，甚至下 label 來整理 Issue 分類。但有時候不是所有人都喜歡在 Issue 問問題，也有可能擔心問到重複的問題。

如果你的專案很大，你可以建議大家到 stackoverflow/irc 尋找問題，但對於比較小的專案，可以使用 Gitter。Gitter 是一個聊天室，會自動整合 GitHub 專案，任何的動向都會紀錄在 Gitter 內，讓所有人進入一個獨立的空間討論問題。多一個管道讓大家凝聚，其實多少也能幫助到你，因為一個聊天室裡面，大家都能發言，你不回答其他人會幫你回答的。

• 已死？

常常逛 GitHub，你會發現有很多有趣的專案，但看到最新的更新時間，什麼！是一年前。這時候就會開始腦補，是不是專案已經沒有在開發了，作者似乎也消失了，有好多 issue 好多 PR 都沒有被接受。自己也嘗試丟了 issue 詢問專案開發進度，當然也沒得到任何回應。偶爾還是會覺得很可惜，這麼棒的一個專案是不是被拋棄了。

但是不要氣餒，就因為這是 Open Source，這是一個開放的社群，任何人都有權利查看修改更新（有的 License 是不允許的），先查查看 fork 分支，有時候分支的星星數還會比原本的專案多，再看看 issue 裡面有沒有人在討論替代方案。最後一招就是自己 fork 自己改，當然你也可以開一個全新的專案來做一樣的事情。

• END

以上是我在 GitHub 上學習 Open Source 的經驗分享。對我來說，逛 GitHub 和 Facebook 一樣重要，都成為生活中的一部分。打開 GitHub 點擊 Explore 常常會有意想不到的新專案，也是吸收新知識、新趨勢的好地方。

有人說，維護 Open Source 專案，就像是開一間公司，你要不停的對他持續開發，對的時機對的功能，持續研究並找尋突破點，公司才能活得久。

原諒我把專案的名字都縮寫了，因為這不能是個廣告文，但 不瞞各位，我就是來騙讚數的啦，騙星星為其次，再來騙 followers，但我一定會做好做滿，繼續 Open Source。

不知道大家的開發 Open Source 經驗是什麼呢？

[ 成績 ]

既然 Open Source 了，那資訊一定要全面透明化，GitHub 提供了一個簡單 Traffic 的圖表給 Repo Owner 做參考。在我發了這篇在 PTT 後，流量瞬間爆炸（雖然不多，但是明顯增長），直接看圖

謝謝 PTT 上的各位！