谷歌连续第二年举办了其 Google Summer of Code™ 计划，该计划旨在资助学生开发者为愿意指导参与者的开源组织做出贡献。2006 年的活动于 4 月至 9 月期间进行，积极的开发工作在 5 月 23 日至 8 月 21 日之间进行。

在四月中旬左右，当该计划刚刚开始时，一些 Boost 成员开始考虑以指导组织身份参与 Summer of Code 的可能性。尽管时间仓促且我们大多数人对这项计划完全陌生，但 Boost 还是成功申请了该计划。结果，十个项目被选中并得到指导，其中大多数项目有望在不久的将来完全贡献给 Boost。

我们在此提供关于此经历的总结报告，以及对我们发现的主要问题的简短分析，以便我们能够努力解决这些问题并在明年做得更好。

目录

• 计划如何运作
  • 2006 年数据
• Boost 的参与
  • 申请和流程选择
  • 已接受的项目
  • 开发
  • 结果
• 分析
  • Boost 的吸引力
  • 错失的机会？
  • 项目启动
  • 持续开发
  • 公共沟通问题
  • 项目范围
• 改进建议
  • 准备
  • 公共沟通
  • 项目管理
• 结论
• 致谢

计划如何运作

Google Summer of Code 中有三种类型的参与者

• Google 本身作为资助伙伴，负责整个计划的运作。
• 被该计划接受的开源组织必须指定组织内部人员担任项目导师。
• 学生提交他们的项目想法，如果被选中，则与其中一个指导组织合作；成功完成项目后，学生将获得该计划的全部津贴。

该计划经历以下阶段

• 组织选择：有意参加 Summer of Code 的开源组织向 Google 提交意向书，以及 Google 用于资格认证的信息。选定的组织将公开宣布，每个组织预计将提供一系列项目想法。
• 学生选择：有意参与的学生提交一个或多个项目提案，通常扩展指导组织先前提供的一些想法。一名学生可以多次申请并申请不同的组织，但最终只能选择一个项目。这些提案由 Google 路由到相应的组织，组织必须分析提案、对其进行排名，并将导师分配给最有希望的申请。根据指导组织提供的信息，Google 发布最终的已接受项目列表。
• 开发：学生在指定的导师的指导下，预计在三个月内完成项目。Google 要求导师进行中期项目审查，项目的继续进行取决于此审查。
• 最终审查：开发期结束后，导师需要告知 Google 项目的结果，并确定学生是否符合获得全额津贴的资格。

2006 年数据

2006 年 Google Summer of Code 活动于 4 月 14 日至 9 月 25 日期间举行。共有 102 个指导组织参与。在全球 3,044 名学生提交的 6,338 份申请中，最终有 630 份被选中并获得资助。Google 在学生津贴和对指导组织的补偿方面花费了超过 300 万美元。

Boost 的参与

申请和流程选择

4 月 14 日，在 Google Summer of Code 启动的同一天，Julio M. Merino Vidal（后来成为被选中的学生之一）发送了一条消息，鼓励 Boost 成员以指导组织身份参与该计划。这一呼吁引起了社区的兴趣；尽管为所有准备工作留出的时间已经很短，但 Boost 管理员迅速投入工作并进行了初步注册步骤。与此同时，Wiki 页面上增长了 Boost 成员提供的项目想法，总共超过 20 个提案。

到 5 月初，Boost 正式被该计划接受，Boost 管理员开始组建导师团队，导师根据邀请函进行选拔。由于学生选拔是一个细致的过程，涉及评估个人的技术技能，因此所有后续讨论均由选定的导师在为他们的协作建立的私人邮件列表中进行。

我们没有为随之而来的大量学生申请做好准备。在申请期开放后的第二天，我们收到了三个提案；第二天是 14 个，一周内计数超过 50 个。到申请期结束时，收到的提案总数为 174 个，这迫使我们进行非常密集的排名过程并招募额外的导师。为了合理化在数十个不同提案中进行选择的过程，我们遵循了两条规则

