不知道怎么為開源軟件做貢獻(xiàn)？從匯報 Bug 開始吧，或許還有錢賺呢～ 且看 Qian Hong 的經(jīng)驗分享。全文轉(zhuǎn)載開始

今年的軟件自由日(SFD)，我在廣州Linux用戶組的線下活動上做了一個分享，主題叫做《做一名開源社區(qū)的掃地僧(上)》。我把演講的內(nèi)容重新整理擴(kuò)充, 寫出了文字版, 希望可以跟更多朋友分享。

金庸筆下有一個傳奇人物，人稱掃地僧，身世隱秘，武功絕頂。小說中的掃地僧一出現(xiàn)就是個高手，沒人知道高手怎么煉成的。這種"掃地僧"，實在可望不可及。 然而，還有另一種掃地僧，人人都可以效仿，人人都可以做到，不妨稱之為"山寨掃地僧"。

最近流傳一個真實的故事, 有個廣外宿管旁聽了中大和廣外的會計類課程, 考過了注冊會計師, 跳槽去了四大會計事務(wù)所. 還有一個更著名的例子, 今年倫敦奧運會閉幕式里約八分鐘上, 表演桑巴舞的巴西清潔工, 名副其實的"掃地僧", 他是巴西一家舞蹈學(xué)校的清潔工.

每一個山寨掃地僧, 都是一個勵志帝...

這篇文章要推廣的, 就是一條開源社區(qū)掃地僧的打怪升級之路. 當(dāng)然, 起這個標(biāo)題, 完全是為了騙取點擊率, 真正的標(biāo)題是:

= 從Bug report到Google Summer of Code = 副標(biāo)題是: == 從200個bug到5000美金 == 直白一點, 其實重點是: === 怎樣騙錢? ===

預(yù)告: 這篇文章很長, 讀不下去的時候想一想5000美金 XD

報bug跟騙錢有什么關(guān)系呢? 這要從Google Summer of Code說起.

GSoC是一個由Google出錢贊助, 由開源項目提供一對一的導(dǎo)師, 由學(xué)生給開源項目寫代碼賺錢的夏令營活動. GSoC項目的時間是3個月, 每一個完成GSoC項目通過考核的學(xué)生都可以獲得5000美元的獎金. 官方的介紹很長, 讀不下去的時候想一想5000美金:?http://www.google-melange.com/document/show/gsoc_program/google/gsoc2012/faqs

GSoC每年和全球大約200個開源項目組織合作, 每年有4000多個學(xué)生申請, 最終有1000多名學(xué)生通過, 通過申請的絕大部分學(xué)生都能通過中期考核和末期考核. 如果你有幸通過了申請, 那么只要你接下來不偷懶不耍賴不懂多請教, 那么不用擔(dān)心通不過考核. GSoC學(xué)生的通過率可能會影響到開源項目組織下一年分配到的學(xué)生名額, 所以導(dǎo)師一定會幫助你克服困難. 當(dāng)然，換個角度想, 一旦你通過了申請, 也有責(zé)任好好珍惜這個名額, 努力完成目標(biāo).

不管是申請, 中期檢驗還是末期檢驗, 每個階段都是開源項目的導(dǎo)師說了算, 因此, 如果你想騙錢, 不妨提前跟開源項目的開發(fā)者混熟 ;-)

2011年初, 我開始有預(yù)謀地給Wine項目報bug掃地做測試順便混熟臉, 到了2012年4月, 我申請了Wine項目的GSoC, 沒有費多大力氣就通過了申請, 并且最終順利完成騙錢計劃 [注1]. 今年有十幾個學(xué)生報名Wine項目的GSoC, 而Wine項目的學(xué)生名額只有5個, 如果不是提前預(yù)謀好, 騙錢的好事肯定輪不到我.

獨騙騙不如眾騙騙, 希望可以把騙錢的經(jīng)驗跟大家分享: - 提前一年做準(zhǔn)備, 從報bug入門參與開源項目, 花一年時間報接近200個bug - 通過報bug, 了解開源項目的工作流, 認(rèn)識開源項目的開發(fā)者, 從開發(fā)者身上"偷學(xué)", 入門開源項目開發(fā) - 通過報bug與開源項目開發(fā)者建立起信任的關(guān)系, "騙取" GSoC 的資格, 最終騙到5000美元獎金.

簡單地說, 騙錢的訣竅就是通過報bug加入開源項目不斷打怪升級, 從而提升自己的水平和提高GSoC申請的成功率.

正經(jīng)地說, 一個人能為開源項目報200個bug, 那他肯定對這個項目真心有愛, 也一定會珍惜自己在開源社區(qū)中的聲譽(yù), 不會只騙錢不干活. GSoC的本意是培養(yǎng)開源項目的新貢獻(xiàn)者, 希望學(xué)生在結(jié)束夏令營之后仍然愿意為開源項目做貢獻(xiàn). 報200個bug本身就是一種不小的貢獻(xiàn), 而從開源項目開發(fā)者的角度看, 愿意提前花一年時間給項目報200個bug的學(xué)生, 騙完錢之后繼續(xù)做貢獻(xiàn)的可能性也比較大, 所以把名額給這樣的學(xué)生也是合理的. 因此, 信任和機(jī)會其實是汗水換來的, 所謂"騙"只是開玩笑, 不可當(dāng)真.

