做一名开源社区的扫地僧——从Bug report到Google Summer of Code(GSoC)：从200个bug到5000美金

        今年的软件自由日(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骗钱已经与你无关, 那我只能说非常抱歉, 骗你读了这么久... 如果你想报复社会, 就转载这篇文章吧...

                                                                                                                              Qian Hong fracting@gmail.com 2012-10-12

[注1] 要了解技术性的内容, 可以看一下我的 "分享Wine调试经验" 系列, 比如: https://groups.google.com/forum/?fromgroups=#!topic/gzlug/dGet0BGOikQ 

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