• 如果同一项目想法有相互竞争的申请，则最终只选择一个；因此，不接受目标相同或非常相似的两个项目。
• 一些申请建立在给定的 Boost 库之上（例如，Boost Graph Library 是添加算法的常见目标。）我们将每个 Boost 库的申请限制为最多两个。

这些规则的综合效果是大大减少了符合条件的申请数量，同时将接受的项目均匀地分布在想法空间中。此外，具有独特提案的学生，即项目想法并非来自 Boost 最初提出的想法池的学生，具有竞争优势。

不同的提案根据其相关的技术领域进行分类，以便每个集群可以由指定的导师处理，导师在该主题上具有所需的专业知识。然后，导师提交“重点报告”，总结其责任范围内的申请；这些报告充当第一道过滤器，以帮助减少最终要联合评估的申请数量。在此过程中，最有希望的提案的学生被要求完善他们的想法并提供更多信息。

尽管官方规则没有强制执行，但我们同意导师与学生的比例为一对一，这最终标志着符合条件的项目最大数量的硬性限制。

已接受的项目

Google 接受并资助了 Boost 认可的排名前十的项目。其中，八个项目是计划未来纳入 Boost 的库或库组件，而其余两个项目是严重依赖 Boost 的实用程序。

C++ 协程库
Giovanni Piero Deretta，导师 Eric Niebler。
通过现代 C++ 接口管理操作系统提供的协程设施的库。

并发库
Matthew Calabrese，导师 David Abrahams。
STL 风格的通用框架，用于并行算法的高级规范和执行。

TR1 数学特殊函数
Xiaogang Zhang，导师 John Maddock。
C++ 标准库扩展提案 TR1 中指定的 23 个特殊数学函数的实现。

Boost.Process 库
Julio M. Merino Vidal，导师 Jeff Garland。
用于进程启动和基本管理的便携式库。

核外图和图算法
Stéphane Zampelli，导师 Jeremy Siek。
Boost Graph Library 的扩展，用于处理核外结构，即数据集太大而无法一次保存在主内存中。

MISC (M)ulti (I)ndex (S)pecialized (C)ontainers（多索引专用容器）
Matías Capeletto，导师 Joaquín M López Muñoz。
内部基于 Boost.MultiIndex 的专用容器系列。

通用树容器
Bernhard Reiter，导师 René Rivera。
STL 兼容树容器系列的设计和实现。

FSM 查看器实用程序
Ioana Tibuleac，导师 Andreas Huber Dönni。
用于可视化使用 Boost.Statechart 指定的有限状态机 (FSM) 的实用程序。

模块化 C++ 预处理器，使用 Boost.Spirit
Hermanpreet 'Lally' Singh，导师 Joel de Guzman。
使用 Boost.Spirit 和 Boost.Wave 实现从模块化 C++（如 Daveed Vandevoorde 提出的向 C++ 添加模块的提案中所指定的）到标准 C++ 的前端转换器。

实现最先进的 Mincut/Maxflow 算法。
Stephan Diederich，导师 Douglas Gregor。
基于 Vladimir Kolmogorov 设计的新算法，为 Boost Graph Library 实现快速 mincut/maxflow 例程。

开发

设置了两个主要设施来协助学生和导师在开发阶段的工作：一个邮件列表和一个 Trac/SVN 项目管理系统，每个项目都有单独的目录。其中一位学生 Matías Capeletto 出于个人主动性注册了一个 Google Group，旨在为 Boost 学生提供一个非正式互动和讨论常见问题的场所。

在最初的预热期之后，每个学生-导师对主要私下进行开发工作。Boost 邮件列表的使用很少，直到计划结束时，一些学生才公开宣布他们的结果。

结果

到开发期正式结束之日，不同项目的状态如下

• 七个项目已完成或接近完成，预计学生将在 2006 年或 2007 年初申请正式审查。其中四个项目在开发过程中需要重新调整目标，主要是因为最初的计划对于三个月来说过于雄心勃勃。大多数项目在 Summer of Code 计划结束后的几个月内仍在积极开发中。
• 两个项目未达到计划目标，但仍然产生了有用的材料，可以在 Summer of Code 计划之外进行扩展。
• 一个项目在期中审查后不久被放弃。放弃的原因尚不清楚。

