knqyf263's blog

自分のためのメモとして残しておくためのブログ。

OSSエンジニアを1年やってみた所感

最近脆弱性の話とか本業と一切関係ないことを書いていたので、今回は本業に関する話です。

2019/08/01にOpen Source Engineerという肩書になってから既に1年が経過しました。そういうポジションの人はまだ日本では少ないんじゃないのかなと思ったので何か参考になればと所感を書いておきます。ちなみに最初の頃Open Source Software Engineerが正しいんじゃないのかな、とか気になってたのですがみんな細かいこたぁ良いんだよっていうスタイルなので自分も細かいことをうだうだ言うのはやめました。

単に今の所属企業でたった1年やってみた上での感想なので、全然一般的な話ではありません。ベンチャーならではの話も多いので大企業ではまた異なると思います。それでもOSS開発を業務として行うことに興味がある人がいれば読んでもらえればと何かしらはプラスになると信じて書いてます。せっかく色々と学びを得たことだし、とちょくちょくメモしてたやつを全部1つの記事に書いてたら例によって長くなったので、OSSに興味ない人はそっと閉じて下さい。

以下でも書いてますが本当に個人の感想なので必ずしも共感されると思ってはいません。そういう気持ちの人もいるんだなという参考程度に考えていただきたいです。

その前に少し前提を書いておきます。

前提

OSSって何?とかはググれば出るので説明しません。また、OSSへの貢献はハードル低いのでやってみましょうとかも本記事の対象じゃないです。単純にOSS開発を生業にすることの所感を書いています。

そもそも何でお前はそんな仕事してるんだっていうのは過去に書いてあります。

knqyf263.hatenablog.com

あと自分は既に社会人を5年ほど経験していますが、インフラやセキュリティを主な仕事としていたためプログラムを毎日書くような開発者として働き始めたのは今の会社に来てからです。そのため、普段からプロダクト開発をしている人からすると「それはOpen Source Engineerに限った話じゃない」とかもあると思いますが、こいつ経験がないから知らないんだなと思ってもらえれば幸いです。

逆に言うとそれぐらいプロダクト開発に疎い人間でも何とかやれているので、ある程度コードが書ければ務まるポジションなんじゃないかなとも思っています。

所感

ということで感じていることを適当に羅列します。

楽しい

まずはこれにつきます。OSSということで基本的には直接ユーザに使われるものではなく、技術者に使われることがメインです。そのため、ソフトウェアエンジニアに使われるものを作るのが好きな人にとっては最高に楽しいと思います。自分の場合は学生時代にエンドユーザ向けのサービスにいくつか携わらせてもらった結果、一般の人達に使われるものを作ることに楽しみを見出せない人間であることを知りました。そのためネットワークやセキュリティなど裏方というか直接エンドユーザの目の触れない部分に楽しみを見出して生きてきたのですが、OSSもサービスを裏方で支える重要な要素の一つであることに気付きました。

そこでOSS開発を趣味で始めたのですが、自分の作ったソフトウェアが世界中の人から感謝されたり、所属組織も異なる開発者達と共に開発するというのが何にも代えがたい経験であると感じました。国境も会社も越えて一緒に何か一つのことを目指すような活動を自分は他に知りません。

これは仕事としてOSSに携わったとしても変わりません。毎日楽しくて仕方ないという感じです。ただエンドユーザに何かサービスを提供して生活を変えたい...!!という思いが強い人も多いと感じているので、万人にとって楽しいかというとそんなことはないかと思います。ですがOSS活動を休日に趣味でやるぐらい楽しめる人にとっては天職だと思います。

そもそもOpen Source Engineerというポジションの募集がほとんどないという現状がありますが、 GitHub Sponsors によってOSS活動でお金を貰えるようになってきていますし、BoostIOの横溝さんのようにOSSで生きていくエンジニアを増やそうと意欲的に活動していらっしゃる方もいるので少しずつこういったポジションも増えていくのではないかと期待しています。

codezine.jp

やりがいがある