報200個bug似乎很難, 可是只要堅信報完200個bug就可以騙到5000美金, 立刻就變得不難了 :D

怎么報bug呢? 其實每一個成熟的開源項目都有詳細(xì)的bug report guide line, 只要照著文檔去做, 就知道怎么報bug. 如果從來沒讀過這類文檔, 可以試試google一下下面的關(guān)鍵詞組合: XXX + QA / testing / bug report 例如:?http://lmgtfy.com/?q=libreoffice+qa?http://lmgtfy.com/?q=chromium+bug+report?https://www.google.com/search?btnG=1&pws=0&q=ubuntu+testing?等等.

這些文檔通常都不短, 讀不下去的時候想一想5000美金 ;-)

大多數(shù)文檔會引用很多外部鏈接, 這些鏈接也應(yīng)該盡可能閱讀一下, 它們可能會解釋開源項目的測試發(fā)布周期, 或者介紹專用的報bug和調(diào)試工具, 也可能是介紹項目相關(guān)的郵件列表, 還有可能會講解開源項目的?工作流?(workflow)

工作流是什么東西呢? 打個比方, 去醫(yī)院看病, 工作流就是掛號就診檢查化驗繳費取藥也許還有送紅包; 去學(xué)校上學(xué), 工作流就是報名注冊選課逃課交作業(yè)考試也許還有掛科補(bǔ)考; 參加GSoC, 工作流就是選項目選課題混熟臉報名申請寫代碼考核還有最重要的騙錢. 總之, 工作流就是這類看起來有點煩瑣無聊卻有時候不得不面對的辦事流程.

開源項目的工作流包括, 去什么地方報bug, bug生命周期如何運轉(zhuǎn), 去什么地方提交補(bǔ)丁, 補(bǔ)丁沒有被接受怎么辦, 如何獲得開源項目bug tracker的管理權(quán)限, 如何獲得官方的代碼提交權(quán)限, 等等.

對新人來說, 有時候加入一個開源項目最大的門檻居然不是技術(shù)也不是語言, 而是對工作流的困惑不了解. 不知道去哪反饋問題, 不知道補(bǔ)丁發(fā)給誰, 不知道去哪里尋求幫助, 等等各種不知道. 有時候商業(yè)公司的開發(fā)者也可能會遇到這種問題, 比如在工作中用到了一些開源項目, 修復(fù)了一些bug, 卻不知道怎么把補(bǔ)丁反饋給社區(qū), 或者補(bǔ)丁發(fā)送一次沒有被接受就從此放棄改進(jìn), 于是長期維護(hù)一個本地的分支, 這樣就把原本簡單的事情變復(fù)雜了, 把原本可以共贏的事情變成自己額外的負(fù)擔(dān). 其實開源項目的工作流大同小異, 只要接觸過一個項目, 以后參與其他任何項目都不難根據(jù)文檔了解工作流.

如果你對報bug的工作流有初步的了解, 就會發(fā)現(xiàn)報bug其實跟論壇發(fā)貼差不多, 只不過發(fā)貼的地方是bug tracker. 這么看來, 報bug的技術(shù)門檻其實是很低的, 正是因為沒有技術(shù)含量, 所以才叫做"掃地".

雖然報bug跟發(fā)貼一樣容易, 但是如何把bug report寫得好仍然是一件需要用心的事情. 前人寫過關(guān)于報bug的通用教程, 最著名的是 "如何有效地報bug" , 這篇文章具有超級牛力. 另外一篇同樣具有超級牛力的文章叫做"提問的智慧". 認(rèn)真地閱讀這兩篇文章的任何一篇, 時常反省檢查一下自己做到了沒有, 就能寫出質(zhì)量不錯的bug report. 這兩篇文章都很長, 讀不下去的時候就想想5000美金, 這兩篇文章瞬間都不長了. 如果兩篇都認(rèn)真讀過了, 就會發(fā)現(xiàn)本質(zhì)上提問和報bug都需要相同的素質(zhì). 當(dāng)你確信自己"會報bug"的時候, 再看一下論壇上大多數(shù)的提問貼, 也許會覺得很多人不會提問, 說不定也包括過去的自己. 不信報200個bug試試? :P

一個高質(zhì)量的bug report會受到開發(fā)者的歡迎, 而劣質(zhì)的bug report則有可能幫倒忙, 浪費開發(fā)者的時間. 也許很多人不愿意仔細(xì)閱讀 "如何有效地報bug" 和 "提問的智慧" (詛咒他們拿不到5000美金 :P) 為了防止有人真的一下子報200個劣質(zhì)的bug, 還是得先打一下預(yù)防針. 合格的bug reporter需要做到: - 閱讀項目的bug report guide line! 不讀guide line就報bug, 是很不負(fù)責(zé)任的做法. - 每個bug只報告一個問題 -?精確?說明相關(guān)程序版本號和操作系統(tǒng)版本 - 按?時間順序?分點?列出重現(xiàn)bug的?精確?步驟 - 記得及時回復(fù)開發(fā)者的問題!!!

