オープンソースプロジェクト（その２）
企業が主導するオープンソースは、無償のオープンソースだけでは当然ペイしない。有償のクローズド部分があるか、サポートサービスで稼ぐ。オープン部分は技術者のリクルートであり、サポート要員の育成用であると考えれば、前述の８名枠など軽く埋まるはず。
オープンソースには、概要レベルのプレゼン資料はあっても、プログラムの詳細設計書はない。機能追加が頻繁だから、メンテできていないのかもしれないが、リクルート用だと考えれば納得できる。ソースを読んで理解できた者が正規雇用される関門なのだ。某社のチーフアーキテクトは、学生時代、その製品のファンで、ベーター版にバグレポートを送り続け、採用され、米国に移住したそうだ。オープンソースは今やグローバルな技術者のコンペだ。プログラミングの能力だけでなく、なにより英語力が必須となる。
Eclipseでは、ソースの修正ルールも厳しい。正しく動くことはもちろん、性能やメモリ量もチェックされる。さらに著作権問題がないか、レビューする専門委員がいる。すべての承認を得て、はじめて公開できる。クローズド部分のルールと大差ないと思われる。そういう意味でも、オープンソースが新人の選別であり、訓練になっている。入社してからOff JTやOJTで研修する期間は半年から１年にもなる。オープンソースで活躍した新人なら、OJTを済ませたのと同じである。
昔のソフトウェア開発の教科書は、上流工程で設計書をしっかり仕上げることを重視してきた。オープンソースでは「公開を最優先する」と、あるオープンソースプロジェクトのリーダが話していた。動くものを公開することで、広くレビューしてもらう。テストしてもらう。普通ならプロジェクト内でやっている作業をオープンにする。リーダは担当に公開を促す。公開すれば世界が見ているのだから厳しい。
Eclipseでは、次期リリース向けの「とりあえず版」（毎晩）と「安定版」（ほぼ週単位）が公開されている。これはクローズド開発と同期をとっている。オープンソース開発は、クローズド開発の一部が露出しているので、好き勝手に新しい機能を追加しているわけではない。開発計画書も品質評価結果もある、立派なプロジェクトである。