そもそも上の楽しさも一部やりがいから来ています。自分が趣味で作り始めたOSSは現時点では知名度があるとはまだお世辞にも言えないのですが、企業でメンテナンスを続けさせてもらえることになり機能を色々追加していった結果、誰もが知っている大企業や政府のプロジェクトで採用されていたりします(公には言えないやつですが)。そしてMicrosoftが自分の作ったOSSを使ったGitHub Actionを公開したり、イギリス政府のブログAWSブログ に載ったりもしています。このように色々な国の色々な企業から認知されていると思うと何かしらの脳内物質が出ます。ブログ読みながら白飯2杯ぐらいいけます。つまりおかず代が浮くので節約にもなります。

他にも有名なOSSの内部で使われたり有名な製品内部で使われたりというのも本当に嬉しいです。

www.infoq.com

GrafanaなどのOSSのCIでも使われていますし、先日のKubeCon Europe 2020でも色んな発表で名前を出してもらっていました。

毎日仕事を頑張るだけでどんどん認知され広く利用されていくのはやりがい以外の何物でもないかなと思っています。巨大OSSにコントリビュートしてメンテナーとして頑張るというのももちろん最高に楽しいと思いますし、自分のように個人で始めたOSSを育てていくのも楽しいです。自分も元々は既存のOSSに貢献して満足していたのですが、やはり元々作った人の存在感というのは大きいですし(Linuxだとリーナスだったり)大きいOSSだとあまり個人云々という感じでもないなと思い、段々個人で何か開発したい気持ちが強くなりました。

その結果自分で作ってみて今に至るのですが、上のInfoQの記事のように個人名で載りますし利用事例が公開された際の喜びは一入かなと思います。もちろん0→1が得意な人、1→10が得意な人、10→100が得意な人、またはそれぞれのフェーズが好きな人、がいるので必ずしも個人で作るのが良いとは全く思いません。多くの人で協調して大きな物(LinuxだったりKubernetesだったり)を作るのも当然楽しいです。

いずれにせよそういった活動を楽しめる人にとっては仕事というよりは趣味といった感覚で毎日を過ごせるので本当に幸せになれると思います。自分も仕事という意識はあまりないですし、運を使い果たしてそろそろ死ぬのかもな...と思ってます。

作ったOSSが広く使われると嬉しいという話をしましたが、一方で恐らく一生ソフトウェアエンジニア以外にその貢献が知られることはありません。IT業界以外の友人にLinuxの開発者を聞いても間違いなく知らないと思いますし、何ならLinuxの存在も知らない可能性が高いです。

自分としてはそういったIT業界以外の人は誰も知らないけど誰もが使うようなものの内部で動いているソフトウェアの開発者といった肩書の方がかっこいいと思うのですが、中にはそれの何が楽しいの?と感じる人もいると思います。そういう人には本当にオススメしないです。Open Source EngineerというポジションからFacebookザッカーバーグになることはないです。起業して何かサービスを作るほうが良いです。

実績になる

OSSに携わっている人が優秀かというと必ずしもそんなことはないと思っていますが、少なくともOSSとして自分のコードが公開されているため実績として分かりやすいというのは利点かと思います。例えば就職/転職活動の時に職務履歴書を頑張って書かなくても自分のGitHubアカウントを渡すだけで終了したりします。つまりOSS活動が名刺代わりになるので多くを語らずに済むようになります。

実際今の会社に入る際も一切履歴書を書いていません。自分の採用を決めたCTOは自分が何歳で、どこの大学を出ていて、どういう企業で働いてきて、どういう仕事をやってきたのか、ということを全く聞きませんでした。「あのOSS作ったんだろ?それ以外は別に知らなくて良い」という感じでした。純日本企業育ちの自分としては年齢すら聞かないというのはなかなか痺れました。逆に自分としてはもっと過去の実績を色々伝えたいと思って寂しくなったぐらいでしたが、こっちではいわゆるジョブ型雇用が一般的なのでそのポジションで必要とされるスキル以外については知る必要がないのかと思います。ジョブ型雇用のように仕事に見合った人材を登用するのとは反対に日本のメンバーシップ型雇用では人を見て仕事を振るため、その人の経歴などが重要になります。教育という観点ではメンバーシップ型も悪くないと思いますが、既に何か得意分野・または興味のある分野を持つ技術者にとってはジョブ型の方が幸せになりそうです。