本來還需要增加一點: - 報bug之前先分別在google和項目bug tracker里搜索重復(fù)的問題. 但實際上對于新手來說, 搜索重復(fù)問題是最難做好的, 尤其對于英文不好的人來說更是如此.

當(dāng)你知道怎么搜索鑒別重復(fù)的bug的時候, 已經(jīng)不是新手了, 不妨提高對bug質(zhì)量的要求: - 養(yǎng)成自己固定的風(fēng)格. 盡量按照固定的格式寫bug報告, 就容易養(yǎng)成習(xí)慣, 有助于形成嚴(yán)密的思維, 不會漏掉重要的信息. 很多bug tracker都有bug報告的"模板", 可以參考這些模板養(yǎng)成習(xí)慣. - 假想自己報了50個bug, 如果半年后隨機(jī)挑一個給自己看, 能否保證閱讀一次就知道如何重現(xiàn)? 帶著這樣的想法去報bug, 等真正報了很多bug的時候, 回頭檢驗一下. 如果自己都沒辦法讀過一次就知道怎么重現(xiàn), 那別人怎么知道? - 訂閱/跟蹤開源項目的bug tracker, 觀察別人怎么報bug, 從老手身上學(xué)習(xí), 并主動幫助新手. 幫助別人也是提高自己的一種方法. 讀完報bug必讀的文檔, 領(lǐng)會了報bug的要點, 也許你會發(fā)現(xiàn): 報bug不是問題, 問題是沒bug!

的確, 報bug本身不難, 難的是找bug. 在日常使用中發(fā)現(xiàn)bug, 通常是一件可遇不可求的事情, 否則肯定沒人愿意使用這個軟件 ;-) 但是, 如果你非常想報bug, 一定要了解一下?批量找bug的方法, 哪怕沒有方法, 也要創(chuàng)造方法!

什么? 批量找bug?! 其實批量找bug并不稀奇, 有一類工作干的就是批量找bug的事情, 這種職位或者叫測試, 或者叫QA, 或者叫QE.

要批量找bug, 首先必須做到的一點是 "早".

很多開源項目都有devel版, alpha版, beta版等各種開發(fā)測試版, 也有所謂的最終版穩(wěn)定版, 如果你在開源軟件的"穩(wěn)定版"中遇到不穩(wěn)定的現(xiàn)象, 不用大驚小怪, 因為很多開源項目都沒有足夠的人手可以去做充分的測試, 而商業(yè)軟件背后通常有不少全職的QA. 反過來, 如果你沒遇到過什么嚴(yán)重的bug, 其實應(yīng)該感激為開源項目默默做貢獻(xiàn)的QA們. 想抓住"批量報bug"的機(jī)會, 就應(yīng)該?盡早, 每當(dāng)軟件發(fā)布新版本的時候, 第一時間去測試, 最好是alpha版, 最好是daily build版, 最好最好是自己從git倉庫下載編譯的實時版.

早起的鳥兒有bug吃, 但批量找到bug的通常還得是老鳥. 所以, 第二點就是跟老鳥學(xué). 訂閱開源項目的bug列表, 觀察別人報的bug, 觀察哪些是老鳥, 觀察老鳥怎么找bug怎么報bug. 詳細(xì)閱讀QA的文檔, 也許批量找bug的方法工具就記錄在QA文檔中.

有時候, 批量找bug的方法很簡單, 比如說, 怎么給 wine 報200個bug? 我用過的是最笨的方法: - 去軟件下載站找排行top 100的軟件, 有空就在wine上測試一下, 只要有時間, 要多少bug有多少bug. - 有針對性地下載各家網(wǎng)銀的控件進(jìn)行安裝測試, 不知不覺也報了很多bug, 順便改進(jìn)了工行和招行等網(wǎng)銀的很多問題. - 關(guān)注郵件列表和論壇里其他朋友反饋的Wine的問題, 看到順眼的帖子就去幫忙測試一下報幾個bug ;-)

如果這些笨辦法對你實在沒有吸引力, 可以看一下比較有技術(shù)含量的批量方法:?http://wiki.winehq.org/UnitTestSuites

很多項目都有自己的單元測試, 如果你在Wine上面運行這些單元測試, 就變成一組非常有價值的Wine測試用例. (如果你恰好是某個Windows軟件的作者, 希望借助Wine將軟件移植到Linux/Mac, 其實只要在Wine下運行一下單元測試, 就能發(fā)現(xiàn)和解決絕大部分問題了.)

上面的例子不是特例, 其實很多項目都有前人總結(jié)開發(fā)出來的批量報bug方法或工具:

• 怎么批量發(fā)現(xiàn)Chromium/Firefox瀏覽器的bug? 有一個叫做Selenium的開源項目, 它是一個瀏覽器自動化測試工具, 支持IE, Firefox, Chromium以及一些手機(jī)瀏覽器:?http://seleniumhq.org/

