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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

怎么報bug呢? 其實每一個成熟的開源項目都有詳細的bug report guide line, 只要照著文檔去做, 就知道怎么報bug. 如果從來沒讀過這類文檔, 可以試試google一下下面的關鍵詞組合: 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美金 ;-)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

值得強調的是, 如果你的目標是從報bug入門進階為開發, 那么從一開始就應該訂閱開源項目的patch列表和devel列表, 一開始讀不懂不要緊, 長期耳濡目染, 量變可能會引起質變, 這也是一種"掃地".

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

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

• 報bug的過程可以跟開發者熟悉甚至成為朋友, 將來他們能夠對你有很多幫助, 有開發方面的問題可以向他們請教.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

全文轉載自郵件列表

轉自：https://linuxtoy.org/archives/from-bug-reporter-google-summer-code.html

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。