OSSへの貢献ノウハウ - Cybozu Inside Out | サイボウズエンジニアのブログ

はじめに

こんにちは、Necoプロジェクトのsatと申します。本記事は世間で何かと重要といわれつつもなぜ重要なのかがわかりにくく、かつ、広くやりかたが知られていないOSSへの貢献ノウハウについて述べます。本記事は筆者が過去にはLinuxカーネル、現在ではRookというOSSへの貢献に業務で取り組んできた経験に基づいて書きました。

ひとくちに貢献といっても様々な方法がありますが、ここではissue発行やPR発行などのOSSの開発へ開発者が直接かかわるような貢献に焦点を絞ります。

本記事の想定読者は次のようなかたがたです。

業務でLinuxやKubernetes,MySQLなどの有名どころのOSSを使っている
バグや機能不足で困っている
OSSへ貢献したことがない
貢献する必要性ががわからない
自分では必要性がわかっているが、会社にうまく伝えられない
貢献したいものの、やりかたがわからない

貢献の利点

OSSに貢献する利点はどのようなものでしょうか。「OSSは使っている限りはなんらかの方法で貢献すべきだ！」というようなことが言われることもありますが、そうはいっても具体的に企業としての利益につながらないとなかなか足を踏み出しにくいのではないでしょうか。そこで、ここでは企業の実利という観点でのOSS貢献の利点について書きます。

OSSを使っていて、まったく問題が起きないというような幸せなケースはまずないと思います。必ずといっていいほどバグや機能不足という問題にぶち当たるでしょう。このようなときにまず思いつくのは「OSSなんだからupstream版*1に自社独自修正をしたものを使えばいいじゃないか！」というアイデアです。実際にこのような方法で問題を解決している例は少なくありません。

ただしこの方法には大きな問題があります。それは時間の経過、もっと具体的にいうとupstreamの安定版リリースごとに大きなコストがかかり、しかもそれが段々増えていくということにあります。最初はupstream安定版に自社独自修正を適用するだけでよいのですが、次の安定版が出たときはどうでしょう。このときは古い安定版に、新しい安定版のうちバグ修正などの必要な修正のみをバックポートして、その上に自社独自修正を適用するという手段をとることが多いようです*2。この手間が安定版のバージョンアップごとに増えていくというわけです。

f:id:cybozuinsideout:20200214175928p:plain

このようなことを避けるためにはupstream版に自社の修正をマージするという方法があります。いったんマージされてしまえば、その後に別の人がPRを発行するときは、みなさんのものを含めた既存のコードが正しく動き続けるように保つ必要があります。もちろんみなさん自身にもregressionが起きないようにコードレビューやテストをするコストはかかりますが、独自修正をし続けるよりはトータルコストが少なくなることが多いです。例えば多くのLinuxディストリビューションは修正をなるべくupstreamに取り込むという"upstream first"という方針を採用しています。

f:id:cybozuinsideout:20200214180040p:plain

上記に述べたもの以外にOSSへの貢献には次のような利点があります。

開発者は貢献したOSSについての知見が得られる。以後の問題発生時の対処が迅速になる
顧客に対して「弊社には製品で使用しているAというOSSに熟達した開発者がいます」とアピールできる
社外開発者に対して「AというOSSの仕事ができる会社」として認識され、採用につながるかもしれない*3

貢献方法

はじめの一歩

OSSに貢献しよう…と決めたものの「やったことないのでわからない、社内にノウハウも無い」というかたはたくさんいるのではないでしょうか。このようなときはお使いのOSSに見つけた些細なバグの報告や修正をお勧めします。ドキュメント追加/修正やテスト追加も歓迎されます。とにかく肩肘張らずに簡単なことから始めるのが望ましいです。

さて、貢献ネタは決まったものの、どういう作法でやればいいかがわかりません。これについては大きめのOSSであればDevelopment.mdやContribution.mdのような「それっぽい」ファイルに貢献方法が書いていることが多いです。ドキュメントを見た後は他のissue/PRなどを見様見真似でご自身のものも発行してみましょう。見様見真似は後々になって難しいissue/PRに挑戦するときも同様です。

issue/PRの発行には、いくつかコツがあります。第一にプロジェクトの中の多くの人が嬉しくなることをアピールしましょう。たとえば単に「このバグが直らないと弊社のシステムが止まるんです！」とみなさんの都合をまくしたてるよりも、コミュニティの中のみんなが遭遇しうる問題だという言い方のほうが反応してもらえる可能性が高いでしょう。

第二に、issue発行だけではなく、なるべく自分でPRも出しましょう。仮に修正や機能追加の必要性が認められたとしても、それを実行する人的リソースには限りがあるのです。

第三に、issue/PR発行時に最初から肯定的な反応を期待しないようにしましょう。否定的な反応をされても、それは注目されているサインだと受け取って、くじけずにしっかりと議論して説得しましょう*4。否定的な反応よりも困るのが無視です。この場合は、そもそも誰の興味もひけていないので、投稿内容を見直して再チャレンジしてみましょう。