• 怎么批量發(fā)現(xiàn)linux桌面環(huán)境的bug? 有一個叫做linux desktop testing project的開源項目, 用來做桌面環(huán)境和圖形界面軟件的自動測試工具, 支持linux, windows 和 mac:?http://ldtp.freedesktop.org/wiki

• 怎么批量發(fā)現(xiàn)LibreOffice/OpenOffice的bug? 我不知道有什么聰明的辦法, 但笨辦法倒是很簡單: 每個LibreOffice/OpenOffice跟MS office格式不兼容的地方都是一個bug. 面對格式兼容問題, 有的人只會抱怨, 有的人默默地拿走了5000美金... 從Libreoffice的wiki上可以看到, 已經(jīng)有好幾個GSoC學(xué)生做的是改進(jìn)格式兼容的工作.

其實, 凡是跟兼容靠邊的項目, 都很容易"制造"大量不兼容的bug :P mono, Wine, ReactOS, Haiku OS, LibreOffice/OpenOffice, mingw/mxe, gnash/lightspark, 這些都是跟兼容有關(guān)的項目, 只要google一下 XXX open source alternative, 可以發(fā)現(xiàn)兼容類開源項目還有很多, 這類項目非常需要志愿者去找bug報bug. 兼容性相關(guān)的問題常常是很有挑戰(zhàn)的技術(shù)難題, 開發(fā)調(diào)試不容易, 還時不時需要逆向工程, 遺憾的是這類項目卻被罵得最多, 真是吃力不討好. 如果我們都能做到多報bug, 少抱怨, 這個世界會變得更好.

批量報bug的方法通常跟自動測試/單元測試工具有關(guān), open source testing項目為我們收集總結(jié)了大量的自動測試/單元測試工具:http://www.opensourcetesting.org/functional.php

如果給一般的項目報bug對你來說太沒技術(shù)含量怎么辦? 不用擔(dān)心, 總有夠硬的骨頭可以啃.

• 怎么批量發(fā)現(xiàn)gcc的bug? 這個我真不知道, 不過當(dāng)我搜尋這個問題的答案的時候, 我發(fā)現(xiàn)Delta這個工具真是帥呆了:?http://gcc.gnu.org/wiki/Aguidetotestcasereduction?Delta是一個利用二分原理對代碼進(jìn)行裁剪的工具, 對于診斷編譯器的bug有很大幫助. 如果報bug可以騙錢, 我會先學(xué)習(xí)Delta工具, 然后上GCC的bugzilla搜索前人報過的有效的bug, 親自重現(xiàn)幾十個bug.?重現(xiàn)bug?其實跟?報bug?一樣, 也是一種"掃地", 同樣能學(xué)到很多東西. 俗話說熟讀唐詩三百首,不會作詩也會吟, 如果你讀過的bug report夠多, 重現(xiàn)過的bug夠多, 那你也一定會找bug報bug. 像gcc這樣基礎(chǔ)而重要的項目, 對于新手來說確實不容易找到bug, 但也不是沒有機(jī)會. gcc在x86平臺上可能非常完善, 但在一些冷門的平臺上則未必有那么完美, 這也是找bug的一種思路.

• 怎么批量發(fā)現(xiàn)內(nèi)核的bug? 有一個開源項目叫做linux testing project, 是一個專門針對Linux內(nèi)核開發(fā)的測試套件:?http://ltp.sourceforge.net/同樣, 如果報內(nèi)核的bug太難, 也可以先從重現(xiàn)別人的bug report開始入手, 照樣可以學(xué)到很多東西. 給內(nèi)核找bug同樣不容易, 但也不是沒有機(jī)會, 一些冷門的平臺, 例如openrisc, 人手不一定夠, 肯定有很多bug等你捉 ;-)

很多人說Linux kernel穩(wěn)定, 其實linux kernel哪里穩(wěn)定? 測內(nèi)核的最傷不起了, 新出的內(nèi)核動不動就panic, 穩(wěn)定的內(nèi)核都是經(jīng)過多輪測試的. 其實只要有足夠多的工業(yè)級測試, linux桌面也可以跟內(nèi)核一樣穩(wěn)定. 開源社區(qū)極缺大量志愿QA, 如果你愿意捉蟲, 到處歡迎你, 甚至巴不得手把手教你 (就怕人手不夠沒手教你...) 當(dāng)你報了200個bug的時候, 會發(fā)現(xiàn)原來開源項目bug那么多, 人手那么少...

在批量找bug這件事上, 需要一定的創(chuàng)意和想象力. 比如Selenium原本的作用是測試瀏覽器, 內(nèi)置了大量的browser test case, 而ReactOS是一個開源的仿Windows操作系統(tǒng), 如果把這兩者組合起來, 在ReactOS上運行Windows版的Selenium+Firefox/Chrome, 那就變成一組現(xiàn)成的ReactOS test case了, 這時候還怕找不到ReactOS的bug嗎?

