Boost 在 Google Summer of Code™ 2006 中的参与概述

连续第二年，谷歌举办了其 Summer of Code™ 计划，该计划为学生开发者提供赞助，以鼓励他们为愿意指导参与者的开源组织做出贡献。2006 年的活动在 4 月至 9 月之间举行，活跃的开发工作从 5 月 23 日持续到 8 月 21 日。

大约在 4 月中旬，当该计划刚刚开始时，一些 Boost 成员开始考虑以指导组织的身份加入 Summer of Code。尽管时间紧迫，而且我们大多数人对这项计划完全陌生，但 Boost 还是成功地申请了该计划。结果，十个项目被选中并得到了指导，其中大部分项目预计将很快成为 Boost 的完整贡献。

我们在此提供本次体验的总结报告，并对我们遇到的主要问题进行简要分析，以便我们努力解决这些问题，并在明年做得更好。

计划运作方式

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

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

该计划经历以下阶段

组织选择：愿意加入 Summer of Code 的开源组织向谷歌提交一份意向书，以及谷歌用于资格审查目的的信息。选定的组织将被公开公布，每个组织都应提供一组项目想法。
学生选择：愿意参与的学生提交一个或多个项目提案，通常扩展指导组织先前提供的一些想法。学生可以多次申请，并针对不同的组织，但最终只能为一个项目被选中。这些提案由谷歌转发给相应的组织，组织必须对其进行分析、排序，并为最有希望的申请分配导师。根据指导组织提供的信息，谷歌发布最终接受的项目清单。
开发：学生在指定导师的指导下，预计将在三个月的时间内完成项目。谷歌要求导师在计划中期进行评估，项目是否继续取决于评估结果。
最终评估：开发期结束后，要求导师通知谷歌项目的成果，并确定学生是否有资格获得全部津贴。

2006 年数据

Google Summer of Code 2006 年的活动在 4 月 14 日至 9 月 25 日之间举行。共有 102 个指导组织参与。在全球 3,044 名学生提交的 6,338 份申请中，最终有 630 份被选中并获得资助。谷歌在学生津贴和指导组织补偿方面投入了超过 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 图库是添加算法的常见目标）。我们将每个 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（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++ 的前端翻译器。

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

开发

为了在开发阶段为学生和导师提供帮助，设置了两个主要设施：一个邮件列表和一个 Trac/SVN 项目管理系统，每个项目都有单独的目录。其中一名学生 Matí as Capeletto 自发地注册了一个谷歌小组，旨在为 Boost 的学生提供一个非正式互动和讨论常见问题的地方。

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

结果

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

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

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

分析

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

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。碰巧的是，Google 最初要求组织提交他们认为自己能够应对的最大项目数量，而我们获得了与我们目标完全一致的资金，因此限制因素完全在于 Boost 一方。

项目启动

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

因此，开始在 Boost 工作需要相当多的专业知识。一些学生报告了在了解这些细节和熟悉工具（最著名的是 bjam 和 Quickbook）方面的启动困难。每个学生都克服了他们自己的启动困难，或者求助于他们的导师（见关于公共沟通问题的部分）。

持续开发

一旦学生克服了启动阶段，大多数项目都在没有严重并发症的情况下取得进展。在大多数情况下，在开发过程中，人们意识到没有时间完成它。一些参与者不得不重新定义目标，以使项目保持在进度内，而另一些人则简单地决定在 Google 暑期代码项目的官方截止日期后继续工作。

每位学生与其导师之间信息流通常被双方报告为令人满意。缺乏沟通的项目恰好是那些取得最差结果的项目。总的来说，导师并没有感到被学生的要求所淹没，甚至在少数情况下，项目实际上是无人看管的。这一事实证明了招募到该项目的学生的超高能力。

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

公共沟通问题

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

Boost 公共列表，尤其是开发者和用户列表。
一个专门的邮件列表，覆盖所有在 Boost 中参加 Google 暑期代码项目的学生和导师。
一个更休闲的 Google 网上论坛，由一名学生建立，旨在为参与者提供一个社交和解决常见问题的场所。

