Boost 參與 2006 年 Google 暑期程式碼計畫 (Google Summer of Code™) 概述
Google 連續第二年舉辦了暑期程式碼計畫 (Summer of Code™)，這項計畫贊助學生開發者在願意指導參與者的開放原始碼組織中做出貢獻。 2006 年的活動從四月持續到九月，實際開發工作在五月二十三日至八月二十一日之間進行。
大約在四月中旬，計畫剛開始時，一些 Boost 成員開始考慮以指導組織的身分參與暑期程式碼計畫。儘管時間緊迫，而且我們大多數人對這項計畫完全陌生，Boost 還是成功地申請加入了。結果，我們選定了十個專案並進行指導，其中大部分預計很快就會成為 Boost 的正式貢獻。
我們在此提供這項經驗的總結報告，並簡要分析我們發現的主要問題，以便我們能夠著手解決這些問題，並在明年做得更好。
目錄
計畫運作方式
Google 暑期程式碼計畫有三種類型的參與者
- Google 本身作為資金合作夥伴，並負責整個計畫的執行。
- 被計畫接受的開放原始碼組織必須指派組織內的人員擔任專案導師。
- 學生提交他們的專案構想，如果被選中，將與其中一個指導組織合作；專案成功完成後，學生將獲得計畫的全額獎學金。
該計畫會經歷以下幾個階段
- 組織選拔：有意願參與暑期程式碼計畫的開放原始碼組織向 Google 提交一份意向書，以及 Google 用於資格審查的相關資訊。入選的組織會被公開宣布，每個組織都需要提供一些專案構想。
- 學生選拔：有意願參與的學生提交一份或多份專案提案，通常會擴展指導組織先前提供的一些構想。學生可以多次申請，也可以申請不同的組織，但最終只能被選中參與一個專案。這些提案會由 Google 轉發給相關組織，組織必須分析、評比這些提案，並為最有希望的申請者指派導師。根據指導組織提供的資訊，Google 會發布最終的錄取專案名單。
- 開發：學生在其指定導師的指導下，預計在三個月的時間內完成專案。Google會要求導師進行期中審查，專案是否繼續進行取決於審查結果。
- 最終審查：開發期結束後，導師需要告知 Google 專案的結果，並確定學生是否有資格獲得全額獎學金。
2006 年數據
2006 年 Google 暑期程式碼大賽於 4 月 14 日至 9 月 25 日期間舉行。共有 102 個指導組織參與。全球 3,044 名學生提交了 6,338 份申請，最終選出並資助了 630 份。Google 已在學生獎學金和指導組織的報酬上花費了超過 300 萬美元。
提升參與度
申請和甄選流程
4 月 14 日，也就是 Google 暑期程式碼大賽開始的當天，Julio M. Merino Vidal（後來成為獲選學生之一）發送了一封訊息，鼓勵 Boost 成員以指導組織的身分參與這個計畫。此呼籲引起了社群的興趣；儘管準備時間已經很短，Boost 管理員仍然迅速投入工作，並進行了初步的註冊步驟。同時，Boost 成員在 Wiki 頁面上提供了專案構想，總計超過二十個提案。
5 月初，Boost 正式獲准加入該計畫，Boost 管理員開始組建一個由受邀者組成的導師團隊。由於學生甄選是一個需要評估個人技術能力的微妙過程，所有後續的討論都由選定的導師在一個專門為他們協作而建立的私人郵件列表中進行。
我們沒有準備好迎接隨之而來的學生申請潮。申請期開放的第二天，我們收到了三份提案；第二天是 14 份，一周內數量就超過了 50 份。到申請期結束時，我們總共收到了 174 份提案，這迫使我們進行非常密集的排名流程，並招募更多導師。為了使數十個不同提案的甄選過程合理化，我們遵循了兩條規則：
- 如果同一個專案構想有多個競爭申請，最終只會選出一個；因此，不會接受目標相同或非常相似的兩個專案。
- 有些申請是基於特定的 Boost 函式庫（例如，Boost Graph Library 經常成為新增演算法的目標）。我們將每個 Boost 函式庫的申請數量限制為最多兩個。
這些規則的綜合效果是大幅減少了合格申請的數量，同時也讓被接受的專案在構想空間中均勻分佈。此外，擁有獨特提案的學生，也就是專案構想並非來自 Boost 最初提出的構想庫的學生，將具有競爭優勢。
不同的提案會根據其相關的技術領域進行分類，以便每個群組都能由具備相關專業知識的指定導師處理。然後，導師會提交「重點報告」，總結他們負責的申請；這些報告作為第一道篩選機制，有助於減少最終需要共同評估的申請數量。在此過程中，我們會要求最有希望的提案的學生完善他們的構想並提供更多資訊。
雖然官方規則沒有強制規定，但我們同意導師與學生的比例為一比一，這最終決定了合格專案數量的上限。
已接受的專案
Google 接受並資助了 Boost 認可的十個排名最高的專案。其中八個專案是函式庫或函式庫組件，目標是未來納入 Boost，而其餘兩個則是由高度依賴 Boost 的工具程式組成。
C++ 協程函式庫 (C++ Coroutine Library)
Giovanni Piero Deretta，指導者：Eric Niebler
透過現代 C++ 介面管理作業系統提供的協程功能的函式庫。
並行函式庫 (Concurrency Library)
Matthew Calabrese，指導者：David Abrahams
受 STL 啟發的通用框架，用於高階指定和執行可平行化演算法。
TR1 數學特殊函數 (TR1 Math Special Functions)
張曉剛，指導者：John Maddock
實作 C++ 標準函式庫擴展提案 TR1 中指定的 23 個特殊數學函數。
Boost.Process 函式庫 (The Boost.Process library)
Julio M. Merino Vidal，指導者：Jeff Garland
用於程式啟動和基本管理的可移植函式庫。
核心外圖形和圖形演算法 (Out-of-Core Graphs and Graph Algorithms)
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 的特製容器系列。
通用樹狀容器 (Generic Tree Container)
Bernhard Reiter，指導者：René Rivera
設計和實作一系列與 STL 相容的樹狀容器。
FSM 的檢視器工具程式 (Viewer utility for FSMs)
Ioana Tibuleac，指導者：Andreas Huber Dönni
用於視覺化使用 Boost.Statechart 指定的有限狀態機 (FSM) 的工具程式。
使用 Boost.Spirit 的模組化 C++ 預處理器 (Modular C++ preprocessor, using Boost.Spirit)
Hermanpreet 'Lally' Singh，指導者：Joel de Guzman
使用 Boost.Spirit 和 Boost.Wave 實作一個前端翻譯器，將模組化 C++（根據 Daveed Vandevoorde 提出的將模組添加到 C++ 的提案中指定）翻譯成標準 C++。
實作最先進的最小割/最大流演算法 (Implementing a state of the art Mincut/Maxflow algorithm)
Stephan Diederich，指導者：Douglas Gregor
基於 Vladimir Kolmogorov 設計的新演算法，為 Boost Graph Library 實作一個快速的最小割/最大流例程。
開發 (Development)
建立了兩個主要設施來協助學生和指導者在開發階段：一個郵件清單和一個 Trac/SVN 專案管理系統，每個專案都有單獨的目錄。其中一名學生 Matías Capeletto 主動註冊了一個 Google 群組，旨在為使用 Boost 的學生提供一個非正式互動和討論共同問題的場所。
在最初的暖身期之後，每個學生-指導者對大多私下進行開發工作。Boost 郵件清單的使用很少，直到程式結束時，才有一些學生公開宣布了他們的成果。
成果 (Results)
截至開發期正式結束之日，不同專案的狀態如下：
- 七個專案已完成或接近完成，預計學生將在 2006 年或 2007 年初提出正式審查。其中四個專案在開發過程中需要重新調整目標，主要原因是最初的計畫對於三個月的時間來說過於 ambitious。大多數專案在暑期程式碼計畫之後的幾個月仍在積極開發中。
- 兩個專案未能達到預定的目標，但仍然產出了有用的素材，可以在暑期程式碼計畫之外繼續擴展。
- 一個專案在期中審查後不久就被放棄了。放棄的原因不明。
所有專案的成果都可以在線上查閱，網址是 Trac 網站。
分析
我們將檢視 Boost 參與暑期程式碼計畫的各個階段，重點在於發掘改進的機會。
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）的困難。每個學生都靠自己或求助於他們的導師來克服啟動困難（請參閱關於公開溝通問題的部分）。
持續開發
一旦學生度過初始階段，大多數專案都能順利推進，沒有遇到嚴重的阻礙。然而，在開發過程中，大部分的專案都意識到時間不足以完成預期目標。有些參與者必須重新定義目標以維持專案進度，而其他人則決定在暑期程式碼計畫的官方截止日期後繼續投入。
學生和導師之間的資訊交流通常雙方都表示滿意。缺乏溝通的專案恰好是成果最不理想的。一般來說，導師並沒有感到學生提出的要求過於繁重，甚至有幾個專案幾乎是在無人監督的情況下運作的。這也證明了參與計畫的學生的高能力。
Trac/SVN 系統的使用程度不一。有些學生頻繁更新，而有些學生僅將程式庫用於提交最終成果給 Google。
公開溝通問題
學生和導師可以使用三個不同的論壇來公開交流資訊和尋求支援：
- Boost 公開郵件列表，尤其是開發者和使用者列表。
- 一個專門的郵件列表，涵蓋所有參與 Boost 暑期程式碼計畫的學生和導師。
- 一個由其中一位學生建立的較為輕鬆的 Google 群組，旨在為參與者提供一個社交和解決共同問題的平台。
儘管資源豐富，但所有參與者之間，以及他們與更廣泛的 Boost 社群之間，幾乎完全缺乏群組溝通。學生們似乎滿足於僅依靠導師的支援來進行他們的活動。這種情況阻礙了 Boost 成員透過提供經驗和見解來豐富這項計畫，並可能導致學生誤以為貢獻 Boost 的過程是從需求到完成工作的可預測線性路徑。當被問及為何不參與公開溝通時，學生們給出了模糊的理由，大致可歸納為以下幾點：
- 認為疑問過於技術性或特定，不值得公開提出。
- 追求完美主義，使得學生在覺得自己的成果夠好之前，不願意提問或提交正在進行中的工作。
- 害羞：有些學生可能缺乏公開溝通的經驗，而且大多數學生的母語都不是英語，這也可能是一個限制因素。
雖然學生沒有將以下因素列為不公開的原因，但很可能許多學生認為，由於可以隨時聯繫到他們的導師，因此沒有必要公開討論。人們很容易習慣這種專屬的支援來源，而忽略了其他資源。導師應該鼓勵學生公開討論專案，這是 Boost 著名的品質支柱之一。
專案範圍
事後看來，很明顯大多數專案的目標過於雄心勃勃，以至於無法在三個月的計畫期間內完成，即使是被認為成功的專案也需要數週或數月的時間進行完善，才能正式審核。與其他參與暑期程式碼計畫的組織不同，截至撰寫本文時，Boost 尚未將任何成果納入其程式碼庫。目前也沒有任何專案被要求進行正式審核。
這些範圍問題與特定專案類型密切相關。我們可以將 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 原則 (Keep It Simple, Stupid)。 先完成一個較簡單的程式庫，然後在經過公開審查和使用後再逐步發展，這樣會更好。
更頻繁地更新 Trac。 程式碼庫應該被視為日常工作工具，而不僅僅是存放最終結果的地方。經常更新可以讓導師和一般大眾更容易掌握專案進度。
非正式審查。如同先前討論，一般的「程式碼之夏」Boost 項目並不會在官方截止日期前完成。為了某種程度上正式化在「程式碼之夏」期間完成的工作，也為了讓學生達到某種心理里程碑，可以建立非正式審查制度，讓 Boost 成員在「程式碼之夏」結束時評估已完成的工作。
讓學生參與。這項經驗顯示，引導有意願且聰明的學生達到貢獻 Boost 所需的能力水平是可行的。「程式碼之夏」活動最好的結果是將新人納入 Boost 活躍貢獻者的圈子。努力讓學生們投入 Boost。
結論
儘管先前缺乏 Boost 的經驗，我們參與 Google 程式碼之夏的成果依然非常豐碩：產生了許多有用的素材，而且，或許更重要的是，一些學生可能會長期投入並成長為 Boost 的常規貢獻者。傳統上，成為一位多產的 Boost 作者有著很高的門檻，因為其極高的品質標準、缺乏公開支援以及專案非常特殊的文化。「程式碼之夏」本身的吸引力以及在指導下溫和地進入 Boost 世界的可能性，很可能是降低這個門檻的關鍵因素。
如同Boost 作為一個新手組織的預期，這個過程並非沒有遇到一些困難。我們試圖在本文中找出需要改進的地方，並提出具體的行動建議，讓即將到來的 2007 年 Google 程式碼之夏能成為更有價值的經驗。
致謝
沒有 Boost 學生和導師們熱心提供的眾多報告和貢獻，這篇文章是不可能完成的：非常感謝所有參與者與我分享他們的經驗。也感謝 Google 推廣和執行「程式碼之夏」活動的人員。