只要肯動腦, 一定能發(fā)明出前人沒想到過的批量找bug的方法. 還是那句話, 只要想一想5000美金, 辦法一定有的 :P 讀到這里, 也許你會發(fā)現(xiàn), 報bug不是問題, 找bug也不是問題, 問題是木有項目!

很多人想?yún)⑴c開源項目, 卻不知參加什么項目好. 其實這個問題功利的答案很簡單: 如果是沖著GSoC的5000美金去報bug的, 那就去GSoC的官方網(wǎng)站查一下最近5年有哪些項目跟google合作過:?http://code.google.com/intl/zh-CN/soc/?看完之后可以猜出哪些項目明年參與合作的機(jī)會比較大, 然后就可以從中找感興趣的項目去研究. 如果過去對開源項目了解不多, 那么不妨花一兩個星期的時間廣泛瀏覽然后再篩選一些進(jìn)一步鉆研.

不那么功利的答案: 只要是感興趣的任何項目都可以. 如果毫無頭緒, 不妨到ohloh.net上隨便瀏覽, 比如看看按活躍貢獻(xiàn)人數(shù)排名的top 1000:https://www.ohloh.net/p?page=100&sort=active_committers?如果找到一個感興趣的項目, 還可以在?ohloh.net?上搜索這個項目的related project, 一不小心就會牽出一批有趣的項目. 如果有多個候選項目要篩選出一個進(jìn)行重點研究, 可以在?ohloh.net?上看一下這些項目的統(tǒng)計數(shù)據(jù), 比如: - 近期代碼提交數(shù)量 - 最近一個月的new contributor的人數(shù) - 高kudo rank的開發(fā)者的人數(shù).

一個開源項目經(jīng)常有新代碼提交, 說明這個項目很活躍, 加入活躍的項目才有活干, 給活躍項目報bug才有人處理; 一個項目經(jīng)常有新貢獻(xiàn)者加入, 說明這個項目很吸引人并且對新人的門檻不是特別高; 一個項目有很多高kudo rank的開發(fā)者, 那么加入這個項目可以跟很多大牛學(xué)習(xí).

如果找到這樣的項目, 但它以前沒有參與過GSoC, 也可以慫恿項目開發(fā)者明年向Google申請作為GSoC的合作項目, 當(dāng)然, 申請不一定會成功, 因為每年只有大約200個項目有機(jī)會跟Google合作. 另外,Google每年都說不保證明年會繼續(xù)舉辦GSoC, 所以, 騙錢要趁早...

很多事情是知易行難, 報bug也一樣, 哪怕項目找到了, 批量報bug的方法也找到了, 堅持報200個bug也是一件不容易的事情.

怎樣才能找到足夠的動力持續(xù)去報bug呢? 其實也不難.

報bug被修復(fù)帶來的成就感, 本身就能激勵人繼續(xù)努力. 問題是, 不是每一個bug都能被及時修復(fù). 很多新手經(jīng)常問, 一個bug要多久才能修復(fù)? 網(wǎng)上流傳個段子, 正好回答了這個問題:

=== >> 師爺, 寫代碼最重要的是什么? >淡定. >> 師爺, 調(diào)試程序最重要的是什么? >運氣. ===

這個段子很經(jīng)典, 影響bug修復(fù)的因素太多了, 有的bug一天就能修復(fù), 有的陳年老bug很多年都沒解決. 一個bug要多久才能被修復(fù), 這個問題本身無法回答, 但是換個說法就能帶來希望: 報100個bug一年后會有多少個被修復(fù)? 根據(jù)我的粗略統(tǒng)計, 給Wine項目報100個bug, 一年后大約會有50個被修復(fù). 換句話說, "bug半衰期" 差不多是1年. 其他開源項目, 只要是活躍開發(fā)中, "bug半衰期"應(yīng)該都不會太長. 所以, 保持報bug的動力的方法之一就是多報bug, 這樣必定有一部分bug先被修復(fù), 這些成果就會激勵自己繼續(xù)前進(jìn).

實際上, 保持動力的第二個方法仍然是 "多報bug". 當(dāng)你報的bug足夠多的時候, 可能會發(fā)現(xiàn)只要你一段時間不上網(wǎng), 郵箱里就有很多bug郵件等著你處理, 可能是開發(fā)者發(fā)布了新補(bǔ)丁等你幫忙測試, 也可能是一組相關(guān)聯(lián)的bug狀態(tài)發(fā)生變化需要重測, 這時候bug reporter的作用就很重要. 如果不回復(fù), 開發(fā)者的工作就可能被阻塞, 意識到這一點, 就會加倍感受到自己在社區(qū)中的價值.

