.png&w=3840&q=75)
本記事では、「OSS応援企画」として記事の最後に「応援ボタン」を設置しています。1回の応援につき、Findyが100円をOSS団体などへ寄付し、エンジニアの成長とOSSの発展を応援する取り組みです。開発者の想いや取り組みに共感した気持ちが、OSSの支援にもつながっていく、そんな前向きな循環をFindyは目指しています。「応援ボタン」は、1日1回まで押すことができます。記事を読んで「いいな」と感じたら、ぜひボタンを押してあなたの応援の気持ちを届けてください。
Songmuと申します。現在はとある外資のテック企業でシニアソリューションエンジニアとして働いています。最近はOSS作家を自称しており、OSSのつくり手として実用的じゃない物も含めてGitHubで200を超えるOSSを公開・メンテナンスしています。
自分がオリジナル作者ではないOSSの開発や長期メンテナンスにも携わっており、代表的なものとしてはx-motemen/ghqやk1LoW/deckが挙げられます。それらはGitHub starが1000を超えるOSSになっています。
私自身がつくりはじめたOSSには1000スターを超えるような人気OSSはありません。100スターを超えるものはいくつかあり、tagprなどはソフトウェアのリリースのためのニッチな用途のソフトウェアですが、国内外のOSS開発者やテック企業の中でそれなりに使っていただいています。
また、業務で利用しているOSSにも必要に応じてpull requestを送り、これまで100を超える外部リポジトリにpull requestを取り込んでもらいました。
そのような、気楽な中堅OSS開発者として10年以上活動しています。
OSSへの憧れと馴れ初め
私がOSS開発に興味を持ちはじめた発端としては、2000年代のインターネット普及期のブログブームのように、何でもオープンにするのが当然で、それがかっこいいという雰囲気だったり、GitHubの登場によってソースコードを公開しやすくなったこと等による影響があるでしょう。
当時のWeb開発で良く使われていたPerlでは、自作のモジュールを中央リポジトリであるCPANに公開することは１つのステータスでした。miyagawaさんに代表されるように"CPAN Author"になるというのがPerl界隈のエンジニアの1つの目標だったのです。
実際私もその頃からインターネットの片隅でブログを書いていましたし、CPANに初めてモジュールを公開できた時はとても興奮したことを覚えています。ただ、その頃は、OSSハッカー達に憧れを持ちながら真似事をしていたくらいのものでした。
Our Free Software Runs Your Company
2011年に入社したカヤック社では、自分たちが開発しているライブラリをOSSとして公開することや、業務で活用しているOSSに積極的に貢献することが当然の風土がありました。この頃から私も本格的にOSS開発者として活動することになります。
折しも、miyagawaさんが手動したPerlのWebアプリケーションの標準インターフェース策定・実装プロジェクトであるPlackの開発や普及が進んでいた時期でした。Plackはまだバージョン1.0になっておらず不完全な部分もありましたが、それでもその優位性から多くのサービスのプロダクションで利用が進んでいました。その為、Plackに足りていない実装や周辺OSSを自分達含めたコミュニティ開発しながら、それぞれが自社のサービスで活用していたのです。Plackはコアコンセプトがシンプルであり、周辺エコシステムの開発に貢献しやすい優れた設計になっていたこともそのムーブメントを牽引しました。
つまり、OSSはスゴイ人がつくった物を使わせてもらうものと言う感覚ではなく、OSS開発と自分たちの製品開発が地続きだったのです。この辺り、各社のエンジニアが合理性を持ってOSSエコシステム構築に協力していた様子は、もうひとつの知られざるオープンソース 〜 ウェブ企業のOSS戦略というブログ記事に詳しく書かれています。
当時、PerlのWebアプリケーション開発に係わるOSSの多くは日本人開発者によって主導されていました。そのようなエコシステムの中に私も身を置いてOSS開発に関わることができたのは幸運でした。最初は分からないことだらけでしたが、その中での振る舞い方などはコミュニティの先輩開発者の方々が温かく示してくれました。特にtokuhiromさんにはお世話になりました。運の要素もありますが、私としてはOSS開発というものは決して高尚な物ではなく、それくらい多くの人が参加できる敷居の低いものだと伝えていきたいです。オーナーシップを共有しながら、自分たちや周りの人に使いやすいように改善できることがOSSの醍醐味です。
昔のCPANには "cpan faces"というページがありました。CPAN Authorのアイコンが並んでいるだけの簡素なページでしたが、その一番上に "Our Free Software Runs Your Company" というキャッチコピーがありました。この言葉はOSSのカッコ良さを表す言葉として今でも私の心に残っています。
当時のスクリーンショット
私がつくっているOSSは今でも小さなネジのような小粒な物ばかりですが、それでもどこかの企業で利用されて、微力ながら貢献しているということには喜びを覚えます。「OSSが世界を良くする」などと語られることもあり、大げさで意識が高過ぎる言葉に聞こえるかもしれませんが、本当にそういう小さな小さな積み重ねが世界を良くしているのだと私は捉えています。
You have a commit bit!
私がつくりはじめたOSSがすぐに広く使われることはありませんでしたが、その代わり、実績のあるOSSをいくつか引き継いでメンテナンスさせてもらう機会に恵まれました。OSSにバグ修正や機能追加のpull requestをいくつか送っていると「もうあなたが直接変更してリリースして良いよ」とリポジトリのコラボレーション権限を付けてもらえることがしばしば発生したのです。
ソフトウェアに不具合は付き物でOSSも例外ではありません。それは、些細な不具合だったり、作者のユースケースでは不要ではあるため実装が後回しにされていた機能、使っている人がいなかったため動かないことが見過ごされていた機能、依存ライブラリなどの外部要因の変化によりいつの間にか動かなくなっていた機能など様々です。
ただ、利用しているOSSに問題がありそうだと思った場合であっても、9割方は自分の実装側に問題があったりするものです。OSSに不具合があると軽々しく判断せず、慎重に検証した上で問題報告をしましょう。それと同時に、見つけた不具合は自分たちの環境でその場凌ぎの対応に留めるのではなく、ちゃんと報告をしてOSSエコシステムに還元するのが望ましいです。
不具合に限らずOSSには様々な改善余地があります。それらは「ちゃんと使っているから」こそ見つけられるものです。私が各種OSSのメンテナンスを引き継がせてもらえたのは、それらを実際に利用していたからでしょう。作者からすると、既に使っていなかったり、メンテナンスが負担になっている場合、ちゃんと使っている信頼できる人に渡した方が有効活用してもらえるだろうと考えてメンテナンス権を譲るのは自然な流れです。
"You have a commit bit!" という言葉がしばしば使われました。「あなたはコミット権限を持っている（付与した）」ので、後は好きにして良いよ、という意味合いです。コミット権という言葉はSubversionなどの集中型バージョン管理システムの名残りでしょう。集中型の場合にコミット権はすなわち中央リポジトリの変更権限をそのまま指すからです。
当時の開発者同士のコミュニケーションはIRCが多かった為、インターネット上にその会話の様子はあまり残っていませんが、私の手元に残してあるログを軽くgrepすると以下のような会話の様子が見つかり、気軽にメンテナンス権を渡し合っていた様子が窺えます。
メンテナンスを引き継ぎ、リポジトリの管理を任せてもらえれば後は自由です。自分の好きにして良いものなので自己効力感を感じます。それと同時に、既存の利用者に引き続き便利に利用してもらうために、自分で何とかしないといけないし、何とかしたいという責任感も自然と湧いてきます。そのようなオーナーシップが醸成されるのです。
メンテナンスを引き継ぐことで、自分とは異なる色々な流儀を知ることができるのもメリットです。コーディングスタイルや、ライブラリ・ツールチェイン選定、CI／CDのサービス構成など、新しい発見が得られます。それらを無理に自分の色に塗り替えるのではなく、過去の経緯を尊重しながらメンテナンスすることで自分が使ってこなかった技術から生きた学びも得られます。
OSSを引き継いでいたら、CTOも引き継いでいた
引き継いでもらったとしてもOSSは自分の小さなプロダクトです。そのソフトウェアがどういったプロダクトなのか改めて理解と解釈を試みること、その上で定義の策定が必要になることもあります。利用者や貢献者の意見を取りまとめ、指針を示すことが求められることもあります。もちろん、メンテナンスを任せてくれた人や利用者の信頼に応えたい気持ちも根幹にあります。
これはまさしくプロダクトマネジメントです。私はこれらの経験を通して、ソフトウェアはつくって終わりではないこと、継続運営することの価値や、信頼を繋ぐことの尊さを学びました。そして、自分がそのような継続的な活動が好きであり、強みであることにも気付けたのです。
そんな経験もあってか、仕事でもMackerelというクラウド監視SaaSのプロダクトマネージャーを引き継いだり、Nature社のCTOを引き継ぐなどの機会がありましたが、それらを前向きに引き受けることができました。
Mackerelはエンジニア向けのプロダクトであり、業務上も関連OSSを自分たちで開発してメンテナンスしていた点も私にフィットしていました。プラグインシステムのエコシステム構築やそのマネジメントなどは特にOSS経験が活きた部分でしょう。
NatureのCTOはカヤック時代の同僚であったtypesterさんから引き継ぎました。彼の海外移住に伴い後任を探している中で私を思いだしてくれたのです。尊敬するOSSハッカーから「CTOを引き継いでくれないか」と言われた時は、驚き、感激しました。OSSを引き継いだこともある彼からCTOも引き継いだのは面白い経験でした。
Just for Fun
そんなtypesterさんの発表にPerlハッカーは息をするようにCPANモジュールを書くというものがあります。この資料にもありますが、OSSは当人の必要に応じてつくられるケースが多々あり、インストールや管理が楽で自分が利用しやすいからOSSとして公開しているだけのソフトウェアがたくさんあるのです。寧ろ最初はそれが大半なのではないかという肌感覚もあります。
Linuxの生みの親であるLinus Torvalds氏の有名な書籍に "Just for Fun" （邦題: それがぼくには楽しかったから）というタイトルがあるようにメジャーなOSSであっても、そのような個人の楽しみから始まることも多いのです。また、PHPの生みの親であるRasmus Lerdorf氏の「PHPは歯ブラシ程度の日常の取るに足らない道具に過ぎない」という発言も有名です。
私の最近の活動も、例えばプレゼンテーション作成ツールであるk1LoW/deckは自分の資料作成の為にコントリビュートを始めたに過ぎません。また、個人ポッドキャスト配信の為に PodbardやChapeといったOSSを新たに開発して利用しはじめました。私のブログもRijiという自作のOSSブログエンジンで10年以上運営しています。このように私の身の回りの数名しか使っていなかったり、私自身しか使っていないようなOSSもたくさんありますが、それでもそれらは私の日常生活を支えてくれているものです。
OSS開発は別に特別なものではありません。実は仕事の開発よりもハードルは低く、誰でも始められる物なのです。個人的な酔狂や課題感から始まる物で良いし、多くの場合そうじゃないと始まりません。OSSとはそういうボランタリーな活動です。無償であることよりも自発的で自由な活動であることが本質なのです。
OSS開発者が皆の為に無償で汗を流してくれている聖人君子のようにとらえられてしまうこともありますが、そういう過度な期待と幻想がOSS開発者を苦しめる事もあるように感じます。
もちろん、世界中の多くの人の生活を支えている重要なOSSもあります。開発者がそこに使命感を感じてモチベーションにして開発している場合もあるでしょう。それはとても尊いですが、それもあくまで開発者個人がそうしたいというボランタリー意識で成り立っていることを忘れてはいけません。利用者はあくまでお裾分けに預かっているだけですし、開発者達のモチベーションを損ねるような責任追及は誰の為にもなりません。
OSSは誰でも自由に気軽に始められ、気楽に続けられる活動です。だからこそすそ野が広がり、その中から多くの有用なOSSが生まれてきたのです。
OSSは使っていることを公言するだけでも貢献になる
私たちはすでにOSSから数多くの者を得ています。OS、プログラミング言語、エディタ、多くがOSSとして提供されており、私達開発者はOSSがなければ何もできません。
そして、OSSは貢献することでより多くの恩恵を得られるものでもあります。例えば、そのエコシステムやコミュニティに参加することで、より良い使い方を見つけたり、自分たちのユースケースにフィットした機能追加に協力できたりもします。自分達にとって望ましい方向性の提案や、望まない方向へ変化しないように意見を述べることもできます。非互換変更を事前に察知して対応準備を早めに進めることもできます。その意思決定プロセスに深く関われるほどお得とも言えます。
OSSへの貢献というとハードル高く感じてしまうかも知れません。ただ、私がよく言っているのは「OSSは使っていることを公言するだけでも貢献である」ということです。例えばSNSで「このOSSとても便利」だと一言ポストするだけでも開発者からするととても嬉しく、モチベーションに繋がります。そういう採用実績が目に付くと他の人からしても利用の検討材料になります。そういう小さなところから始め、ブログにまとめてみる、他の人の利用開始を支援する、issueを上げてみる、ドキュメントを改善してみる、pull requestを送ってみるなど、少しずつステップアップしていくと良いでしょう。貢献方法は無数にあります。
Social Codingの楽しさ
GitHubが"Social Coding"をモットーとしていたように、OSSは人間同士の社会活動です。OSSに貢献するにしても、そのOSSがどのような貢献を望むかは異なります。既存の貢献ガイドラインや作法は不慣れな人への手助けになるとは思いますが、それらを形式的マナーとして機械的に適用するのではなく、個別の背景や文脈に敬意を払ってコミュニケーションをするべきです。幸い、OSSにはリポジトリ上に過去の変更履歴や議論のログが見られる形で残っています。そこで事前に調査すればコミュニケーションがスムースになるでしょう。
コンピューターに向かう仕事だったはずなのに、どうしてそのように他者と向き合ってコミュニケーションを取るようになったのか、と人付き合いがそれほど得意ではない自分からしても不思議に思うことはあります。でも今では、コードと言う共通言語を通して議論しながらソフトウェアをより良くしていくこと、自分のつくったソフトウェアのフィードバックを得られること、様々な技術や流儀を新たに知ること等に面白みを感じるようになったのです。
英語でのコミュニケーションがハードルになるかも知れませんが、共通の話題があるので、稚拙な英語でも何とかなります。英語ネイティブではない開発者も多いので、受け入れる雰囲気もあります。今なら多くの翻訳ツールの支援も受けられます。ハードル低く英語を使う機会と練習になることは寧ろメリットだと私は捉えています。
あなたのOSSはあなたの作品である
ソフトウェア開発は創造的な活動でもあります。絵や音楽が得意な人がいるように、私にとってはソフトウェア開発が創造性を発露させてくれるものです。OSSは私たちソフトウェアエンジニアの創造性を自由に発揮できる場です。
あなたのOSSはあなたの作品です。それをどのように扱うかは自由です。まずは、ちょっとしたモノを公開して、自分で自由に利用するだけで構いません。OSSにできるレベルで抽象化して切り出すことは設計の練習にもなります。
あなたが初めてつくったOSSは大して注目を集めない可能性が高いでしょう。それでも自分自身が利用者であることや、利用しなくても何らかの学びに繋がればそれで良いのです。どうせ大して注目を集めないのだから、気軽にやれば良いと言う話でもあります。
運が良ければ、自分のOSSにフィードバックが得られたり、利用者が現れて思わぬ広がりを見せることもあります。それはとても嬉しいことです。それと同時に、自分のキャパシティを超えたコミュニケーションで消耗することも出てくるかも知れません。例えば、大量のフィードバックを捌ききれないこと、意見の対立、機能提案やpull requestの却下などNoを言うことの心苦しさなどがあります。そういうときは、どうしても引きずられてしまうかも知れませんが、あなたの気持ちを大事にして、付き合い過ぎないようにしましょう。
繰り返しますが、あなたのOSSはあなたの作品です。それを私的な物からどれくらい公器的な存在に変化させていくかも自由です。これは、料理に似ているかも知れません。あなたのレシピを単にあなただけで楽しんでも良いし、友人に振る舞っても良い。人気が出たらお店を開いても良いし、チェーン展開を計っても良い。ただ、周りが「これは絶対お店を出すべき」とか「チェーン展開しましょう」と言ってきたとしても、その機運を前向きに捉えられれば良いですが、気が乗らないのであればやらなくて良いのです。
OSSは自由で楽しい活動ですし、今後もそうあって欲しいと願っています。OSSに興味がありつつも踏み出せない人は多いと思いますが、まずは気負わずOSSを始めてみてはどうでしょうか。勉強会等に参加すれば多くのOSS開発者に会えるのでそこで話を聞いてみても良いでしょう。私にも是非話しかけてください。OSSの楽しさや魅力についてもっとお話できればと思います。
寄付先「reviewdog」の推薦理由
reviewdogは様々なリンターと連携し、GitHubやその他のコードホスティングサービスでコードレビューコメントや修正提案を自動投稿するOSSツールです。実行プラットフォームや言語に依存しない柔軟さと強力さを兼ね備えており、多くの開発の現場で使われています。私も日々の開発や執筆のコード管理でお世話になっているため、寄付を募ります。