GSOC
各位同学：
新年好，
我是洪谦，自封的 Google 开源代码夏令营助教。
两年前，我写了《做一名开源社区的扫地僧(上)》，记录了我在开源社区中打怪升级的经历和收获，以5000美金奖金为诱饵，怂恿在校的朋友参加 Google代码夏令营。说来惭愧，这篇文章冗长罗嗦，可恰是这篇文章让我认识了这么多开源社区的朋友，有的朋友见面就问我《扫地僧（下）》什么时候问世，我总是一拖再拖，不好意思又跳票了。
这次新作拙文请大家评阅，一方面是再度为 Google Summer of Code 做免费宣传，另一方面其实是抱着私心，诚恳地希望找到志同道合的朋友加入 Wine 项目。
文章一如既往的冗长罗嗦，一如既往的只限学生阅读 :)
Google Summer of Code 是 Google 于2005年发起的学生夏令营，由 Google 赞助，联合全球知名开源项目，共同培养开源社区接班人。Google 为开源项目提供预算，开源项目为学生提供一对一导师，学生远程办公完成为期三个月的 coding 课题，获得5000美金的奖金，形象地说类似于实习工资。GSoC 的官方网站有详细的介绍
参与 Google Summer of Code 有什么好处呢？
首先当然是5000美金奖金。
同学，谈钱太俗。。。我们还是谈谈感情吧。拿到5000美金奖金，分一半给我好伐！
不开玩笑，其实5000美金不算多。在美国，学生视野比较广，实习工资比较高，创业公司遍地，GSoC 只是无数选择之一，如今每年参与 GSoC 的美国学生已经没有印度学生多。就算在中国大陆，3个月5000美金的实习工资，也仍然不算多。大学里比较牛的同学，几个人自己组建工作室，接一些外包项目，一个月赚一两万以上，也不是奇怪的事情。而参与GSoC，表面上是3个月，其实前期准备也要一两个月甚至更多的时间，平均下来就更少了，技术难度却往往比一般的外包项目大，还要克服语言障碍。。。
咳咳，谈钱太俗。。。我们还是谈谈开源吧。。。
几乎每个 geek 同学，或多或少都曾经是某个开源项目的粉丝，幻想过给自己喜欢的开源项目贡献代码，可是能走到这一步的人却不多。对于一个有着 geek 梦的人，参与自己喜欢的开源项目，本身就是一种奖励，还有什么比实现看似天马行空甚至不切实际的幻想更激动人心呢？
Geek 从来不缺乏疯狂的想法，却往往不容易找到同样的疯子 ── 好不容易找到一群疯子，却发现每个人都有不同的疯法，每个人的想法都很有趣，每个点子都缺人，每个人都在找跟自己一样的疯子。开源项目最神奇的一点，就是把世界各地有相同想法的 geek 联系起来，通过互联网进行协作沟通，完成任何单独一个个人都做不到的事情。BeagleBoard 的开发者，想拥有自己的开源开发板；OpenRISC 的开发者，想设计自己的开源 CPU；CyanogenMod 的开发者，想用自己的纯开源手机系统替代 Android；RepRap 的开发者，想拥有自己的开源 3D 打印机。。对于普通人来说，很多开源项目可能跟自己没什么关系，但是对于这些开源开发者来说，他们可能找了很久才找到自己的同类组建成了开源社区。如果有好的想法却找不到合作者，与其孤军奋斗或者眼看着点子在拖延中烂掉，不如尝试到开源社区中寻找同类。Open Hub 收录了全球60万个开源项目，活跃项目接近一万，也许这一万个项目中就有一个能找到自己的同类
参与开源项目，可以锻炼技术，可以开拓眼界，可以认识世界各地的朋友，这些都是老生常谈，可是说起来容易做起来难。为了降低新人加入开源项目的门槛，Google 举办了代码夏令营活动，鼓励和引导对开源感兴趣的学生参与到开源实践中。很多 GSoC 学生，后来都成为开源项目的活跃贡献者，甚至成为新一代 GSoC 的导师，指导新一代的学生。GSoC 奖励学生现金，但导师是义务的，所以愿意做导师的，都是非常在意自己的开源项目的。如果非要说福利的话，导师的福利是有机会得到赞助去 Google 总部参加 GSoC Mentor 聚会 :)
然而，即使有了 GSoC，参与开源项目仍然有一定的门槛。Google 每年赞助约1000个学生名额，分配给大约两百个开源项目组织，而全球每年申请 GSoC 的学生就有4000人，竞争程度虽不算激烈，但也不简单，对于母语非英语的同学来说，更多了一层障碍。
2012年，我通过 GSoC 加入了 Wine 项目的开发，成为 Wine 项目的第一个中国学生。
Wine 是一个开源的 Windows API 兼容层，通过 Wine 可以在 Linux 和 Mac 上运行 Windows 软件，比如 QQ，Office，WOW，等等
对于这个项目，开源社区的朋友爱之恨之不屑之都有，作为 Wine 项目的开发者，我们常常自嘲只有脑子不正常的人才会开发 Wine :)
作为一个不正常的 Wine 开发者，要找到自己的同类是很不容易的事情。为了这份私心，GSoC2012之后，我又陆续帮助一些朋友申请和参与 GSoC。在交流的过程中，我发现中国学生的技术能力不差，但沟通水平却参差不齐，尤其是英文沟通，很多人不敢下笔写英文邮件，殊不知别人也是查 Google 翻译的 233
经过共同的努力，有两名中国学生克服了包括英文沟通在内的各种困难，参与了 GSoC2013，为 Wine 项目贡献了代码， GSoC2014 则增加到三名。如果算上在我怂恿下参与其他开源项目的朋友，Google 已经间接被我“骗”了几万美金奖金了。这些同学中，从大一到研一都有，英语水平有的很好有的很烂，从很烂到极烂都有，技术储备也有强有弱，但共同的特点是每个人都提前准备了很长时间。也正是这个过程，我积累了一些作为 Google
代码夏令营“非官方助教”的经验。
根据 GSoC 的官方流程，学生在申请名额的过程中，需要向开源社区提交提案，和开发者进行沟通，改进自己的提案，做出必要的准备工作证明自己有能力完成课题，联系潜在的导师，制定合理的进度计划，等等等等。在官方的“玩法”中，并没有“助教”这个角色，所以我只是一个“自封”的助教。为什么需要一个助教呢？因为我发现，开源项目需要一个角色，来填充导师和学生之间的距离。
举一个毫无技术含量的例子：很多第一次申请 GSoC 的学生，英文邮件中往往有各种各样的毛病，比如乱用或不用空格，比如完全不注意大小写，再比如不会说谢谢，等等。看看 GSoC 邮件列表里中国学生的英文邮件，三个人有两个从不说 thanks，还有一个从头到尾只说过一次
thanks。只是开个玩笑，没这么严重，但这是个很好的例子，像这样的沟通上的细节，“导师”这个角色是不适合帮学生指正的，而“助教”这个角色却可以私下帮学生指出来。
客观的说，沟通上的细节无伤大雅，导师也未必就会介意，最多只是觉得这个人怪怪的 XD
但是，作为“助教”，可以做的还有很多。比如说，有的同学除了考试作文之外从来没写过英文邮件，申请 GSoC
勇气不足，即使鼓起勇气发出申请邮件，也未必能一次性表达清楚自己的意思，这时候，作为“助教”，可以先私下帮学生“批改作文”，哪怕一字不改，有个人帮忙读过，对于申请的同学也是一种鼓励和肯定。再比如说，申请邮件发出之后万一石沉大海，没人指点的同学可能就会困惑甚至放弃，而作为“助教”则可以帮忙分析和跟进，甚至预先提示避免出现这样的情况，例如万万不要一封申请邮件一字不改同时发送给多个开源项目，要知道程序员都会 Google，这种申请者注定当炮灰的。再比如，学生和导师交流的过程中，可能会误解导师的意思，参与过
GSoC 的“助教”可以帮助学生提高沟通效率，避免卡顿。有时候学生没有仔细阅读文档导致低级错误，有个“助教”骂一骂，老老实实再读一遍文档，可能就解决问题了；也有时候仔细读再多文档，还不如跟“助教”聊一聊天，因为有些东西实在是文档里没有的。万一学生申请没有通过，作为导师能够提供的帮助可能不多，但作为“助教”却可以帮忙分析问题总结经验，制定长期的学习计划，为新一年的 GSoC 做准备，对于积极上进的好青年，学到东西才是最重要的。
只要解决沟通的问题，那么在申请 GSoC 的过程中，中国学生跟英语国家的学生就基本站在同一起跑线上了，但是要想占更大优势，还需要更多努力，其中一个效果明显的方法就是提前准备，持续准备。2014年，Wine 项目的学生名额有 ¾ 是中国人，相比过去几乎20年没有中国人参与，已经是一个巨大的转变，而这几位学生都至少提早了几个月准备。在准备的过程中，作为助教可以提供各种技术上的支持，包括开源项目工作流的讲解，工具链的使用，具体技术方案的探讨，等等。然而，说来惭愧，过去两年我曾多次在不同场合介绍 Wine 项目并且鼓励学生参与，可是却没能做到为每一位“上当受骗”的同学提供长期的支持，有的同学浅尝辄止，没能达到给开源项目成功提交补丁这一步，这一方面是因为 Wine 项目门槛实在比较高，另外一方面也是因为我个人的精力不够。 培养一个新开发者挺不容易的，新同学刚加入的时候，我常常需要先自己动手完成一个简单的任务，然后把完成过程按住不表，让新同学去练手并不断提出修改意见。换句话说，新同学实现并提交给 Wine 项目的补丁，有一些我已经提前写过一次。如果不这样做，心中就没有一个足够好的“参考答案”，在修改新同学的代码的时候很可能力不从心。事实证明，这样做虽然苦逼，但是效果挺好的。在成功提交一两个补丁之后，参与的同学的信心和积极性都提高了不少，更容易进入自我驱动的状态，后面需要的帮助就越来越少。
好消息是，经过这两年的努力，参与 Wine 项目的中国学生多了起来，“GSoC 助教”也渐渐扩展为“GSoC 助教团”。我们希望吸收更多的中文开发者进来，进一步扩充 Wine 项目的开发队伍。
Wine 是一个巨大的开源项目。从愿景上来说，Wine 社区希望 Wine 可以让所有 Windows 用户可以无痛迁移到 Linux 平台，带动起良性循环，让更多厂商为 Linux 开发商业软件。在我看来，Wine 项目之于 Linux 桌面软件生态的发展，就跟“自举”之于复杂系统的开发一样重要。 Linux 内核的第一个版本，是在非 Linux
平台上编写的；64位平台上的第一个编译器，是在32位平台上交叉编译的；第一个vi编辑器和第一个emacs编辑器的代码，既不是在vi也不是在emacs编辑器中编写的。所有复杂系统的开发过程都是渐进的，在拐点到来之前，无法脱离旧系统的支持，而一旦拐点到来，就可以自成体系，就跟编译器完成自举一样。作为一个geek，我十分理解，对于单独任何一位 geek，都可以脱离 Windows 软件在 Linux 世界中活得很自在。可是世界并不完全是由 geek 组成的，生态成熟如 Android 的平台，用户群体也远不止只有 geek。如果把 Linux
桌面生态当作一个整体，Windows 软件是目前不可忽略的环节。完全脱离 Windows 软件发展 Linux 桌面生态，就像在新平台上用汇编代码手写编译器一样，说说容易，细思极恐。而借力 Windows 软件发展 Linux 生态，就像用旧平台开发和交叉编译新平台的编译器，听起来高深，实践起来却是经济省时的道路。一旦我们完成 Linux 生态的自举，拐点到来，Wine 项目的历史使命就会完成，不管 Windows 下一步如何发展还是如何衰落，Linux
生态都不会受影响，就像拐点之后， Emacs 开发者用 Emacs 开发 Emacs 代码，git 开发者用 git 管理 git 代码， gcc 开发者用 gcc 编译 gcc 一样。
Wine 项目富有争议，其实批评和支持本质上是哲学观点的不同，争论是不会有结果的，只有实践才有说服力。不管怎么说，支持和批评，都是一种自由。相比起纸上谈兵的批评，那些行动者更值得尊重，所以有人不喜欢在 Wine 上运行 QQ，于是发起和参与了开源聊天工具项目，有人不喜欢在 Wine 上运行 Office，因此加入 LibreOffice 等开源办公软件项目，有人不喜欢 Wine 本身，因此为 Virtualbox
这样的开源虚拟机项目贡献代码。这些人都用行动为开源软件生态做出了贡献，我自己也是 LibreOffice，Virtualbox 等开源软件的用户，我也感激这些项目的劳动。值得一提的是，现实中很多开源社区是交叉重叠的，Wine 项目的开发者，给 Linux 内核，git，emacs，Xorg，Firefox 等项目报告过 bug 提交过补丁，反过来也可以说这些项目的贡献者同时在参与 Wine 项目。 在过去的22年中，全球累计有一千多名贡献者给 Wine
项目提交过补丁。实际上小部分核心开发者贡献了大部分的工作，虽然过去12个月有100人向 Wine 项目贡献过代码，但核心开发人数只有20人左右
根据 Wine 项目的兼容数据库，Wine 项目目前支持的 Windows 软件有一万多个，其中包含了一些大型软件如 Office 和 WOW，也有各种各样的不知名的小众软件。粗略估计，Wine 项目用 400 多人年的开发人力，为 Linux 生态丰富了一万多种应用，如果全部从头开发，不知要多少人力。Linux 用户群体，尤其是企业用户，对 Windows 应用的需求，远超一般人的想象。CodeWeavers 基于 Wine
项目开发商业应用并提供商业支持，根据我们的统计，我们的用户总共需要超过五万种不同的 Windows 应用。在未来的五年，由于多国政府的操作系统迁移，全球的 Wine 技术工程师会供不应求，希望未来合适的时机可以跟大家分享更多商业上的细节。
技术上说，Wine 项目很难。我们不敢说 Wine 是全球最难的开源项目，但是说 Wine 是全球最苦逼的开源项目是当之无愧的。首先要开发 Wine 必须同时熟悉 Windows 和 Linux 这两个平台，而 Windows API 非常多，据不完全统计有超过9万个函数，Wine 项目目前能够兼容的还不到7万。其次，作为闭源 Windows API 的开源实现，Wine 开发者既要懂得逆向工程的技术，又不能采取任何侵权的手段，一切不公开的细节都只能通过黑盒测试来推测。还有，虽然 Wine 本身是开源的，可是用户在 Wine 上运行的软件通常都是闭源的，学习如何调试一个没有源码的软件，是一个非常漫长的过程。此外，Wine 涉及的编程知识和领域知识都非常多。比如说，要完成 DirectX 到 OpenGL 的嫁接，不仅需要懂两种 shader language，还需要懂编译原理，将一种 shader 指令编译为另一种；要实现兼容 IE 的 jscript / vbscript 解释器引擎，不仅要懂 jscript / vbscript 脚本和 HTML，还要懂编译原理；要实现 dom xml 解析器，不仅要熟悉 DOM 标准，还要懂编译原理；实现 Wine 自带的调试器，当然更要懂编译原理。。。这样的例子还有很多，可以说，Wine 项目简直就是为受虐狂特设的，喜欢操作系统底层原理，对编程语言内部实现感兴趣，或者对网络协议感兴趣，或者对逆向工程感兴趣，或者其他各种技术非常 geek 的同学，可能会在 Wine 项目的开发中找到很多乐趣，也可能会因为 Wine 项目被迫将大学的计算机基础课程重新学一遍。
虽然 Wine 项目很难，但是 Wine 社区的一些开发者实在让人惊叹，例如 Jacek Caban 高中就参与 Wine 项目，刚上大学就成为全职 Wine 开发者，基于 Mozilla Gecko 内核实现了 IE 引擎 mshtml 的开源兼容版本，顺便给 gecko 和 MinGW 项目贡献了很多补丁，如今已经连续贡献超过十年，连 Firefox 社区都有开发者反过来向 Jacek Caban 请教问题。再比如 Piotr Caban 几乎以一己之力实现了 C++ 运行库 msvcp 的开源兼容版本，两年的时间就完成了上万个函数，如今已经投入商业应用。再比如 Henri 和 Stefan 等人实现了 Wine DirectX 兼容层，André Hentschel 一人完成了 Wine 的 ARM 移植，Juan Lang 等人实现了 Wine 的 RSA / DSS 等加密库，还有很多外人不知道水有多深的难题，例如绘图底层支持，Unicode支持，网络底层支持，等等等等，更不用说 Alexandre Julliard 二十年如一日维护 Wine 项目，审阅每个人的补丁，维护两百万行 C 代码，其工作量之大难度之高难以描述。
我常常感叹自己可能永远达不到 Wine 项目最顶尖的开发者的高度，但加入 Wine 社区以来我也一直不断挑战新的难题，提交了上百个补丁，做到了过去想不到的事情。更让我欣喜的是，加入 Wine 项目的年轻中国学生，做得都不错，提交了几十个补丁，有几位在各自擅长的领域已经超过我，比如有同学因为 Wine 项目而给 gecko 提交了补丁 :)
Wine 项目太难，人力成本太贵，所以海外 Wine 开发者没有在培养新开发者上做过太深入的尝试。如今我们已经在培养新人上走出了一小步，Wine 中文社区也算是做出了一些国外社区没做过的事情，希望新的一年里能够更进一步。
我们希望和对 Wine 项目感兴趣的同学共同进步。如果你的C语言基础扎实，如果你熟悉 Windows 或 Linux 任一一种平台的开发并且不介意学习另一种，如果你对操作系统原理和编程语言原理之类的底层细节感兴趣，如果你算法能力强又不介意做底层开发这种脏活累活，如果你对逆向工程感兴趣又愿意为了代码版权放弃传统白盒逆向手段，如果你数学好但找不到工作。。。如果你符合上述任何一点，就是我们日夜期待的队友。如果你还懂得“结果倒推行动”的思维方式，那你可能是 Wine
社区明日的中流砥柱。正是因为认同“结果倒推行动”的思维方式，为了 Wine 项目的长远发展，我们才会把培养新人看得跟个人的技术学习一样重要。
根据以往的经验，一个C语言合格的学生，经过一定的协助，一个月到半年可以给 Wine 项目成功提交第一批补丁，而成为成熟的 Wine 开发者可能需要一到三年，因人而异。培养一个开源开发者的成本如此高，如果由于生活工作的琐事而放弃开源项目实在可惜，因此对于已经向 Wine 项目做出一定贡献并且有志于长期参与 Wine 项目的同学，我们会尽可能提供工作机会，支持尽可能多的全职开源开发者。同时，我们也提供实习机会，前提也是成功提交一定数量和质量的补丁
如何加入 Wine 项目呢？
我们希望能够吸收10到20位在校的同学加入我们今年的新人培养计划，在线交流，当然也可能会有同城聚会。凡是能够独立搜索网络资料，通过git下载最新的 Wine 源代码，并完成编译安装的同学，都满足我们的最低技术要求。编程经验当然越多越好，能读懂 Linux C 一站式编程第三章的同学基础都是很不错的。
对于特别厉害的同学，也许可以通过Wine 项目官网的资料，研究 Wine 项目未解决的 bug，参考前人的bug 分析，深入阅读开发文档，独立给 Wine 项目提交补丁修复 bug。
如果你达到了这样的水平，我想问一下，土豪我们做朋友好吗？
对于对技术有信心但对 Wine 社区的开发流程不熟悉的同学，我们欢迎你订阅 wine-zh 邮件列表参与讨论，wine-zh 列表是一个过渡区，帮助英文交流不顺畅的同学克服心理和语言障碍，我们翻译和撰写了部分中文文档，例如： 《Wine 社区的基础设施和贡献简明指引》
我们鼓励中文社区的 Wine 贡献者未来直接参与上游英文社区。
对于不介意从一些简单任务开始练手入门的同学，我们准备了一门“公共选修课”，主要包括两部分，第一部分是共同研究和改进 Wine 项目的 mshtml 模块，这个模块有大量入门级的工作，只要基本的HTML/DOM/C知识就可以上手，深挖进去则是个无底洞，做出来的成果可以改进 Wine IE 的兼容性，不仅有潜力支持各种网银和教务系统，而且在企业应用中有大量的需求。 第二部分是已经被 Wine 项目修复的 bug 案例分析讲解，例如这类入门级的Bug，借此入门黑盒逆向工程，并且进一步优化调试方法，分享调试思路和经验。
除了“公共选修课”，我们也会开设“专题讨论组”。
- 如果你对密码学感兴趣，我们可以一起研究 Wine 项目的 rsaenh 等加密解密模块；
- 如果你对编程语言解释器引擎实现感兴趣，我们可以一起研究 vbscript / jscript 等模块；
- 如果你对 C/C++ 库函数实现感兴趣，我们可以一起研究 MS VC/VC++ runtime；
- 如果你对 DirectX 或者 OpenGL 有研究，可以探索 Wine 的 DirectX 兼容层；
- 如果你逆向过学校的校园网客户端协议，那么你可能会喜欢参与 wininet / winhttp / winsock 等模块的开发；
- 如果你逆向过文件格式，那么类似 typelib 支持这样的大坑在等着你跳；
- 如果你有v4l的编程经验，那么你一定有兴趣改进 Wine 的视频支持；
- 如果你对图像视频编码解码感兴趣，那么欢迎改进 Wine 的编码解码器；
- 如果你希望改进 Wine 的 UI 主题，或者改进 Wine 的性能，或者改进 Wine 对具体某个游戏的支持，甚至改进 Wine 的 USB 驱动支持，都可以成为学习的东西； -如果你读汇编代码就跟看小说一样，那么请先接受膜拜再麻烦土豪指点解决各种疑难杂症。
总之，不管你在编程方面有什么爱好特长，几乎都能在 Wine 项目中找到感兴趣的领域，9万个API函数难道没有一个你喜欢的菜？当然，有些任务的难度超乎想象，我们会在适当的时候提示，前方高能 233
对于“公共选修课”，我们希望每个任务同时分发给10到20个同学做，这样对于“助教”们来说比较轻松，但对于参与的同学可能会有点乏味，做的内容都一样，并且最终不一定能提交给 Wine
项目。对于“专题讨论组”，我们希望每个课题有2到3人一起讨论，很多问题会很有挑战，但是我们只能帮到半路，因为除非亲自做一遍，不然连“助教”们也未必知道答案，只能是尽力帮助同学们提供方向和挖掘潜能。参与的同学需要尽可能挑选感兴趣的课题，才容易坚持下来克服困难。我们将帮助同学们了解 Wine 项目的技术和非技术知识，创建一个讨论交流的氛围，协助同学们申请 Wine 项目的 Google Summer of Code，但不以 GSoC
为核心目标，最重要的目标仍然是做出技术上的成果。为了完成目标，我们也希望参与的同学能够全力投入，把 Wine 项目作为业余时间最主要的研究课题，并做好坚持投入半年以上的准备。现在离 GSoC 2015 正式公布有整整一个月的时间，离申请截止日期有两个多月的时间，离正式开始编程有四个多月的时间，寒假即将开始，现在正是开始准备的最好时机，期待与同学们的交流。
什么人不适合开发 Wine 呢？
如果你已经在读研究生博士生，对语音识别图像检测自然语言处理数据挖掘人工智能等各种高科技有研究，那么我们建议继续专注自己的本行深入研究，参与 Wine 项目开发可能大材小用，每个人都有各自的机会成本。顺便提一下，我们最近请了研究图像识别的同学帮忙做一项实验，通过 PCANet 算法，对开源的Symbola，OpenSymbol 和 Anasa-Math 三个字体合计数万个字符进行图像识别，从结果中找出全等或接近 Wingdings/Webdings/MT Extra
等闭源字体合计上千个字符的元素，用于实现开源版的字体贡献给 Wine 项目。也就是说，图像识别之类的高科技，在 Wine 项目中也能发挥作用，但这样的应用场景可能是可遇不可求的。
如果你现在刚学习编程不久，Wine 项目可能太难，但是我们非常欢迎编程初学者关注 Wine 项目。今年我们可能没有精力为编程初学者提供帮助，但是如果今年的新人培养计划能够成功，明年就会多出很多“助教”，那个时候我们可以制定更大的计划。而一年的时间也足够自学很多东西，比如 Linux C 一站式教材，就是对 Wine 开发非常有帮助的资料，能够吃透这本教材的同学，稍微训练就能入门 Wine 开发了。我们长期的愿望是，大一的同学初步了解Wine 项目，提交一些 bug 报告练练手，大二贡献一些入门的补丁，到大四毕业就可以成为优秀的 Wine 开发者，并且加入我们成为全职的开源开发者。我们鼓励工程师远程办公，如果可以顺便为降低大城市的雾霾水平，拥挤水平和房价水平做一点贡献就更好了。我们也鼓励工程师参与国内外技术大会的演讲，希望可以在比利时 FOSDEM 或者美国 WineConf 上看到更多中文社区的朋友。当然，有了 Wine 开发的背景，Windows 和 Linux 通吃，转行也是不难的，我们也支持同学们通过 Wine 项目入门开源开发，再为其他开源项目做贡献，如果你搞得定 Wine 项目，那么世界上没有几个项目搞不定了。
能够完整读到这里的朋友，真的是辛苦了，非常感谢。Wine 的开发调试很难，修一个中等难度的 bug 就跟完成一场连续三天的开卷数学竞赛一样难，只有真正喜欢挑战的人才适合参加。如果没有长时间集中精神的能力，或者分阶段消解问题的能力，很难胜任 Wine 的开发。这篇文章的冗长是特意制作的，如果你读到这里，不管是一次读完，还是多次读完，都已经满足 Wine 开发最基本的非技术要求。对于这样的人，我想说：请联系我！
如何联系我们呢？
欢迎订阅邮件列表，通过 wine-zh AT freelists DOT org 列表联系我们：https://www.winehq.org/forums
如对邮件列表不熟悉，请搜索《邮件列表礼仪》。
我们还会定期或者不定期在 IRC / slack 等平台上聚会交流，也欢迎你带来更 geek 或更方便的交流方式。
我们希望 GSoC 助教团一年比一年壮大，也希望更多开源项目的支持者像我们一样，为了类似的“私心”，建立类似的助教团，帮助更多人加入自己喜欢的开源项目。如果多一些人做这样的事情，相信 GSoC 的中国学生迟早会超过印度 :)
希望在大家的努力下，未来 Wine 项目会给 Linux 桌面生态带来革命。这是一个自证预言，如果你相信，它就会实现。
对了，如果你读完发现上当了，不妨随手转发，报复社会
谢谢。
附录：
中文社区向 Wine 项目提交的补丁（包括海外华人贡献者，欢迎补漏）