很開心看到原PO分享GitHub open source的心得 私以為台灣軟體在有資源的不懂軟體，懂軟體的沒資源情況下， 靠open source似乎是唯一的出路，所謂 "自己的軟體業自己救" ! 小弟也在這分享自己的open source小小心得， 雖然自己沒有repo，但有靠發PR(Pull Request)成為collaborator的經驗 :) 先附上在PyConTW 2015 lightning talk的slide: http://goo.gl/fTUPGC 小弟比較有貢獻的repo是 (工商一下...XD) * https://github.com/djacobs/PyAPNs * https://github.com/mher/tornado-celery < 重點心得 > PR能不能被merge的關鍵似乎不在於coding多厲害，解決多複雜的問題， 而是 "PR解決的問題大家覺得重不重要" < 基本 > 必須了解repo解決了甚麼問題，用了甚麼方法，coding structure/convention， patch加在哪邊最適合，會不會影響到原本structure，有沒side effect等 < 讓別人好review/merge > code diff保持很乾淨，盡量做到讓reviewer好auto-merge, 技巧如 1. push上remote前先git squash整理一下 2. 開PR專用branch，裡面只放PR的change 3. 如自己的fork要發PR但是upstream已經變很多 => 先fork最新upstream成新branch再cherry-pick要PR的部分 4. 如PR發很久還沒被merge, upstream又變動到conflict的話, 自己先merge from upstream < 提升PR的重要性 > 如果owner遲遲不merge的話，有幾種可能， 1. 他懶 2. 他覺得不重要 3. 他覺得PR不夠好 要驗證是何者的話，就用對PR做點PR(Public Relations)試試看吧...XD * 我會先發一個issue，蒐集遇到類似問題的人，強化重要性。 下面我會貼我的fork/PR請遇到問題的人回去試試看，通常試成功的人會回文 就變成很好的"見證"...XD * 另外，我也會在相關issue，stackoverflow相關問題上貼我的fork/PR， 累積到一定的量，其他user會反過來push owner來merge PR e.g. https://github.com/djacobs/PyAPNs/pull/78 * 積極回應網友issue與對你發的PR的challenge * 經我實驗本來PR 2個月沒人理，用上述方法後沒多久就被merge惹 < 成就 > * 在貢獻過程中看到自己的code有幫助到人，如user會在GitHub上或是mail表示 這個code work! 或是表達感謝，自己也會覺得鳩甘心，進而化為繼續貢獻的動力 * 有些conference可以用contributor的名義申請票就不用跟別人搶...XD < 後記 > 有時候該專案已經跟目前工作/side project距離太遠時，會覺得懶得去maintain/ 回應user問題，這時候就是該放手讓對此專案更有熱情的人接手了。 這也是原PO說的open source精神之一~ ※ 引述《huei90 (huei90)》之銘言： : 本魯在 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 經驗是什麼呢？ --

※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 1.160.114.196 ※ 文章網址: https://webptt.com/m.aspx?n=bbs/Soft_Job/M.1451014129.A.D43.html