この投稿はFujitsu extended Advent Calendar 2016の11日目の記事です。
はじめに
知り合いの@tnaotoさんがFujitsu Advent Calendarを作ったとFacebookで流れてきたのを見て、参加しようと思っていたのですが、すぐには埋まらないと油断していたら気が付いたときには全て埋まってしまっていたので2枚目の空いているところにエントリーしました。
今回は仕事で何をしているかを紹介したいと思います。
なんで仕事のことが書けるの？
普通の会社では、仕事の話は社外秘なのでAdvent Calendarの様なパブリックな場に書くことはできませんが、私の仕事はフルタイムでオープンソースの開発をしているので、社内向けの仕事以外の多くの仕事は既にパブリックに観測可能なものです。そのため、Advent Calendarに書いてしまっても問題ないという話です。
オープンソースの仕事をしていると、他の人と話すときに自分のやっていることをほぼ全て話すことができるのが精神衛生上良いのがメリットかなと常々感じています。
どんなプロジェクト？
Open Network Operating System (略称: ONOS)というプロジェクトにパートナー企業1からのフルタイムエンジニアという形で参加しています。ONOSは、オープンソースのSDN(Software Defined Networking)コントローラを開発するプロジェクトで、ON.Lab (Open Networking Lab)というNPOが開発を主導しています。ONOSの特徴は、SDNコントローラで課題となるスケーラビリティと耐障害性を解決することを最初から念頭に置いて開発されていることです。2014年4月から現在の形態で開発が行われており、2014年12月にオープンソース化されました(Github, Gerrit)。
オープンソースのSDNコントローラという意味では、OpenDaylightが競合のプロジェクトになりますが、現在、両方のプロジェクトがLinux Foundation傘下のプロジェクトになっています。2
どういう仕事をしているのか？
富士通は2014年4月の最初からパートナー企業としてプロジェクトに参加しており、私はパートナーに割り当てられた2名のフルタイムエンジニアの一人としてフルタイムでONOSのコア部分の開発を行っています。2014年10月からアメリカ（シリコンバレー）に赴任となり現在に至っています。普段はON.LabのオフィスでON.Labで雇用されたエンジニアおよび私のようなパートナー企業から派遣されているエンジニアと同じオフィスで働いています。
開発を担当している具体的な部分は、Northbound APIと呼ばれるSDNコントローラ上で動くアプリケーションが使用するAPIの中でもIntent Frameworkと呼ばれる抽象度の高いAPIを担当しています。Intent Frameworkは、ネットワークの細かい知識がなくともアプリケーション開発者が簡単にコネクティビティを設定することが出来るだけでなく、ネットワークの細かい知識を持った開発者には細かい制御ができるように拡張性を持ったAPIです。Intent Frameworkの基本的なデザイン/コンセプトの決定から開発までを行っています。
また、Intent Frameworkの開発から派生して、ネットワーク上に存在する様々なリソースを統一的に予約/管理するためのResource Serviceの開発を昨年からメインで担当しています。これらのコンポーネントについてのモジュールオーナーなので、自分のコードを書くだけではなく、様々なコントリビュータから来るパッチのレビューもしています。
大変なこと
オープンソースで最も重要なものはコミュニティだと私は思っていますが、コミュニティの運営は得てして簡単ではありません。もしかすると、企業の運営よりも様々な人がいるという意味ではある意味難しいかも知れません。私は、コミュニティマネージャではないのでコミュニティの運営方針について直接の責任を持っていませんが、コミュニティに参加している一人としてコミュニティの活性化/成長に関して難しさを感じることがあります。
例えば、外部コントリビュータからパッチが送られてきて自分がレビューすることになったとしましょう。そのパッチに修正が多く必要そうに見える場合、1) 修正が必要な全ての点についてコメントを付け修正してもらうまでマージしない、 2) リグレッションを引き起こすなど重大な欠陥がなければ、コメントを付けるのはほどほどにマージしてしまう というような方針が考えられます。
1)の場合、折角プロジェクトに参加してくれようとしているコントリビュータが嫌になってしまう可能性がある、また、レビューに多くの時間をとられることで自分のコードを書く時間が減ってしまいます。前者の要素は、将来的なコミュニティの参加者を減らしてしまう要素かもしれませんし、後者の要素は、開発のスピードを遅くさせ、将来的にプロジェクトに興味を持ってくれる人を減らす要因になってしまうかも知れません。
2)の場合、参加のハードルが下がることによってコミュニティへ気軽に参加できコミュニティの成長にプラスの面があるかも知れませんが、一方で、技術負債を増加させる要因となり将来的にプロジェクトを停滞させエンジニアを引きつけられなくなる要因となるかも知れません。
このように、レビューひとつとってもよく考えるとコミュニティ成長に対してのトレードオフが存在しています。コミュニティをどのように成長させていうのに絶対的な解は存在しないことを感じています。プロジェクトが異なれば、正解となる方法も異なり、また、同じプロジェクトであってもそのフェーズによって正解となる方法は異なるでしょう。
おわりに
仕事でオープンソースの開発をするのは、自分のやったことが社外からも見える、仕事の内容を話しやすいなど様々ないい面がありますが、一方でオープンソース特有の難しさもあります。プロジェクトそのものに興味を持ってくれた方、オープンソースの話に興味を持ってくれた方、お気軽にご連絡下さい。
Twitter: @oshothebig