www.businessinsider.jp

ただ採用する側としては有名なOSSのコントリビューターだから、といった理由のみで採用するのは危険だと思います。せっかくコードや発言が公開されてるので具体的な活動まで踏み込んで確認することをおすすめします。実際にどの機能を開発したのか、とかレビュー時の他の開発者とのやり取りとか、はOSS活動から読み取れると思いますし、プログラム書くのは得意でもプロダクト開発には向いてないケースとかもあるのでやはりその人の考え方などは面接等で確認したほうが良いと思います。

実績になるのは事実ですが、それだけで判断するのは怖いかなという感じです。自分の極端な例を出しておいてなんですが。

得意な形でアウトプットできる

上で書いた実績の話と似てるのですが、OSS開発をすることでそれがそのままアウトプットになります。ソフトウェアエンジニアにとってアウトプットは重要というのはよく話題になることですが、登壇やブログ・本の執筆などが挙げられることが多いように感じます。もちろんそういった登壇やコミュニティ活動というのは重要なのですが、自分のようにそういう活動が得意ではない人もいます。

嫌いなわけではないので声かけていただいたら喜んで発表等するのですが、自ら進んで志願するほどではないという感じです。ナッツとか誰かから貰ったら美味しく食べますが自分で買うほどではないです(?)。

不得意なことを頑張って改善するよりは得意を伸ばしたほうが良いのではないかと考えているため、OSS開発が得意な人はそちらでアウトプットすれば十分だと思っています。もちろん何が得意かは人次第なので登壇が得意な人は登壇を続ければ良いし、ブログ書くのが得意ならそこで頑張れば良いです。自分が言いたいのは他の人が登壇しているから自分も登壇してアウトプットしなきゃ、と焦る必要はなくて得意な方法でアウトプットすれば良いということです。

OSSはその手段の一つとして使えるので、他の方法によるアウトプットが苦手な方にもおすすめです。

勉強になる

様々な人からIssueやPRを受け取ることになるわけですが、そこから学ぶことはとても多いです。こういうフォーマットに対応するとこういうサービスで使えるよ、とかこのライブラリなら解決できるよ、この機能はこうすれば実装できるよ、といったことまで幅広く教えてもらうチャンスがあります。自分の開発しているOSSの周辺情報は何もしなくてもかなり集まってくるので捗ります。

PRでこういう書き方出来るぞと教わるケースもありますし、自分がレビューで指摘した箇所に関してもPR送ってきた人のほうが理解が深くて自分が間違いを正されることも普通にあります。最初はメンテナーなのに恥ずかしいなとか思ってたんですが、最近はもう勉強になるなぁと思って素直に教わるようになりました。関係ないですが自分にとって凄いと感じる人は部下からでも積極的に学ぼうとする人です。変なプライドは捨てて学べる機会があればどんどん学ぶ人が最終的に強そうです。

深く特定領域を学べる

一つのプロダクトを開発し続けると相当細かい知識を得ることになります。もうこれ世界で自分が一番詳しいだろう、みたいな感覚になります。そうするとその領域を専門分野と呼べるようになるので、自分が何者か自分で説明しやすくなります。

過去の自分は片っ端から色々と手を出して触っていたので、幅広く出来る方だなと不遜にも自分で思っていたのですが「結局自分は何者なんだ?」という思いがずっとありました。あれもこれもそこそこ出来る、でも何も出来ない。という虚無感がありモヤモヤとした日々を過ごしていました。今ではこれが出来ます、と胸を張って言えるようになったので精神的にかなり落ち着いています。

コンピュータサイエンスは幅広いので少し離れただけで門外漢になることはよくあると思いますが、自分の詳しい分野があると物怖じせずにやっていけるなと思います。もし漠然と凄い人々との差を感じているようであれば、個人的なおすすめは色々と手を出すより先に自分の専門を作ることです。