尽管拥有如此丰富的资源，但所有相关方之间以及他们与更大的 Boost 社区之间的群体沟通几乎完全缺乏。似乎学生们满足于依靠导师的支持来进行活动。这种情况阻止了 Boost 成员通过提供他们的经验和见解来丰富该计划，并且可能导致学生错误地认为对 Boost 的贡献是按预定的线性路径从要求到工作完成的。当被问及他们为什么不参与公共沟通时，学生们给出了模棱两可的理由，可以归类如下

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

虽然学生们没有将以下因素列为不公开的理由，但很可能，他们中的许多人并没有因为他们享受到的导师的随时帮助而感到需要公开。很容易习惯这种专用的支持来源，而忽略了其他资源。导师应该鼓励他们的学生公开讨论项目，因为这构成了 Boost 著名的质量支柱之一。

项目范围

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

这些范围问题与项目的特定类型密切相关。我们可以将 Google 暑期代码项目的 Boost 项目归类如下

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

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

对于那些涉及设计和实现完整库的项目，几乎没有希望目标和范围能够保持足够小，以适合三个月的计划。由专业作者开发的 Boost 候选库通常需要比三个月长得多的时间才能被接受；一些库经过几年的发展才被包含在 Boost 中。因此，如果我们要在 Google 暑期代码项目中支持为 Boost 实现库项目，我们所能期待的最好结果是，在项目结束时，结果可以被评估为对 Boost 的可行潜在贡献。在这种情况下，至关重要的是学生承诺进一步完成项目，直到完成并进行正式评审。也许比编写库代码更重要的是让新的作者与 Boost 项目建立长期关系。

改进建议

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

准备

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

创建项目创意库。此操作将在 Google 暑期代码项目开始之前提供宝贵的时间来评估和完善创意。经验表明，那些在设计方面投入更多准备工作的项目最终会更加成功。该库还可以用来保留在邮件列表中出现但经常没有得到适当关注而被放弃的有趣想法。

创建学生库。事先参与 Boost 对于在选择阶段以及之后在项目开发期间都是一项优势。那些对参加 Boost 的 Google 暑期代码项目有浓厚兴趣的学生可以加入该库，并开始在夏季之前很久就探索想法并与社区互动，使他们处于有利地位以供选择。学生库的广告可以在 2007 年初通过通常的渠道（网站和邮件列表）启动：此外，参与大学的 Boost 成员可以在当地传播这些信息，并帮助提高学生对他们所在环境的兴趣。

创建导师库。鉴于 Boost 匆忙参加了 2006 年的 Google 暑期代码项目活动，导师的邀请必须按需进行，因为越来越明显的是，任务越来越大。该组织必须在明年做好更好的准备，以便提前确定有能力和意愿参与 Boost 导师的人员。

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

公共沟通

学生们必须尽早参与到社区中，并开始了解公共开发与单独编码的优势。

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

通过公共渠道进行学生与导师之间的交流。这可能是一个过于激烈的政策，因为一些事项需要私密性，并且根据交流信息的多少，可能会出现泛滥问题。不太严厉的变化包括允许导师自行决定进行一些私下交流，并将此类交流转移到与通用邮件列表不同的专用公共邮件列表中。

项目管理

在管理方面需要改进的两个最重要的问题是

项目范围必须得到控制，
进度必须公开可见，以便更容易地发现范围、设计和/或进度方面的问题。

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

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

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

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

鼓励 KISS 原则。 最好先完成一个更简单的库，然后在它被公开审查和使用后迭代地进行演化。

更多 Trac 更新。 仓库应该被视为日常工作工具，而不仅仅是用于存放最终结果的地方。经常更新可以使导师和公众更容易了解工作进度。

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

吸引学生。 这段经历表明，可以指导有能力和聪明的学生达到为 Boost 做出贡献所需的水平。Google Summer of Code 活动的最佳结果是将新人纳入 Boost 积极贡献者的圈子。努力使学生致力于 Boost。

结论

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

这个过程也并非没有困难，正如预期的那样，对于 Boost 这样的新手组织来说。我们试图在这篇论文中确定需要改进的领域，并提出具体的行动建议，以便即将到来的 2007 年 Google Summer of Code 能够带来更加丰厚的回报。

致谢

没有 Boost 学生和导师提供的众多报告和贡献，这篇论文不可能写成：非常感谢所有参与者与我分享他们的经验。感谢 Google 的人员推广并开展了 Google Summer of Code 计划。

Boost C++ 库