如果我說保持動力的第三個方法仍然是多報bug, 那我一定會被讀者罵死 :) 其實, 在我看來, 保持動力的最終極辦法, 就是跟開源項目的其他貢獻(xiàn)者成為朋友. 加入一個國際性的開源項目, 可以認(rèn)識到地球上不同角落的朋友, 也許有的角落你一輩子都沒有機(jī)會到達(dá), 但是那里有個跟你素未謀面卻一樣為同一個開源項目做貢獻(xiàn)的人, 這是多么神奇的事情! 如果你得到某個老外的幫助, 一定要記住她/他的名字, 雖然老外的名字很難記; 如果你得到別人的鼓勵, 也不要忘了鼓勵別人, 大牛和菜鳥一樣都需要鼓勵. 如果你跟世界各地的開源項目貢獻(xiàn)者成為朋友, 就會加倍享受到開源的樂趣, 那個時候, 地球人都無法阻止你報bug了...

既然決心報bug, 就千萬別浪費一邊掃地一邊偷學(xué)的好機(jī)會, 這正是掃地僧的真諦所在. 開源社區(qū)里雖然不需要"偷", 但要觀察到別人忽略的東西, 學(xué)到別人沒學(xué)到的東西, 也需要 "留心", 所謂的 "偷學(xué)" 其實就是分外留心地觀察和學(xué)習(xí). 只要有心, 報200個bug可以學(xué)到很多東西.

• 如果開發(fā)者反復(fù)追問bug的細(xì)節(jié)和日志, 你可以學(xué)習(xí)積累排錯調(diào)試的方法思路.
• 如果開發(fā)者關(guān)閉了重復(fù)的bug, 就應(yīng)該注意學(xué)習(xí)搜索方法和積累搜索關(guān)鍵詞, 尤其是英文不好的新手.
• 如果一個bug被開發(fā)者確診為上游的bug, 你也可以順便了解上游項目.
• 對于大型項目, 要閱讀完所有代碼幾乎是不可能的, 報bug的過程可以熟悉局部代碼并逐漸入門開發(fā):
• 如果開發(fā)者針對bug發(fā)布了一個補(bǔ)丁, 可以嘗試從這個補(bǔ)丁周圍的代碼入手閱讀和學(xué)習(xí), 理解補(bǔ)丁的作用, 暫時忽略無關(guān)的代碼.
• 如果你自己報的bug足夠多, 可能會發(fā)現(xiàn)某些bug涉及的代碼似曾相識, 這時候不妨嘗試自己動手修改代碼, 也許是從協(xié)助診斷開始, 也許是從dirty hack開始, 慢慢地就可能從報bug進(jìn)階到修bug.

值得強(qiáng)調(diào)的是, 如果你的目標(biāo)是從報bug入門進(jìn)階為開發(fā), 那么從一開始就應(yīng)該訂閱開源項目的patch列表和devel列表, 一開始讀不懂不要緊, 長期耳濡目染, 量變可能會引起質(zhì)變, 這也是一種"掃地".

如果你像我當(dāng)初一樣對自己的開發(fā)能力沒有足夠自信, 這種看似曲折的道路可以大大降低入門開發(fā)的門檻, 不知不覺增長信心. 如果你還是沒信心, 想一想5000美金吧 XD

除了這些能直接學(xué)到的東西, 報bug還能帶來很多間接的好處.

• 報bug的過程可以跟開發(fā)者熟悉甚至成為朋友, 將來他們能夠?qū)δ阌泻芏鄮椭? 有開發(fā)方面的問題可以向他們請教.

• 報bug過程可以鍛煉英文!!! 如果你跟我一樣, 大學(xué)入學(xué)英語分班考試考到了最差的班, 那么趕緊去報bug. 當(dāng)你報了200個bug的時候, 計算機(jī)專業(yè)英語肯定不是障礙. 我剛開始用英文給開源項目報bug的時候, 很多單詞不懂, 一邊寫bug report一邊查, 報一個bug花很多時間, 還戰(zhàn)戰(zhàn)兢兢生怕自己表達(dá)錯, 現(xiàn)在雖然英文也不太好, 但至少錢是騙到手了 =) 如果你在一個開源項目里混久了, 那么很容易會認(rèn)識幾個老外朋友, 那時候遇到英語的問題你還可以向老外請教... (用英語請教LOL)

• 報bug的過程會逐漸改變自己的思維方式. 報10個bug跟報200個bug, 學(xué)到的東西不一樣, 思考方式也不一樣, 前者可能是從用戶的角度出發(fā)去思考問題, 而后者會迫使你從開源項目團(tuán)隊的角度出發(fā)去思考問題, 例如:

• 怎么做才能提高bug被修復(fù)的概率?
• 怎么節(jié)省開發(fā)者的時間和自己的時間?
• 這個項目什么地方最需要改進(jìn)?
• 怎么降低新手報bug的門檻?
• 等等 當(dāng)你想這些問題的時候, 其實已經(jīng)逐漸融入項目團(tuán)隊了. 當(dāng)你融入項目團(tuán)隊了, 可能就會像我一樣沒事總想騙幾個人來幫忙... 所以就有了這篇文章 =)