T型人材が良いと言われたりもしますが、TになるためにはーかIをどちらか先に伸ばす必要があります。ー型といっても無限に横に広いので、何かを学んでもまた違う分野のスペシャリストを見かけて焦りを感じる羽目になります。それであればIをしっかり掘り下げてから横に広げる方が精神的には良いと考えています。ただ上で書いたようにメンバーシップ型雇用の場合はー型の方が有利だと思うので必ずしもどちらが良いとは言い切れません。あくまで精神的には専門を先にやる方がおすすめという話です。

www.kaonavi.jp

得た知見を公の場で共有しにくい

上で書いたように特定の領域における細かい知識を多く得ることになるのですが、これらの知見を勉強会等で共有するのは非常に難しいです。プロダクト開発であれば他社でも困っていたりするので自社で困ったことを共有するのは大いに意義があることなのですが、OSS開発で得た細かい部分の知見というのは似たOSSの開発者じゃないと活かせません。

もちろん良いテストコードの書き方とか拡張しやすいアーキテクチャとかフィードバックできる部分もあるのですが、やはりその領域に関する知識は披露する場があまりありません。例えば自分は昨年OSS開発する際にrpmソースコードを読んでデバッグしてrpmdbのバイナリフォーマットを解析したりしたのですが、そんな話多分誰も聞きたくないので自分の脳内に留まっています。もちろんそういう細かい知識を求めている人も世の中には0ではありませんし、何より自分で忘れてしまうので可能であればそういう知識もどこかに書き留めておくほうが良いです。

ただ多くの人に求められているわけではないのでモチベーションにも影響しますし、やはり多くの人にとって有用な知識を共有できるか、という観点でいうと難しく感じます。それよりはAWSの新サービス試してみた、とかCNCFの新しいOSS使ってみた、とかの方がウケは良いと思います。

でもそれが専門分野ということだと思うのであまり気にしてませんし、むしろ上に書いた理由から心地よいとも思っています。ただ今の会社に入って同じことをやっているチームがあり、自分の知見を披露できる場があったのでここぞとばかりに早口で喋り倒しました。というのは嘘で実際には英語でそんなに早く話せないので脳内で話すスピードと英語のスピード差が大きすぎてストレスを溜めました。

いずれにせよ、一人で黙々とやっていた時に比べると議論できる相手がいるというのは嬉しいものです。勉強会とかで話すのもそういう効果があると思いますが、OSSの種類によってはそれは難しい可能性があるということは知っておくと良さそうです。

広く触れない(可能性がある)

例えば一つプロダクト開発しようとするとインフラからアプリケーション、セキュリティまで求められる要素は幅広いです。大企業であれば細かくチームが分かれていることもあるとは思いますが、例えばインフラチーム内だけでもコンテナオーケストレーションだったりストレージだったりサービスメッシュだったりと多岐にわたります。

一方で一つのOSSに集中すると、上で述べたように特定領域を深く掘り下げる必要があります。そうすると幅広く色んな技術を試すといったことは難しくなります。SNSやブログを見ていると色んな人が色んなことをやっていて、それを見て焦ることもあるかもしれません。

過去の自分も自分が知らないことを他人がやっているのを見て焦りを感じていました。そのため少しでも知らないことを減らさなければ...と色々と手を出していました。しかし自分の強みを得たことによってそういった不安はなくなりました。もちろん好奇心をなくしたわけではないので面白そうなことは試していますが、無意味な焦燥感によって全部やろうとしてしまって何の専門領域も持てず器用貧乏になってしまうということはなくなりました。

そのため"広く触れない"、と書きましたがそれがマイナス点だとは思っていません。むしろ他人の活動に惑わされずに自分のするべきことに集中できるので良い点だと思っています。念のため書いておきますが、それを言い訳に新しいことを学ぶ必要がないという意味ではないです。この業界は変化が早いので今の状態が快適だからと他領域の勉強を完全に怠ればすぐに置いていかれると思っています。不必要な焦りや不安がなくなるという点で良いことだと考えています。