所有项目的结果都可以在专门的 Trac 站点上在线查阅。

分析

我们检查了 Boost 参与 Summer of Code 的各个阶段，重点是发现改进的机会。

Boost 的吸引力

在期中项目 OSCON 2006 演示文稿中，来自 Google 的 Chris DiBona 提供了一些关于收到最多申请的组织的数据

组织	申请数量
KDE	244
Ubuntu & Bazaar	236
Python 软件基金会	212
GNOME	199
Apache 软件基金会	190
Boost	174
Gaim	152
GNU 项目	148
Drupal	146

此处显示的数字是根据演示文稿幻灯片中包含的图表估算的。此图表包含一个额外的列，标记为“Google”，实际上解释了因质量低而被驳回的申请。

Boost 在总共 102 个组织中排名第六最具吸引力，这完全出乎意料，特别是考虑到其他顶级组织的广泛知名度。Boost 成员或多或少存在一种隐含的共识，即我们的项目是一个相对小众的项目，以其质量标准而为经验丰富的 C++ 从业者所知，但在入门级程序员中的渗透率有限：也许上面的数字应该让我们重新考虑这一假设。对提交给 Boost 的申请的粗略检查表明，大多数申请者都是 Boost 的 регуляр用户：许多人将 Boost 在 C++ 社区中的地位作为申请的一个有吸引力的因素。

错失的机会？

如果我们查看关于收到的申请的资助项目数量，那么数据对 Boost 来说并不那么有利。

组织	项目数量	项目/申请比率
KDE	24	9.8 %
Ubuntu & Bazaar	22	9.3 %
Python 软件基金会	23	10.8 %
GNOME	19	9.5 %
Apache 软件基金会	27	14.2 %
Boost	10	5.7 %
Gaim	8	5.3 %
GNU 项目	10	6.8 %
Drupal	14	9.6 %

事实证明，在排名前九的组织中，几乎任何其他组织的项目/申请比率都远高于 Boost。碰巧的是，Google 最初要求组织提交他们认为可以应付的最大项目数量，而我们获得的资助正是我们目标达成的数量，因此限制因素完全在 Boost 方面。

项目启动

为 Boost 做贡献依赖于相当多的编码、文档、测试和维护指南和协议。许多必需的工具专门在 Boost 内部使用，其中一些工具并非易事，例如 Boost.Build。虽然 Boost 网站包含有关所有这些工具和程序的信息，但这些信息分散在不相关的页面中，有时很难找到。

因此，开始在 Boost 工作需要大量的专业知识。一些学生报告了在开始阶段遇到困难，难以了解这些细节并熟悉工具，最值得注意的是 bjam 和 Quickbook。每个学生都自行克服了启动困难，或者求助于他们的导师（请参阅关于公共沟通问题的部分）。

持续开发

一旦学生度过了启动阶段，大多数项目都顺利进行，没有严重的并发症。在大多数情况下，在开发过程中的某个时刻意识到没有时间完成它。一些参与者不得不重新定义目标以使项目保持在计划之内，而另一些参与者则简单地决定在 Summer of Code 的官方截止日期之后继续工作。

双方通常报告说，每个学生及其导师之间的信息流动令人满意。那些缺乏沟通的项目恰恰是那些产生最差结果的项目。总的来说，导师并没有感到来自学生的请求不堪重负，甚至在少数情况下，项目实际上是在无人值守的情况下运行的。这一事实证明了招募到该计划中的学生的高能力。

Trac/SVN 系统的使用程度各不相同。一些学生频繁更新，而另一些学生只是使用存储库来转储最终结果，以便正式提交给 Google。

公共沟通问题

学生和导师可以使用三个不同的论坛进行公共信息交流和支持

• Boost 公共列表，特别是开发者和用户列表。
• 一个专门的邮件列表，可以联系到所有在 Boost 中参与 Summer of Code 的学生和导师。
• 一个更随意的 Google Group，由其中一位学生建立，旨在为参与者提供一个社交和解决常见问题的场所。