自社が遭遇した問題を解決したい

簡単な貢献に慣れてきたら、次は本題ともいえる自社が遭遇したバグや機能不足などの解決をしてみましょう。典型的な解決までの流れは次のようになります。

既存issue/PRの有無を確認。あればそこで「自分も遭遇した」と言ったり追加情報を提供したり、レビューしたりといった貢献をする
無ければ自分でissue/PR発行

PRのマージには数か月、あるいは一年以上かかることもありますし、最悪の場合はマージされないこともあります。このため、常に次のような代替案を考えておきましょう。

回避策を見つける
一時的に自社独自版/開発版を使う
自社独自版を使い続ける(できれば避けたい最後の手段)

たとえば我々は自社インフラで利用するためにRookの開発に取り組んでいますが、現在開発においてはupstreamの安定版ではなく自社独自版を使っています。その理由は、我々の環境で動かすのに必要な機能がまだupstream版にマージされていないためです。この機能は次版にマージされる見通しは立っているために、一時的にという条件付きで自社独自版を使っています。

開発スタイルについて

業務システムでOSSを使う場合は、なるべく開発版ではなく安定したものを使いたいものです。このため、必要なPRがマージされた安定版がいつリリースされるのかの目安を知るのは非常に重要です。このためにはドキュメントや各種コミュニケーションチャネル*5から次のような開発プロセスを確認しておくとよいでしょう。

マージ条件
開発版へのマージ可能時期
安定版のリリースサイクル

参考までにRookは次のようになっています。

メンテナ*6は4人
新機能マージには3人のレビューが必要
安定版のリリース間隔は未定義
- これまでの実績は3~6か月に一回
新機能を安定版にバックポートすることもある

さらにその先へ(参考)

自社向けのバグ修正や機能追加にとどまらずに、さらに先を目指すこともできます。それはプロジェクト全体を盛り上げることです。これだけ書くと「何が嬉しいの？」と思われるでしょうし、実際のところ短期的に目に見える形での効果はわかりにくいです。しかし、長期的に見ると大きな効果が期待できます。

単純化すると、プロジェクトが盛り上がると次のような好循環になることが期待できます。

ユーザが増える
開発リソースが増えてバグ報告/修正、機能追加増加
機能が充実、品質が向上
1に戻る

さらに、このようなコミュニティ全体に向けた貢献をしていると、メンテナを含めたコミュニティに信頼されるようになってissue/PRに反応がもらえる確率が高まりやすい、といった効果もあります。

プロジェクト全体を盛り上げるには例えば次のような方法があります。

自社に直接関係が無いissue/PR発行、レビュー
ユーザサポート
イベントでの発表

貢献時の課題

OSSへの貢献には、これまで述べたもの以外にも、大きな、かつ見過ごされがちな課題があります。ここでは開発者、および開発者を雇用している会社についてのものを紹介します。

開発者の課題

OSSへの貢献はソフトウェアの設計/プログラミングするといった能力(ここでは仮に「技術力」とします)があればできる、というものではありません。技術力が高いのにOSSへの貢献がうまくいかないという例を筆者はたびたび見聞きしてきました。なぜなら、OSSへの貢献には技術力以外にも、以下のような全く別種の能力が必要になるからです。

見知らぬ社外エンジニアに話しかける度胸
それぞれ違う目的でOSS開発に参加している関係者との交渉能力
英語力。あるいは英語が下手でも自分の意思を魂で伝えようとする能力

これらに加えて、主要な開発者、あるいはメンテナともなると日本時間深夜の定例ミーティングに参加したり、海外カンファレンスへの頻繁な参加が必要だったりと、業務負荷がかなり高まるというのも見逃せません。

見かたを変えてみると、OSS開発を長年続けていれば上記のようなことは最初はできなくても時間をかければ自然とできるようになってきます。このような能力を身に着けたいかたには、大変ですが魅力的な業務でしょう。

会社の課題

OSSに貢献したい企業は次のような社内制度の変更が必要になることがあります。

勤怠システム: 前述の変則的な勤務形態が存在しないのなら作る
情報発信ルール: Issue/PR発行、あるいはメール一通ごとに上長の許可が必要…といった制約は辛い
法的ルール: 著作権の帰属、CLAへの署名要否など
- (参考) サイボウズのOSSポリシー

会社および開発者のために、これらはしっかり準備しておきましょう。

社内制度だけではなく、会社組織そのものに考え方の転換が必要です。何よりも大事なのは「OSSの開発は自社の都合では進まない」ということでしょう。これまでに述べてきたような情報を関係者間で共有して、それを前提として問題解決を目指しましょう。そうしないと開発者は会社とOSSコミュニティとの間で板挟みにして苦しむことになります。以下はその「あるあるネタ」です。