発表された新しいツールや技術を次々と試してまとめたり発表するのももちろん楽しいですが、自分で一本軸を持って集中して掘り下げていくのも楽しいです。

なぜ会社としてOSSをやるのか?ということを真剣に考えられる

弊社はまだベンチャーにも関わらず(といっても260名ぐらいはいる)OSSをメインで行うチームがありまして、6名も人員を割いています。さらに兵役中のメンバーも入れると8名ほどいます。GAFAMなどの巨大企業と違い、まだ売上を増やしていかなければならない会社状況でOSSチームが存在しているのは結構珍しいのではないかなと思っています。

大企業であれば社内で必要なものをせっかく作ったからOSSで公開しよう、といった動機も結構あるのではないかと想像しています。そしてコミュニティの協力を得られれば自社の開発リソースも減らせて良い、という感じかなと思っています。

一方で弊社はもっと直接ビジネスに繋げる必要があります。そのためなぜOSSを会社として注力するのか?というミーティングが定期的に開かれます。HashiCorpやElasticの事例を見ながら色々意見を出し合ったりします。かなりたくさんあるのですが、面白いと思った考えをいくつか共有しておきます。

市場の熟成

例えば弊社ではクラウドネイティブのセキュリティ製品を提供しています。そのため、クラウドネイティブの市場に成長して貰う必要があります。さらにDevSecOpsのように開発や運用にセキュリティを統合しようという考えも推進しているのですが、残念なことに世の中的にはまだそこまで広まっていません。もちろん感度の高い一部の方にとっては当たり前になっていますが、それ以外の人にとっては全く馴染みがなかったりします。知らない概念のものを導入しましょう、といった営業をかけたところで勝ち取るのはとても難しいです。そのため、まず人々にDevSecOpsという考え方に慣れてもらう必要があります。

そこで、OSSとしてそれらの概念を体験できるものを提供することで多くの人に慣れてもらいます。OSSであれば無料なので導入のハードルはそこまで高くありません。一部にはサポートのないOSSなんざ使わんという企業もありますが、全体で見れば有料製品の導入に比べたら確実に多くの人に使ってもらうことが出来ます。

そうして市場の熟成を促し、その上でOSSの不足部分を製品によって補ってもらうという進め方が可能です。自分だったらどうやって自社製品の売上に繋げるかという目先のことばかり考えてしまって、そういった大きい視点は持てません。このやり方が正解かどうかはまだ分かりませんが、少なくとも自分にとっては非常に興味深かったです。

有料化のしやすさ

OSSを主軸にビジネスしている企業はいくつかのタイプに分かれます。OSSの保守契約でお金を貰うパターン、自社ホスティングなら無料だがSaaSは有料というパターン、OSSの不足機能が有料版では使えるというパターン、などなど。いずれにせよ既にOSSを使ってくれている企業であれば、完全なる0から導入に繋げる場合と比べて有料化は容易になります。全く聞いたことのない企業が営業に来るよりも、既に使っているOSSの開発元であれば信頼度も異なります。

一方でOSS版で十分だから有料化は要らない、となる恐れもあります。そのため、OSSによって失う顧客と得る顧客の率を考慮して戦略を展開する必要があります。そのへんは詳細省きますが、色々議論していて面白いです。

品質の向上

これは実際にElasticの方に伺ったことなのですが、元々有料プラグインのX-Packはクローズドソースだったものの、現在ではソースコードが公開されています。

elasticsearch/x-pack at master · elastic/elasticsearch · GitHub

クローズドで開発していたときはどんどんソースコードがスパゲッティになっていってしまったが、公開してからは品質が保たれるようになったとのことです。やはり第三者に見られる、ということで雑なコードは入れられないという意識が働くのかなと思っています。

ちなみに公開しちゃったら有料化出来ないじゃんと思うところですが、特定のディレクトリだけ異なるライセンスで提供されています。Elasticsearch全体はApache Licenseでx-pack以下だけElastic Licenseになっています。こうすることで、ソースコードを公開しながらもOSSとしては利用できないようにしています。なのでX-Packの例は厳密にはOSSではなくソースコードを公開することによる利点の話になります。