尽管资源丰富，但在所有相关方之间以及他们与更大的 Boost 社区之间几乎完全缺乏群体沟通。似乎学生们满足于仅仅依靠导师的支持来开展活动。这种情况阻止了 Boost 成员通过提供他们的经验和见解来丰富这项计划，并可能给学生们造成了错误的印象，即为 Boost 做贡献是按照从需求到工作完成的可预测的线性路径进行的。当被问及他们不参与公共沟通的原因时，学生们给出了模糊的理由，可以归类为以下几类

• 疑虑被认为过于技术性或具体，不值得公开提出。
• 对完美主义的渴望使学生不愿在公开场合提问或提交正在进行的工作，直到他们觉得自己的材料看起来足够好为止。
• 害羞：一些学生可能缺乏以前公开交流的经验，而且大多数人的母语不是英语，这也可能是一个限制因素。

尽管学生们没有将以下原因确定为不公开的原因，但很可能他们中的许多人并没有感到需要，因为他们可以随时获得导师的支持。很容易习惯这种专门的支持来源，而忽略求助于其他资源。导师应该鼓励他们的学生公开讨论项目，这构成了 Boost 卓越品质的支柱之一。

项目范围

事后看来，已经很明显，大多数项目对于在计划的三个月期限内完成来说都过于雄心勃勃，即使是那些被认为是成功的项目，也需要数周或数月的时间进行润色，然后才能准备好进行正式审查。与其他参与 Summer of Code 计划的组织相比，截至本文撰写之时，Boost 尚未将其任何成果纳入其代码库。尚未要求对任何项目进行正式审查。

这些范围问题非常依赖于特定类型的项目。我们可以将 Summer of Code 的 Boost 项目分类如下

• 成熟的库，
• 对现有 Boost 库的补充，
• 使用 Boost 的实用程序和工具项目。

在这些项目中，补充（例如 Stephan Diederich 为 BGL 提供的最大流最小割算法）最适合在短时间内完成：大部分准备工作已经完成，学生对于要遵循的编码和文档标准有明确的指导。此外，这些项目不需要进行正式审查，因为审查代码并将其纳入其酌情权范围内是托管库作者的责任。实用程序项目似乎也适合较短的时间范围，尽管大多数项目提案和请求自然而然地倾向于对 Boost 项目的实际代码贡献。

至于那些涉及成熟库的设计和实现的项目，几乎不可能将目标和范围保持足够适中，以适应三个月的计划。专业作者开发的 Boost 候选库通常需要比三个月更长的时间才能被接受；一些库在被纳入 Boost 之前已经发展了数年。因此，如果我们要在 Summer of Code 内部支持 Boost 库项目的实现，我们所能期望的最佳结果是，到计划结束时，对结果的评估可以构成对 Boost 的可行潜在贡献。在这种情况下，至关重要的是，学生承诺继续从事该项目，直至完成和正式审查。也许比编写库代码更重要的是让新作者与 Boost 项目建立长期关系。

改进建议

以下提案旨在缓解我们在 Boost 内 Summer of Code 开发过程中发现的一些问题。这些行动要点仅与在 Boost 连接中发现的问题有关：我们没有解决与 Summer of Code 计划本身相关的其他改进领域。

准备

在实际计划开始之前，可以做很多工作。以下准备活动已经可以启动

创建项目想法池。此操作将为在 Summer of Code 开始之前评估和完善想法提供宝贵的额外时间。经验表明，那些准备工作更多，尤其是在设计领域的项目，最终更成功。该池还可以用于保留在邮件列表中出现的有趣想法，这些想法通常未得到适当的关注而被放弃。

创建学生池。事先参与 Boost 对于选择阶段和后期的项目开发都是一个优势。那些对参与 Boost 的 Summer of Code 计划有认真兴趣的学生可以进入学生池，并在夏季之前很早就开始探索想法并与社区互动，以便使自己处于选择的有利位置。可以在 2007 年初通过常用渠道（网站和邮件列表）启动学生池的宣传：此外，参与大学的 Boost 成员可以在当地传播此信息，并帮助提高他们环境中的学生的兴趣。