報bug能學(xué)到很多東西, 可惜很多東西記錄不下來, 記下來的也可能會失真. 這也正常, 如果讀一讀別人的分享就能學(xué)到這些東西, 那又何必親力親為去掃地? 如果真的報了200個bug, 一定會充分掌握掃地僧騙錢大法, 申請GSoC成功的概率一定會很大. GSoC的學(xué)生需要在申請時說明自己想要為項目做什么貢獻(xiàn), 盡管GSoC的合作項目會提供一些可選的任務(wù), 但更鼓勵學(xué)生提出自己的idea. 如果你對項目很了解, 就容易提出自己的idea, 不會跟其他學(xué)生撞車. 如果你對項目很了解, 就會對不同任務(wù)的難度心里有數(shù), 申請成功后也容易實現(xiàn)目標(biāo). 其實大多數(shù)被拒絕的學(xué)生, 不是idea太難不現(xiàn)實, 就是idea太容易騙錢意圖太明顯. 騙錢可以, 但不要太明顯 ;-)

其實, <<做一名開源社區(qū)的掃地僧(上)>>, 到這里就可以結(jié)束了. 也許有人會困惑, 這才剛講完掃地, 還沒開始講騙錢, 怎么就結(jié)束了? 有這樣的困惑, 正是紙上談兵的后果. 如果真的按照掃地僧打怪升級的道路去做, 會發(fā)現(xiàn)對自己幫助最大的人, 其實是開源項目中的前輩, 而這篇文章最大的作用無非是引誘多幾個人去嘗試, 真正的價值不大, 屬于讀過就可以忘掉的類型.

開源項目的前輩, 有的就是GSoC的潛在導(dǎo)師. 騙錢事宜, 都是導(dǎo)師說了算, 所以最重要的還是趕緊找個項目去跟潛在的導(dǎo)師混熟 ;-)

正經(jīng)地說, 這篇文章希望探討的問題不僅僅是騙錢, 而是這么一個老大難的問題: 應(yīng)屆畢業(yè)生找工作難! 沒有工作經(jīng)驗, 所以找不到工作; 找不到工作, 所以沒有工作經(jīng)驗.

其實對于未來碼農(nóng)來說, 解決這個問題的辦法很簡單, 只要愿意在開源項目中找一份掃地的活干, 花個大半年的時間報一兩百個bug, 就能積累一定的經(jīng)驗, 這個時候去找測試崗位的實習(xí) [廣告1], 肯定很受歡迎, 而有了開源項目經(jīng)歷和靠譜的實習(xí), 肯定不怕找不到工作. 在開源項目中掃地掃久了, 還能逐漸進(jìn)階入門開發(fā), 如果成功參加過GSoC, 就更不愁找不到工作了.

當(dāng)然, 參與開源項目實踐, 也不能包治百病. 比如, 參與開源項目不能代替學(xué)習(xí)計算機(jī)基礎(chǔ)和算法基礎(chǔ), 不能代替閱讀好書. 不過, 多實踐對于明白需要學(xué)什么會很有幫助, 實踐遇到瓶頸的時候也會更容易發(fā)現(xiàn)自己讀書不夠. 再比如, 參與開源項目也不能代替企業(yè)的實習(xí)經(jīng)歷, 實際上兩者都能學(xué)到很多東西, 但兩者互不可替代. 不過, 如果有開源項目的實踐經(jīng)歷, 對于尋找更好的實習(xí)機(jī)會肯定大有幫助.

希望這篇文章對在讀本科新生或者研究生新生有幫助, 尤其是對開源感興趣卻不知如何入手的同學(xué), 或者對開發(fā)感興趣卻經(jīng)驗不足的同學(xué). 開發(fā)能力很強(qiáng)的同學(xué)請不要被這篇文章誤導(dǎo), 你應(yīng)該向?google-opensource.blogspot.com?中記錄的優(yōu)秀案例看齊, 爭取成為下一個優(yōu)秀案例, 掃地的路徑不一定適合你, 我這種騙錢的技倆也不應(yīng)該是你追求的層次 ;-)

GSoC每年報名申請的時間是4月份, 現(xiàn)在開始掃地距離GSoC2013還有半年的時間, 其實很充裕. 對于接近畢業(yè)面臨就業(yè)壓力的學(xué)生, 現(xiàn)在開始掃地合不合適我就不知道了 :P

我有一個小小的愿望, 希望以后國內(nèi)的大學(xué)生爭先恐后給開源項目報bug, 通過報bug入門參與開源項目, 緊接著成功申請GSoC, 并且在騙完錢之后仍然繼續(xù)給開源項目做貢獻(xiàn) ;-) 希望將來本科生參與開源項目就像現(xiàn)在的本科生參加數(shù)學(xué)建模競賽, ACM競賽, XXX軟件開發(fā)比賽一樣多. 想一想哪個比賽有5000美金, 就知道誰吸引力大了 XD

