谷歌连续第二年举办了 编程之夏™ 活动，这是一项由学生开发者在其导师愿意指导参与者的开源组织中贡献而获得赞助的项目。2006 年的活动于 4 月至 9 月期间举行，其中活跃开发工作在 5 月 23 日至 8 月 21 日之间进行。

大约在四月中旬，当项目刚刚开始时，一些 Boost 成员开始考虑将 Boost 作为导师组织加入编程之夏的可能性。尽管时间紧迫，而且我们大多数人对这项活动完全陌生，但 Boost 还是成功地申请加入了该项目。结果，有十个项目被选中并获得了指导，其中大部分项目预计很快会成为 Boost 的完整贡献。

我们在此给出此次经验的总结报告，并简要分析我们发现的主要问题，以便我们能够努力解决这些问题，并在明年做得更好。

目录

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

项目运作方式

Google 编程之夏中有三种类型的参与者

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

项目分为以下几个阶段

• 组织选择：那些希望参加编程之夏的开源组织向谷歌提交一份意向书，以及谷歌用于资格认定的信息。选定的组织会公开宣布，并且每个组织都应提供一系列项目想法。
• 学生选择：希望参加的学生提交一个或多个项目提案，通常是扩展导师组织先前提供的一些想法。学生可以多次申请并针对不同的组织，但最终只能选择一个项目。这些提案由谷歌路由到相应的组织，组织必须分析它们，对它们进行排名，并为最有希望的申请分配导师。根据导师组织提供的信息，谷歌发布最终接受的项目列表。
• 开发：学生在指定的导师的指导下，预计在三个月内完成项目。谷歌要求导师在项目中期进行审查，以确定项目是否继续进行。
• 最终审查：开发期结束后，导师需要通知谷歌项目的成果，并确定学生是否有资格获得全部津贴。

2006 年数据

2006 年的 Google 编程之夏活动于 4 月 14 日至 9 月 25 日举行。共有 102 个导师组织参加。在全球各地 3,044 名学生提交的 6,338 份申请中，最终有 630 份被选中并获得资助。谷歌已在学生津贴和对导师组织的补偿方面花费了超过 300 万美元。

Boost 的参与

申请和项目选择流程

在 4 月 14 日，也就是 Google 编程之夏开始的同一天，Julio M. Merino Vidal（后来成为被选中的学生之一）发送了一条消息，鼓励 Boost 成员作为导师组织参与该项目。这一号召激发了社区的兴趣；尽管准备工作的时间已经很短，但 Boost 审核员迅速投入工作并进行了初步的注册步骤。与此同时，一个 Wiki 页面正在增长，其中包含了 Boost 成员提供的项目想法，总共超过 20 个提案。

到 5 月初，Boost 正式被该项目接受，Boost 审核员开始组建一个导师团队，这些导师是根据邀请挑选的。由于学生的选择是一个复杂的过程，涉及到对个人的技术技能进行评估，因此所有后续的讨论都由选定的导师在一个为他们的协作而建立的私人邮件列表中进行。

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

• 如果存在针对同一项目想法的竞争性申请，则最终只会选择一个；因此，不会接受两个具有相同或非常相似目标的项目。
• 一些申请是基于给定的 Boost 库构建的（例如，Boost 图形库是添加算法的常见目标）。我们将每个 Boost 库的申请数量限制为最多两个。

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

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

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

已接受的项目

谷歌接受并资助了 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 图形库的扩展，用于处理核外结构，即大到无法一次保存在主内存中的数据集。

MISC（多索引专用容器）
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++ 的前端转换器。

实现最先进的最小割/最大流算法。
Stephan Diederich，由 Douglas Gregor 指导。
基于 Vladimir Kolmogorov 设计的新算法，为 Boost 图形库实现快速的最小割/最大流例程。

开发

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

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

结果

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

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

所有项目的成果都可以在专门的 Trac 网站上查阅。

分析

我们研究 Boost 参与暑期代码的各个阶段，重点是发现改进的机会。

Boost 的吸引力

在 OSCON 2006 的一个中期项目 演示中，谷歌的 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。事实上，谷歌最初要求各组织提交他们认为可以应付的最大项目数量，而我们得到的资助正好是我们想要的目标，因此限制因素完全在 Boost 方面。

项目启动

为 Boost 做出贡献依赖于一套关于编码、文档、测试和维护的相当多的指导方针和协议。许多必需的工具仅在 Boost 中使用，其中一些工具并不简单，例如 Boost.Build。尽管 Boost 网站包含关于所有这些工具和程序的信息，但这些信息分散在不相关的页面中，有时很难找到。

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

持续开发

一旦学生度过启动阶段，大多数项目都会顺利进行。在大多数情况下，在开发过程中的某个时刻，人们意识到没有时间完成它。一些参与者不得不重新定义目标以使项目在计划内完成，而另一些人则直接决定在暑期代码的官方截止日期之后继续工作。

双方通常都认为学生和导师之间的信息交流令人满意。那些缺乏沟通的项目恰恰是那些结果最差的项目。一般来说，导师并没有感到学生的请求不堪重负，甚至在少数情况下，项目实际上是在无人监管的情况下进行的。这一事实证明了被招募到该计划中的学生具有很高的能力。

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

公开沟通问题

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

• Boost 公共列表，尤其是开发人员和用户列表。
• 一个专门的邮件列表，可以联系到在 Boost 中参与暑期代码的所有学生和导师。
• 一个由一名学生建立的更为随意的 Google 群组，旨在为参与者提供一个社交和解决常见问题的场所。