ここら辺のライセンス戦略というのも各社の色が出ていて面白いです。

カンファレンスでの発表

当たり前のことですがOSS系のカンファレンスであれば発表内で製品の宣伝をすることは出来ません。つまりLinux Foundation系のOpen Source SummitとかKubeConでの発表ができなくなります。しかし自社でOSSを持っていれば遠慮なく発表しに行くことが出来ます。ユーザ企業であれば自社事例などの道が残されていますが、セキュリティベンダーとなるとそれも少し難しいです。そのため、OSSによって発表ができるというのは会社の知名度を上げる上で有用です。

実際、うちのチームのマネージャーは年間で信じられない回数の発表をこなしています。その結果ベンチャーにも関わらずクラウドネイティブ界隈で弊社の名前を知っている人はとても多く感じます。それら発表の中にはKubeConのKeynoteとかも入っていて化け物説あるので単に発表する場合とは少し事情が異なるかもしれません。

ファンを作る

これはうちのマネージャーが明確に目標に掲げていることなのですが、OSSを通じて自社のファンを作るということを目指しています。OSSを好きなソフトウェアエンジニアというのは多いです。さらに単に好きなだけではなくて勉強会などで発表してくれたりもします。「あれ使ってみた?良かったからおすすめ」という会話がエンジニア間ではよくなされます。そうして口コミで広がってくれれば、自分達で宣伝しなくても多くの人に知ってもらえます。

さらに良いツールを提供している開発元というのは開発者に愛されます。自分も使っているツールなどは開発元を見に行って、「こういう会社が作ってるのか。良い会社なんだろうな。」と思ったりしています。そういった状況になってからであれば、「おたくのツール使ってますよ!」となってスムーズに話が進みます。

会社の売上に貢献できる方が精神的に楽

これは人によると思うのですが、完全に会社の売上には関わらないというよりは多少でも貢献できる方が精神的に楽です。もちろん会社としてやっている以上、会社にとって完全に無駄ということはないと思いますし自動化による工数削減とかマシンリソース削減によるコスト削減とか何かしらに繋がっているとは思います。しかし自分にとってはそれでも申し訳ない気持ちが残りました。実際に過去に所属していた企業で業務でOSSへコントリビュートしても良いよ、と言っていただいたものの全然企業にとってプラスに感じられなくて申し訳なさでいっぱいになったことがあります。業務時間の10%とかならもちろん問題ないですが、もっと真面目に貢献したいと思い始めると50%とかもっと時間を使いたくなります。そうなった時に自分の中で(あと会社との間で)折り合いをつけられるか、は重要だなと感じました。

これは恐らく人によるので、全然気にならない人もいるはずです。自分は給料貰っている以上は何かしら貢献したいという正義マンな部分があったので、もう少し直接的に貢献したいと思っていました。しかしだからと言ってつまらない仕事をしてまで会社に尽くしたいというほどの自己犠牲マンでもなかったので、完全にわがままマンです。

もしそのような考えの人が自分以外にいたら、単に毎日OSS開発すれば良くてサイコーとならないことは注意して欲しいです。今は自分はOSS開発して好きなことやりながら、それをSaaSとして提供してくれる別のチームがあってビジネスに繋げてくれます。このバランスは正直言って精神衛生上最高なので、OSS開発して会社に何のメリットがあるの?というのは事前に良く相談したほうが良いです。単に好きなことだけやっていると苦しくなる時が来る可能性があります。

そういう点で考えると巨大OSSの1メンテナーというのは会社への貢献度合いをどう評価するか難しいかもしれないと感じました。もちろんLinuxディストリビューションを売っているのでLinuxのメンテナーをたくさん抱えています、というのは至極当然な方針だなと感じますが、単に会社でLinuxを使っているので1人メンテナーを雇いますとはならなさそうです。メンテナーがいることで必要になった機能やバグを直してもらいやすいとかはあると思いますが、それもどの程度発生するのか次第で年に1度程度ならそれ以外の期間は何をするのか?というのが問題になりますし、そもそも多くメンテナーがいるOSSだと一存で決められるわけでもないので会社で一人メンテナーを抱えていてもどの程度影響を及ぼせるか、というのが問題になってきます。