我還有一個大一點的愿望, 希望將來我們可以在國內(nèi)舉辦比GSoC更大規(guī)模的夏令營, 鼓勵和支持更多的學(xué)生為開源項目做貢獻(xiàn). 每年1000多名參加GSoC的學(xué)生中, 印度學(xué)生和美國學(xué)生是最多的, 都有200人上下, 而中國學(xué)生只有50人左右. 如果有更多中國學(xué)生愿意走"掃地僧路線", 我相信人數(shù)翻一翻兩翻完全不是問題. 但是如果大家真的爭先恐后都去申請GSoC了, 肯定也沒辦法全部申請成功, 畢竟機(jī)會有限. 我希望我們能夠舉辦一個"本土化類GSoC", 提供更多的機(jī)會, 當(dāng)然這需要錢. 其實現(xiàn)在很多學(xué)校都喜歡舉辦ACM/數(shù)模等的院賽和校內(nèi)賽, 是否以后也可以多舉辦一些院級或校級的"報bug掃地夏令營"呢?

有人會問, 如果掃地捉bug的人多了, 僧多bug少怎么辦? 我只能說, 我非常期待沒bug可報的那一天 ;-) 其實很多開源項目每年"制造"的bug遠(yuǎn)不只200個, 比如Wine項目, 從2011年到2012年就增長了3500個bug. 粗略估計, 凡是ohloh.net上活躍貢獻(xiàn)人數(shù)排名前1000的項目, 每年都能制造成百上千個bug:?https://www.ohloh.net/p?page=100&sort=active_committers?如果你不信, 你給我錢我找給你看 XD 活躍的開源項目其實是一直在發(fā)展中的, 簡直可以說是批量生bug, 所以bug是永遠(yuǎn)捉不完的...

從捉bug入門進(jìn)階開發(fā), 不是新鮮事, 我只是跟隨前人的腳步走, 應(yīng)該感謝掃地的前人. 劉未鵬寫過一篇文章, 叫做 <<怎樣花兩年時間面試一個人>>, 我的掃地僧計劃有很大程度上受到了這篇文章的啟發(fā), 所以我還應(yīng)該謝謝劉未鵬 ^_^ <<做一名開源社區(qū)的掃地僧>>, 其實就是從學(xué)生的角度出發(fā), 對 <<怎樣花兩年時間面試一個人>> 的理論進(jìn)行實踐. 有(上)自然有(下), <<掃地僧(下)>>也大致預(yù)謀好了, 但現(xiàn)在仍不能劇透, 否則一旦失敗就變成搞笑劇了 冏 其實, 最完美的結(jié)果是, 這篇文章的學(xué)生讀者, 將來寫出成百上千各種版本的 <<掃地僧(下)>>.

雖然文章的標(biāo)題叫做掃地僧, 可是文章的內(nèi)容其實是"山寨掃地僧", 為了呼應(yīng)金庸原著中的絕世掃地僧, 在結(jié)尾向大家介紹Wine社區(qū)的掃地高僧 Anastasius Focht, 十一年來他分析了成百上千個bug, 他的bug report就是Wine的調(diào)試教材...?http://goo.gl/TxIvZ

最后, 感謝我的GSoC導(dǎo)師Aric Stewart, 在Wine的開發(fā)中給我很多幫助. Aric Stewart是日本人, 我們都希望中日和平友好. 我相信開源不分種族性別信仰和國界. 感謝 Dan Kegal, Bruno Jesus, Austin English, André Hentschel 等幫助和鼓勵過我的開發(fā)者, 盡管他們看不懂中文 :-\ 感謝Google Open Source Team, 8年來為培養(yǎng)開源社區(qū)新人做了很多貢獻(xiàn), 特別要感謝 Carol Smith, GSoC的成功舉辦離不開她.

親愛的讀者, 如果你讀到這里才想起自己已經(jīng)不是學(xué)生, 猛然意識到GSoC騙錢已經(jīng)與你無關(guān), 那我只能說非常抱歉, 騙你讀了這么久... 如果你想報復(fù)社會, 就轉(zhuǎn)載這篇文章吧...

小調(diào)查: CrossOver (Wine的商業(yè)版) 將專門為中文用戶提供中文技術(shù)支持以及特別優(yōu)惠. 如果你有時間, 請花3分鐘做一份關(guān)于 Wine / CrossOver 的調(diào)查, 一共只有6個問題, 非常感謝!?http://goo.gl/aEfE4

Qian Hong fracting AT gmail DOT com 2012-10-12

[注1] 要了解技術(shù)性的內(nèi)容, 可以看一下我的 "分享Wine調(diào)試經(jīng)驗" 系列, 比如:?https://groups.google.com/forum/?fromgroups=#!topic/gzlug/dGet0BGOikQ?[廣告1] 代Kexin姐發(fā)個廣告: 紅帽北京長期招內(nèi)核測試實習(xí)生, 歡迎在校學(xué)生投簡歷, google一下就可以找到相關(guān)信息. 如果感興趣但擔(dān)心自己達(dá)不到要求, 我建議從掃地開始 ;-) 如果掃地掃夠了準(zhǔn)備出山, 也可以發(fā)信問我要Kexin的聯(lián)系方式.

全文轉(zhuǎn)載自郵件列表

轉(zhuǎn)自：https://linuxtoy.org/archives/from-bug-reporter-google-summer-code.html

總結(jié)

以上是生活随笔為你收集整理的做一名开源社区的扫地僧的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。