尽管资源丰富，但所有相关方之间以及这些人员与更大的 Boost 社区之间几乎完全缺乏小组沟通。表面上，学生们满足于仅仅依靠导师的支持来开展活动。这种情况阻止了 Boost 成员通过提供他们的经验和见解来丰富这项倡议，并且可能导致学生产生一种错误的印象，即为 Boost 做出贡献是在从需求到工作完成的线性路径中可预测地进行的。当被问及为什么不参与公开交流时，学生们给出了模糊的理由，可以归为以下几类

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

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

项目范围

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

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

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

其中，补充（例如 Stephan Diederich 为 BGL 编写的最大流最小割算法）最适合在短时间内完成：大部分准备工作已经完成，并且学生有明确的指导，说明应遵循哪些编码和文档标准。此外，这些项目不需要进行正式评审，因为由托管库作者负责评审代码并自行决定是否将其包含在内。实用程序项目似乎也适用于较短的时间框架，尽管大多数项目建议和请求自然而然地倾向于对 Boost 项目的实际代码的贡献。

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

改进建议

以下建议旨在缓解我们在 Boost 中暑期代码开发期间发现的一些问题。这些行动要点仅与 Boost 相关的问题有关：我们没有讨论与暑期代码计划本身相关的其他改进领域。

准备

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

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

创建学生池。 预先参与 Boost 项目对于选择阶段以及后期的项目开发都很有优势。那些对参与 Boost 夏季代码项目有浓厚兴趣的学生可以加入学生池，并在夏季之前就开始探索想法，与社区互动，以便在选择中处于有利地位。可以在 2007 年初通过常用渠道（网站和邮件列表）发起学生池的宣传：此外，参与大学合作的 Boost 成员可以在当地传播这些信息，并帮助提高其所在环境中学生的兴趣。

创建导师池。 鉴于 Boost 参与 2006 年夏季代码活动的仓促，导师的邀请不得不以按需方式进行，因为很明显任务变得越来越大。组织必须在明年做好更充分的准备，以便提前确定一些有能力和意愿作为 Boost 导师参与的人员。

准备启动包。 为了方便学生在初期熟悉各种 Boost 指南、协议和工具，准备一份学生启动材料汇编将非常有用。该软件包可以由一个收集当前分散信息的单一文档组成，或者超越此范围，提供一些文档和预构建工具的捆绑包，其中一种方法是目前一名学生正在进行的工作。

公开交流

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

强制（双）周报告。 这些报告应直接发送到公共邮件列表，以便所有 Boost 成员都能跟进工作的进展并做出贡献。报告对于学生来说还有一个额外的好处，那就是迫使他们定期反思自己的工作，并努力完成将自己的想法展示给其他人的这项通常很困难的任务。

学生-导师之间的交流仅通过公共渠道进行。 这可能是一项过于严厉的政策，因为有些事情需要隐私，并且根据交换的信息量，可能会出现泛滥问题。不那么严格的做法是，允许导师酌情进行一些私人交流，并将此类交流转移到与普通邮件列表不同的专用公共邮件列表。

项目管理

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

• 必须控制项目范围，
• 必须公开可见进展情况，以便更容易地检测到范围、设计和/或进度方面的问题。

本节中的一些建议不应被视为严格的规则，而应被视为学生需要牢记并由导师鼓励的一般指导方针。

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

强制进行设计阶段。 在项目早期建立并明确描述具体的设计将有助于评估完成工作所需的必要工作量。这也是公开讨论的机会。

并行维护代码、文档和测试。 初学者程序员常常一口气完成编码，然后才进行测试和记录他们的工作。这不符合所有当前的方法标准，并可能导致严重低估完成所需的时间。

鼓励 KISS 原则。 最好是先完成一个更简单的库，然后在它暴露于公众审查和使用后，逐步迭代地改进它。

更多 Trac 更新。 应将存储库视为日常工作工具，而不仅仅是倾倒最终结果的地方。经常更新可以使导师和公众更清晰地看到工作进展。

非正式评审。 正如之前讨论过的，典型的 Boost 夏季代码项目不会在官方截止日期之前完成。为了以某种方式正式化夏季代码期间完成的工作，并且也让学生达到某种心理里程碑，可以设立非正式评审，由 Boost 成员评估夏季代码结束时完成的工作。

让学生参与进来。 这种经验表明，有可能引导有积极性和聪明才智的学生达到为 Boost 做出贡献所需的胜任能力水平。夏季代码活动的最佳结果是将新人纳入 Boost 活跃贡献者的行列。努力让学生致力于 Boost。

结论

尽管缺乏在 Boost 方面的经验，但我们参与谷歌夏季代码项目取得了丰硕的成果：产生了许多有用的材料，而且，也许更重要的是，一些学生可能会长期致力于此，并成长为 Boost 的常规贡献者。传统上，由于极高的质量标准、缺乏公众支持以及项目非常独特的文化，成为一个高效的 Boost 作者的门槛非常高。夏季代码本身以及在 Boost 世界中被温和指导的可能性很可能是在降低这一门槛方面起到了关键作用。

正如人们对像 Boost 这样的新加入组织所期望的那样，这个过程并非没有一些困难。我们试图在本文中找出需要改进的领域，并提出具体的行动建议，以便即将到来的 2007 年谷歌夏季代码项目能够成为一次更富有收获的体验。

致谢

如果没有 Boost 学生和导师提供的众多报告和贡献，本文就无法撰写：非常感谢所有参与者与我分享他们的经验。还要感谢谷歌的员工，他们促进并开展了夏季代码计划。