その点、自社開発のOSSやそのOSSを製品化しているケースなどはメンテナーの存在がより重要性を増すので良さそうだなと思います。自分は今まさにそのケースなので思う存分集中できています。ある程度大きくなるとベンダーニュートラルじゃないと嫌だという方向性になってくるので難しいのですが、それは今回は置いておきます。

ということで仮に会社としてOKを出したとしても開発者側がいたたまれなくなるということもあり得るので、やはり会社側と自分側の双方において最初にきちんと合意しておくのが良さそうです。

ユーザからのフィードバックが助かる

やはりOSSの良いところですが、ユーザが使ってくれてバグを見つけて報告してくれます。中にはPRを送ってくれて直してくれる人もいます。現在弊社では有償版とOSSで中身が異なっているのですが(OSSは買収されてあとでファミリーに加わったため)、OSSで報告されたバグが有償版にも存在するということは多くあります。そういう場合はOSSがコミュニティと協力してバグを直し、それらを有償版にフィードバックするということが行われます。製品開発をしていると分かると思いますがQAのコストというのは大きいため、自発的に協力しようとしてくれるOSSコミュニティには本当に救われています。

さらにはバグだけでなく機能追加や新しい脆弱性データソースなども共有してくれます。CircleCIはJUnit XMLに対応してるからJUnit XMLの形式で出力できると便利だ、とかあの機能が非推奨になったらしい、という情報も入ってきます。このライブラリ使えばバイナリからこういう情報が取れる、とかこのデータソース使えばあの脆弱性も検知できそうだ、とか教えてもらったことは数え切れません。本来であれば自分で収集しなければ得られない情報ですが、OSSを公開しているだけで次々と情報が入ってくるのは大きな価値だと思います。これらはもちろん有償版にもフィードバックされます。

メンテナンスコストが高くなる

利用者が増えてくると要望が増えてきます。その機能いる?!みたいなのも多く見受けられます。そういう時に趣味であれば「不要だと思うのでクローズします」といったことが可能です。もちろんせっかくIssue/PR上げてくれた人をぞんざいに扱うのはよくありませんが、無料でメンテナンスしていて義務があるわけではないので無理に対応する必要はありません。

しかし企業として提供しているOSSとなればそうもいきません。上に書いたようにOSSを提供する目的としてファンを作るというのを掲げている以上、ある程度細やかな対応が求められます(量が多すぎて捌ききれない問題はまた別に存在してます)。そうするとカスタマーサポートをしている気分になってきてこれ自分の仕事なのかな...となります。幸いなことにまだクレーマーのような人はいませんが、ドキュメントにちゃんと書いてるのに...といったことを質問してくる人は多いです。

他にもニッチな機能なので追加したくないけど穏便に済ませたいので慎重に議論を進める必要があったりすることもあります。これは結構精神を削ります。

微妙なラインだけど幸せになる人もいるだろうしせっかくPR送ってきてくれたから追加するか、と一旦マージするとその後のメンテナンスコストは自分たちに降ってきます。その一回で終わらずにずっとそのコストは増えたままなので、本来であれば拒否するべきです。しかし人間の心情的にそこまで機械的に弾くのは難しいですし、自分の心との戦いになる部分があります。もちろんニーズの有無などから判断するべきなのですがOSSの場合は勝手に利用状況を取得するわけにもいかず、どの機能が使われているのかなどを把握するのが難しいです。

方針を決められなくなる

元々自分が作っていたOSSの場合の話になるのですが、初期は当然全て自分の判断で開発できます。しかし会社に譲渡してからは会社の方針に従う必要があります。これがなかなか大変です。

例えば自分の場合はとにかくツールを小さく作ろうと最初にポリシーを定めてから開発を始めました。そのため、余分な機能や情報は足したい衝動と戦いながらも泣く泣く落としてきました。大きくなればなるほどメンテナンスも大変になるし利用者にとっても学習コストが高くなります。何でも出来る万能ツールより小回りの利く小さいツールのほうが将来を考えると良いだろう、と決めてやってきたのですが会社としては何でも出来るツールにしたいということで何度も議論したのですが結局自分が折れることになりました。