创建导师池。鉴于 Boost 匆忙参加 2006 年 Summer of Code 活动，导师的邀请必须按需进行，因为事实证明任务变得越来越大。组织必须为明年做好更好的准备，以便预先确定一些有能力和意愿作为 Boost 导师参与的人员。

准备启动包。为了方便学生熟悉各种 Boost 指南、协议和工具的初始阶段，准备一份学生启动材料汇编将非常有用。此包可以包含一份收集当前分散信息的单个文档，或者超出此范围并提供一些文档和预构建工具的捆绑包，其中一位学生目前正在研究这种方法。

公共沟通

学生必须尽快参与社区，并逐渐认识到公共开发相对于单独编码的优势。

强制执行（双）周报。这些报告应 направлены 到公共邮件列表，以便所有 Boost 成员都可以跟踪正在进行的工作并做出贡献。报告对学生来说还有额外的好处，即迫使他们定期反思自己的工作，并努力完成向他人展示自己的想法这项通常很困难的任务。

完全通过公共渠道进行学生-导师交流。这可能是一个过于严厉的政策，因为有些事项需要保密，并且根据交换的信息量，可能会出现洪泛问题。不太严格的变化包括允许导师自行决定进行一些私人交流，并将此类交流转移到与通用邮件列表不同的专用公共邮件列表。

项目管理

关于管理，需要改进的两个最重要的问题是

• 项目范围必须受到控制，
• 进度必须公开可见，以便更容易检测到范围、设计和/或计划问题。

本节中的一些提案不应被视为严格的规则，而应被视为学生牢记并受到导师鼓励的一般指南。

创建最佳实践文档。此文档可以作为项目管理的指南，Boost 传统上对此领域不作任何要求。学生可能缺乏该领域的专业知识，而专业知识在传统模型中通常被认为是理所当然的，在传统模型中，对 Boost 的贡献是由专业程序员做出的。

强制执行设计阶段。在项目早期建立并清楚描述具体设计将有助于估计完成工作所需的努力。这也是公开讨论的机会。

并行维护代码、文档和测试。新手程序员通常会一蹴而就地完成编码，然后才转向测试和记录他们的工作。这在当前的所有方法论标准中都是不可接受的，并可能导致严重低估完成时间。

鼓励 KISS 原则。最好完成一个更简单的库，然后在将其暴露于公众审查和使用后迭代地发展它。

更多 Trac 更新。存储库应被视为日常工作工具，而不仅仅是转储最终结果的地方。频繁更新可以提高导师和公众对工作的可见性。

非正式审查。正如前面讨论的那样，典型的 Summer of Code Boost 项目不会在官方截止日期前完成。为了以某种方式正式化在 Summer of Code 计划内完成的工作，并允许学生达到某种心理里程碑，可以建立非正式审查，Boost 成员可以在其中评估在 Summer of Code 结束时完成的工作。

吸引学生。这项经验表明，有可能引导有能力和意愿的学生达到为 Boost 做出贡献所需的胜任力水平。Summer of Code 活动的最佳结果是将新人纳入 Boost 活跃贡献者的圈子。努力让学生致力于 Boost。

结论

尽管 Boost 缺乏先前的经验，但我们参与 Google Summer of Code 计划非常富有成效：产生了许多有用的材料，也许更重要的是，一些学生可能会长期投入，并成长为 Boost 的常规贡献者。传统上，由于极高的质量标准、缺乏公共支持以及项目非常具体的文化，成为高效的 Boost 作者具有非常高的入门门槛。Summer of Code 本身的吸引力以及在 Boost 世界中接受温和指导的可能性很可能是在降低这一入门门槛方面发挥了关键作用。

正如 Boost 作为一个新组织所预期的那样，这个过程也并非没有一些困难。我们试图在本文中找出需要改进的领域，并提出具体的行动方案，以便即将到来的 2007 年 Google Summer of Code 计划能够成为一次更加有益的体验。

致谢

如果没有 Boost 学生和导师慷慨提供的众多报告和贡献，本文就无法完成：非常感谢所有参与者与我分享他们的经验。还要感谢 Google 的人员推广和实施了 Summer of Code 计划。