每一个山寨扫地僧都是励志帝——从开源社区说起

不知道怎么为开源软件做贡献？从汇报 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 ;-)