元々はCIで使えるようにコンテナイメージの脆弱性スキャンをする軽量なツールを作っていたのですが、今ではサーバ機能だったりファイルシステムやDockerfile内からスキャンする機能も追加されています。自分の掲げた理想からはどんどん離れていって「くぅ〜」となりましたが、一方でそれらを必要としているユーザもいるので一概に悪とも言えず難しいところです。

また、セキュリティツールにとってfalse positiveがないことが最も重要であるというのが自分のポリシーです。大量に検知すればfalse negativeを減らせますが、大量にアラートを出すセキュリティ製品はやがて誰も見なくなります。もちろんそれが正しいアラートならまだ良いですが、嘘ばかりとなれば嫌気が差します。オオカミ少年と同じです。

そのため、自分はツールを作る上で過検知しそうな機能は極力入れないようにしました。仕組み上、全ての脆弱性を検知するのは難しくどうしても検知できない部分があります。しかしそれを検知しようとすると今度は過検知の可能性が高くなります。そういう部分は許容するというのをポリシーとしてやってきました。

ですが会社としては仮に過検知したとしてもやりたいという方針です。こちらも話し合いましたが追加する方向性になっています。

ただし会社としても意見を押し付けているわけではありません。過検知してもいいから検知数を増やして欲しいという声が顧客から多いのを見て判断しています。そのため会社の考えもわかりますし会社の方針はおかしい!やりたくないことをやらされている!とか言いたいわけではなくて、単に自分一人で何でも決められた頃とは変わってしまうという話です。会社としてもより良くしようと考えて意見を出しているので自分にはない視点からのアイディアも多く得られますし、それ自体は良いことだと思っています。

そして会社はオリジナルの開発者である自分の意見を尊重してくれます。自分がヤダヤダと子供並みにゴネると受け入れてくれます。なのであくまでフラットに議論した上で今回は会社の方針に従います、といった決定がなされているだけなので何か問題があるわけではありません。

宣伝は必要

上で発表等しなくてもアウトプットできるので良いということを書いたのですが、せっかく良いものを作っても誰にも知られなければ意味がないのである程度の宣伝は必要になってきます。そうなるとやはりブログ書いたり登壇したりということになるので結局逃れられない...となるわけですが、プロダクトありきで発表するのはかなり楽だなと感じています。そのプロダクトについて自分が世界一詳しいので間違ったこと言ってないかなと不安になることもないですし、周りが凄い発表だらけでも「でも自分は良いものを作ったから大丈夫」と心を強く保てます。

自分はこの宣伝がとても苦手で、物怖じせず売り込んでいける人を見ていつも凄いなと思っています。今は仕事だしなとある程度割り切ってやっているので多少楽ですが、そういう作業が発生する可能性は頭の片隅に置いておく必要があります。そしてOSSの特性上、恐らく英語でのブログや海外での発表が求められたりします。自分はゴネたけど無理だったのでこの1年でCNCF webinarやKubeConなど3,4回は発表しました。プロポーザル出す時の知見も以下に書いてあるので興味があれば読んでみて下さい。

knqyf263.hatenablog.com

大変ではありますが自分の中で良いものが開発出来たと思えればそこまで苦じゃなくなりますし、せっかくなら楽しめるようになっていければいいなと思っています。

まとめ

後半大変な点も少し挙げてみましたが、全体で見れば本当に微々たる話です。多少しんどいところもあるということを知ってもらいたくて書いたものの、実際には楽しさが全てを凌駕します。毎日こんなにストレスゼロで労働して良いのだろうか?いやそもそもこれは労働なのか?というのが最近の所感です。

ということで興味ある人は一度やってみると良いと思います。現時点ではそういうポジションがあまりないかもしれませんが海外では多く見かけますし、日本でも将来増えると期待しているのでその時に備えて自分で趣味のOSS開発を続けてみるとか、出来ることから始めておくと良いかもしれません。