2年前の2019年8月に以下のブログを書きました。
今回はその続きです。前回のブログは多くの人に読んでもらうことを意識して書きましたが、今回はそうではないです。特に得た学びを書くわけでもなく何で作り始めたのか？とかどんなことがあったのか？とか思い出話を書いているだけなので、言ってしまえば自己満足の記事です。それで構わない人や前回の記事を見てその後どうなったか気になった人だけが読んでもらえますと幸いです。
誰かのためになるわけでもない過去の出来事について語るのは老人感が強くて基本的に好きではないのですが、自分の中で一番大きかった目標を達成したので節目として書いています。
英語版の記事も会社のブログから公開しています。英語版のほうが簡潔で良い可能性もあります。日本語版は誤った解釈をされると嫌だからもう少し詳細に書こう、を繰り返していつも長くなりすぎます。
繰り返しになりますが、この先長い上に何も得るものがない可能性があります。前回の記事のように何か面白い話を期待して読むと恐らく期待はずれです。
はじめに
概要
前回のブログを書いた時はまだイスラエルにすら行っておらず、ビザは7月末に出ると弁護士に言われ家を解約したものの結局ビザが間に合わずにホームレス生活を送っている最中でした。そんな全く先の見えない状態でブログを公開するのは正直かなり怖いものがありました。イスラエルに行って周りの優秀さに圧倒されて何も通用せずに帰国したり、買われたソフトウェアも将来性が見出せず結局すぐにメンテナンスフェーズに移行したりという可能性もありました。技術面以外でも行ったことすらない国に行っていきなり住むというのは博打要素がありますし、そもそも英語が全然出来ないので会話できずにクビという可能性も十分あり得ました。
結論から言うとこの2年間大きな問題もなく集中してやらせていただけて、既存の競合OSSを超えるという目標を達成することができました。今の会社に買収される前からの目標だったので約3年越しです。足したい機能はまだまだありますし目標達成したので終わりという感じは全くないのですが、一つの区切りではあるかなと思ったので振り返りを書いておこうと思います。
タイトルで分野世界一と強めの言葉を使っていますが、本記事内ではGitHubのスター数が一番多いことを世界一と表現しています。この点については後述します。
自分はTrivyというコンテナイメージの脆弱性スキャナーを作ったのですが、この分野にはClairという絶対的王者がいました。当時、Amazon ECR, GitLab, Harborなどコンテナ脆弱性スキャンを提供しているところは全てClairを使っていました。この分野では間違いなく世界で一番有名で、世界一使われていたOSSでした。自分はClairがこの分野で世界一だと思っていましたし打倒Clairで開発を始めたので、今回GitHubのスター数でClairを追い越したというのは自分にとっては想像もしていなかったぐらい非常に大きい出来事でした。
Clairのリリースは2015年で、自分が開発を始めた2019年時点で既にスター数は5,000を超えていました。その差を覆すのはほぼ不可能だろうと自分でも思っていただけにとても嬉しいです。以下にスター数の変遷のグラフを載せておきます。この2年で結構良いペースで伸びています。図にはGrypeというOSSも含めているのですが、このツールについては後述します。
Clairは元々Quayというコンテナレジストリのために開発されたツールでしたが、その後CoreOSに買収されます。そしてCoreOSはRed Hatに買収されます。さらにRed HatはIBMに買収されました。わらしべ長者みたいなストーリーですが、つまり今ClairはRed HatやIBMという大企業にメンテナンスされています。ちなみに元々の開発者は弊社CTOの友人なのですが、IBMを既に抜けています。大企業は持っている資金も人的リソースも段違いなので圧倒的パワーで今後追い越される可能性もありますが、とりあえず現時点では上回っています。まだ僅差なのでブログ公開直後に抜かれたら残念な感じになりますが、一瞬でも夢を見られたということで書き残しておきます。
GitHubスターについて
OSSをやっているとどうしてもGitHubのスター数というのは意識せざるを得ないため、せっかくなので一般的な話も含め少しまとめておきます。
「OSS以外の有償の商品でもっと凄いのがある」とか「GitHubのスター数が少なくても良いOSSはある」といった指摘に対しては自分も賛同しますが、今回はあくまでGitHubスター数による評価なんだなと思ってください。他の観点で見たら全然一番ではないという事はあり得ますが、例えば大学ランキングとかも評価軸を変えたら全然順位が異なるわけで今回もその程度の意味合いだと思ってください。「お前がそう思うんならそうなんだろう お前ん中ではな」ぐらいで構いません。とはいえOSSにおけるGitHubスター数というのは「からあげグランプリ 金賞」よりは納得感のある評価軸だと思っています。
どの唐揚げ店でも「からあげグランプリ 金賞」を受賞してます。
— バフェット・コード (@buffett_code) 2021年4月14日
気になって日本唐揚協会を見てみたら、あの手この手の切り口で受賞させてて笑いました。
・弁当部門、専門店部門、定食屋部門など計12もの部門がある
・鳥貴やかつやなど大手が漏れない設計
・コンビニに至っては大手4社がすべて受賞 pic.twitter.com/mlmk7XtaMY
注意点として、言語やカテゴリ異なるとスター数の伸び方も全く異なるので統一的な指標として機能するわけではないです。JavaScriptは開発者の母数が多いので伸びやすいとか、グラフィカルなツールは実際に試す前に何となくスター付けるから伸びやすいとか、細かい違いはたくさんあります。
マーケティングのテクニックによっても左右されるところがあります。大企業が公開するとそれだけで注目されたりもします。スター数と知名度が必ずしも比例するわけでもありません。
例えばログ収集ツールだと自分はFluentdが好きで、実際日本ではFluentdが一番有名な感じがしますが、スター数ではElastic社のLogstashの方が上です。これはLogstashがElasticsearchやKibanaなど他のツールとの親和性が高いことや、Elastic社のマーケティング戦術なども影響していると思いますし、必ずしも「スター数が多い＝優れている」というわけではないことは強調しておきます。両方使ったことがありますがどちらも良いツールです。
また、GitHubで公開されていないソフトウェアもあります。スター数は少ないけどユーザ数は多いライブラリなども多数存在します。例えば意識して使っていないけれど間接的に利用しているケースなどが挙げられます。本来は利用統計が取れると良いのですが、そういうコードをOSSに埋め込むと間違いなくコミュニティから激しい反発に合うはずなので普通は難しいです。
そういう事情もあり、やはり類似ツールを比較する上ではスター数というのは一つの指標としては機能するかと思います。言うまでもないですがスター数だけを求めるようなのは虚しいですし開発者として何も楽しくないので、良いものを作ってその結果評価してもらえるという形が良いです。そもそも上辺だけ取り繕ってもすぐにユーザにバレます。小さな改善を地道に続けた結果、見える数字もついてくるというのが一番だと思います。
時系列
過去のことは自分でも忘れつつあるのでツイートとか見て思い出しつつ簡単に振り返ります。この辺りの話は断片的に別のところでも書いたことがあるのですが、もう少し当時の心境とか細々したことを書きます。
開発を始めるまで
元々脆弱性が好きでしたが、自分で探すバグハンターのような仕事よりシステムをセキュアにすることに興味があることにしばらくして気付きました。そしてVulsというOSSのサーバ脆弱性スキャナーの開発に参加するようになりました。
当時サーバを管理していたので便利に使っていたのですが、しばらくしてコンテナ技術を利用するようになりました。コンテナならばもっと早い段階(CI上など)で脆弱性が検知できれば便利だなと考え、既存のOSSを探しました。そこでClairに出会うのですが、Clairはクライアント・サーバ型でサーバを事前に準備する必要がありCI/CDのようになるべく状態を持ちたくない環境には不向きに見えました。
これは今考えれば当然で、Clairは上述したようにコンテナレジストリ向けに作られたものだからです。目的が違うのだから自分の用途に合わなくて当たり前です。
Vulsもサーバ用に作られたものなので目的が異なります。サーバにSSHでログインしてスキャンできるため多数のサーバであっても軽量に実行できるのが強みですが、CI上での実行となるとやはり不向きでした。そこで元々Vulsで改善したい点もいくつかあったので、それらを踏まえて新たなスキャナーを作ることにしました。
その時のアイディアをVulsの開発者である @kotakanbe さんに話して、Clair倒せるやつ作ろうなどと某キャンプの打ち上げで言っていたのを覚えています。2018年の秋ぐらいでした。そこからずっと構想を温めていたのですが本業も忙しかったので、たまたま当時自分の所属していた企業にインターンに来ていた @hurry_41さんに構想の一部を切り出してテーマとしてやってもらったりしました。
そこからしばらく忙しかったため開発には取り掛かれずにいました。しかし @kotakanbe さんや @tomoyamachi さんの後押しやちょうどゴールデンウィークが10連休だったこともあり開発に着手しました。その辺りの話は別の場所でも書いたので省略します。
仕事が忙しくてその頃あまりOSSやれていなかったのですが、以前に作ったOSSに対してありがたいコメントが来ていてやっぱりOSS良いなと思ったのもやる気になったきっかけの一つです。Issueのタイトルにもrespectivelyって書いててややこしいですが本文にdeep respectと書いてあります。
respectって書いてあったのでリスペクトを感じました（単純）。会ったことないスイスの人から感謝されること普通に生きてるとあまりないので、お互いが感謝の気持ちを持つとOSSとても良いと思います。https://t.co/tGi2s14sM2
— イスラエルいくべぇ (@knqyf263) 2019年1月11日
あと、いつか作ろうなどと言っていてずっと作り始めず他の人が既に作ってしまったということもありました。実はVulsもその一つだったのですが、毎回「それ作りたかったやつ〜」とあとで言うだけの人間になっているように自分で感じていました。
いつか作ろうと思ってたやつ...いつかとか言ってるやつは何やってもダメhttps://t.co/j2qW5B6AuO
— イスラエルいくべぇ (@knqyf263) 2019年2月5日
当時既にコンテナイメージの脆弱性を検知するツールは複数存在していたのですが、自分のアイディアと似たものはありませんでした。今のアイディアを先に誰かに作られたら一生後悔するなと思ってGW10連休を費やす決心をしました。
開発中
構想を練っていた時、コンテナを実行せずにコンテナイメージを解析するということにこだわりを感じるようになっていました。当時の既存ツールの中には実行して解析するものもいくつかありましたが、自分としては絶対に実行したくありませんでした。そのことを周りの人に話したのですが、「コンテナ実行すれば良くない？何が駄目なの？」という反応でした。今考えればランタイムへの依存が不要になったりレイヤー単位でキャッシュできるようになったりといくつも利点を挙げられるのですが、当時は「何が駄目とかではなく自分がどうしてもやりたくない」という論理性のかけらもない理由で強くこだわっていました。こういう謎のこだわりを捨てずに済むのが個人プロジェクトの良いところかと思います。仕事だとまず無理です。
他にも自分が絶対にこだわりたかったのは、シングルバイナリで提供して適当にどこかにおけばすぐ使えるようにするという点でした。これはつまり外部のOSコマンドや他の言語（TrivyはGoで書いているのでGo以外）のライブラリが使えないことを意味します。例えばRubyの依存ライブラリ一覧を取得する際、 gem list や bundle list を実行すれば一発なわけですが、そういったショートカットができません。CGOによりCは使えたりしますが、クロスコンパイルが難しくなるので禁止しました。じゃあどうするかと言うと各言語の実装を理解して全てGoで書き直す必要があります。気の遠くなる作業ですが、そういったところで開発者が楽をするとユーザの利便性が低下します。
ここはしんどくても譲れないという想いが強かったため、まずapk, dpkg, rpmコマンドの実装を読んでOSパッケージを表示するために何をしているのか調べ、次にBundlerの実装を読んでGemfile.lockのパース方法を調べ、といったことを繰り返しました。
他のOSSを見渡しても普通に外部コマンドを実行していて誰もそんなところにこだわりは持っていませんでしたが、これまた個人でやっていたのでこういった細かい部分に時間をかけられました。実際には rpm コマンドへの依存だけGW中に倒すことができず最初は依存がある状態だったのですが、しばらくしてそれも解決しました。その辺りの細かい話は以下に書いてあります。タイトルはいかつめですが、競合OSSであるGrypeのメンテナと協力した良い話です。
そしてもう一つのこだわりは設定や事前準備不要でいきなり使えるようにするという点でした。他のツールは手元で脆弱性DBを構築し、設定ファイルを書いて...などと実行前に事前準備が必要なものがほとんどでした。セキュリティに時間もお金もかけたくない人・組織がほとんどなのにこんなに設定が面倒だとさらにセキュリティから遠ざかってしまうと感じていました。そのため、コンテナイメージ名を指定するだけでDocker EngineやDocker Registryから自動的にイメージを探して取得してくれて、DBも勝手に良い感じにしてくれるツールを目指しました。そうすることでとりあえずこのツール入れておくか、となってセキュリティがもう少し身近なものになってくれるかもしれないと期待していました。
最後のこだわりはやはり精度です。セキュリティのツールで誤検知ばかりするツールもありますが、そうするとやがてオオカミ少年のように誰も信じてくれなくなります。つまり、セキュリティ上の問題があると主張する以上は極力正しくてはならないというのが自分の譲れないポリシーでした。精度は高いべきというのは当たり前に思うかもしれませんが、世の中意外とえいやでやっているツールも多いです。
実際、他のツールの精度を評価したらイマイチなものが多いことが分かりました。ちなみに当時の結果ではClairの精度は他よりも高く、こういう差がユーザ評価にも反映されているなと感じました。やはり精度にこだわるのは間違っていないと確信を深めました。
そしてずっと引きこもって開発していたらどんどんこだわりが強くなって頑固親父みたいになっていき、謎の自信も湧いてきて「やってやるぞ！！」という意思表明をしたりもしてました。
世の中のコンテナ脆弱性スキャンツールは誤検知ばかりでいい加減我慢ならないので最高のやつを世の中に出したい
— イスラエルいくべぇ (@knqyf263) 2019年5月11日
大言壮語ではなくなって良かったです。
公開後
GWで開発したと言っていますが実際に公開したのは2019/05/17だったのでGWを1週間以上過ぎています。この延長期間は開発というよりは、ドキュメントにこだわり始めたら終わらなくなった感じでした。
以前petというOSSを公開したときは公開直後にあっという間にスター数が1,000を超えていたのですが、Trivyの時は公開してもしばらくはあまり伸びず駄目だったかと諦めつつありました。
ですが自分でも忘れていて驚いたのですが、改めてツイートを見返したら公開翌日に今の会社のCTOから連絡が来ていました。この頃はまだスター数も400~500程度だったはずです。その時に既に目をつけて自社のスキャナーを置き換える事を考えていたのは決断力が尋常じゃないです。フランス(?)だったかに出張していてカンファレンスか何かでTrivyがちょうど話題になり友人が教えてくれたらしいです。そしてすぐに自分に連絡したとのこと。フランス(?)には感謝です(?)。
MicroScannerの検知精度が高くないってREADMEに書いちゃったので開発元のAqua Securityからいつキレられるか不安だったんだけど、Aqua SecurityのCTOから「お前のアプローチ良いね。OSSのセキュリティ向上のためのアイディアについて議論しないか？」ってメールが来て、この業界は最高だなって思った
— イスラエルいくべぇ (@knqyf263) 2019年5月18日
しかし当時の自分はそんな怪しそうな話よりもTrivyが伸びるかどうかが気になっていたのでメールをスルーしてコミュニティの反応を見守っていました。2日ぐらい経って500行かない程度だったので終わった...と思っていたのですが、5/19にフォロワー多い人（現時点で9.6万人）が拡散してくれて一気に増えました。
trivy : A Simple and Comprehensive Vulnerability Scanner for Containers, Suitable for CI : https://t.co/25CHsV1CWi cc @knqyf263 pic.twitter.com/c5VAFlIw24
— Binni Shah (@binitamshah) 2019年5月19日
そのタイミングでクラスメソッドさんからの記事も公開されています。公開後4日ということで海外でも記事が出ていない中だったので、DevelopersIOの速度にはいつも驚かされます。
そして一週間経ってようやく1,000を超えました。
皆様のおかげでTrivyのスター数が1000を超えました！！！！！
— イスラエルいくべぇ (@knqyf263) 2019年5月22日
余談ですが最初にスターを付けてくれたのは @shibu_jp さんでした。
これ自慢なんですけど、一番最初のスターつけました。 https://t.co/sVMmqxr9eq
— 渋川よしき (@shibu_jp) 2019年5月22日
1ヶ月ほど経って、海外でTrivyを使ったプロジェクトを公開する人も現れるようになりました。
Today I am launching https://t.co/8s8jbJeBor which scans the 1000 most popular containers in @Docker hub for open CVEs using trivy and scores their risk using @KennaSecurity.
— Jerry Gamblin (@JGamblin) 2019年6月25日
そして2019年8月に今の会社に入って開発を続けるとことになりました。
会社加入後
2019年後半から2020年前半ぐらいでの出来事は以下にまとめています。
元々打倒Clairで始めたとはいえ絶望的な差があったのでそれを埋められるとは正直あまり思っていませんでした。ですが会社の人達が応援してくれているのを見てそれに応えたいなと思うようになります。それが2019年の秋ぐらいでしたが、この時点で知名度でもユーザ数でも圧倒的に劣っていたのによくそんな野望を持てたものだなと思います。そういうモチベーションを保てたという点だけを取っても個人ではなく会社として開発して良かったです。個人だったらどうせ無理だろうと諦めていた可能性が高いです。
早く新しいもの作ったり色々勉強したりしたいと思ってたんだけど、自分のツールを全力で宣伝してくれる同僚達を見てたらまずはClairを倒して世界一になってからにしようと思った
— イスラエルいくべぇ (@knqyf263) 2019年10月14日
当時働きすぎてマネージャーからも休めと言われるのですが、自分のためにやっていることであって仕事じゃないから気にしないで欲しいなどと言ったりしていました。実際この時期39℃の熱が出ていてテンションがおかしいですし、体調管理のためにも休息は大事です(当たり前)。
自分のツールが世界一になるチャンスが目の前にあるのに何か休む理由ある？
— イスラエルいくべぇ (@knqyf263) 2020年2月6日
2020年から2021年までのこともまとめていたのですが、仕事で締切に追われていたためまだ公開できていません。
この間、@masahiro331 もアルバイトとして大きく貢献してくれました。
Clairとの比較という観点で大きかったのは、HarborがClairからTrivyに乗り換えたことです。上でも述べましたが、2019年時点ではどこもかしこもClairだったのでこれは流れを変える重要な出来事でした。実際HarborはSUSEなど色々な製品の裏側で使われているので、間接的に多くの製品にTrivyが組み込まれるようになりました。
既に実装されているものをわざわざ置き換えるというのはかなりコストがかかるため少しの差があれば普通やりません。それだけ高い評価をしてくれたということです。
しばらくしてGitLabも同様にTrivyに置き換えました。
Released in GitLab 14.0: Container scanning in GitLab now uses the Trivy engine by default.
— 🦊 GitLab (@gitlab) 2021年7月20日
➡️ https://t.co/2ZwQWRcfYv pic.twitter.com/Bg3FTyK1ZM
こうした実績的に既に超えたと言えなくもないか…？とも思いましたが、OSSだしあくまでスター数で越えないとダメだなと思い改めて目標にしました。
そして何やかんやあって2021/07/22時点でスター数を追い越し今に至ります。
競合ツールについて
急に細かい話になりますが、今回の記事によって他のOSSは駄目なのかと誤解されるのは望むところではないので補足しておきます。
Clair
自分が今日まで頑張ってこれたのは間違いなくClairというライバルがいたおかげなので、本当に感謝しています。スポーツでもどんな分野でも目指すべき対象があるというのは重要だと思います。こんなの世界で自分以外誰が困ってるんだ、みたいな孤独を感じる時でもリポジトリを覗きに行くと同様に困っていたりして安心します。ライバルとはいえ公平に評価してもらいたいので、Clairの良いところを述べておきます。
まず再三述べているようにClairはコンテナレジストリ向けに開発されたツールです。実際、コンテナレジストリのように大量のイメージをスキャンする上ではClairに大きなアドバンテージがあります。ClairはPostgreSQLをDBとして採用しており、各コンテナイメージのメタデータや依存ライブラリをPostgreSQL上で管理しています。複数のイメージが同じ依存を持つことはザラなので、RDBの参照をうまく使うことで効率的に各イメージの依存性・脆弱性を管理できます。さらに、新たに脆弱性が公開された場合はDB内で関連するイメージの脆弱性結果を一気に更新することができます。全てのイメージを再度スキャンする必要がないためとても効率的です。
一方でTrivyではDBなどの事前準備を全て不要にしてとにかく簡単に実行できるようにしたかったため、RDBは使わず組み込みKVS（BoltDB）を使っています。SQLiteじゃ駄目なのか？などの選定理由は省略しますが、とにかくTrivyではClairのように実装するのは難しいです。Trivyでもキャッシュは可能な限り最適化しているため再スキャンは高速に終わりますが、それでも数百万〜数千万イメージある場合はある程度の時間がかかります。
つまり全てにおいてどちらかが優れているということは無くて、用途により向き不向きがあるということです。大量のイメージがpushされうるコンテナレジストリでは元々の用途を考えてもClairの方が利点も多いです。
Harborはコンテナレジストリですが、幅広いOSやプログラミング言語の依存性への対応、そして初回実行の高速さなどが上で述べた利点を上回っていると判断してClairからTrivyに乗り換えました。また、Clairは初回実行時にローカルで脆弱性DBの構築を行うため、ネットワーク帯域やCPU・メモリのリソースを多く使います。この辺りはトレードオフなので、今後は用途に応じて棲み分けが進んでいくのではないかと思います。
そもそも先人達の努力によって得られた知見を基に改善できるため、後発組のほうが当然有利です。自分はVulsやClairを見て全く異なる仕組みで作ろうと思い立ち開発を始めているので、先人達には頭が上がりません。
Grype
今回の話にGrypeはあまり関係ないのですが、上で述べたようにGrypeのメンテナと共同作業で悲願を達成できたこともあり感謝も込めて触れておきます。GrypeというのはAnchore社が2020年の10月頃に発表したOSSです。
Anchoreは元々コンテナイメージスキャンのツールを有償で提供していたのですが（無料分あり）、それをベースにOSSをリリースしたようです。自分で言うのもなんですがかなりTrivyに似ています。表示もおしゃれに作られていて、さすが後発組という感じです。
SBOM対応などTrivyにはないユニークな機能もあります。以前Alpine Linuxのメンテナがブログ内で比較していましたが、false positiveを増やしてでもfalse negativeを減らすというアプローチなのでTrivyとは大きく異なります。これもトレードオフなので、ユーザの好みに合わせて選択すると良いかと思います。
現時点ではTrivyの方が対応しているOSや言語も多く一日の長がありますが、先程も述べたように後発組の方が基本的には有利なので今後後進に道を譲る可能性はあると思っています。
前回の記事へのコメント
前回の記事は多くの人に読んでもらおうと思って丁寧に書いたので、文章に対する良い評価も頂けて嬉しかったです。かなり文章が長くなってしまったのに多くのコメントを頂きました。
趣味で作ったソフトウェアが海外企業に買われるまでの話 - knqyf263's blogb.hatena.ne.jpすごいし、懇切丁寧な説明もすごいし、すごい。
2019/08/20 15:25
趣味で作ったソフトウェアが海外企業に買われるまでの話 - knqyf263's blogb.hatena.ne.jpいい話だった、というかこの人の人柄がよいことが文章で伝わってきた。
2019/08/20 14:52
こういう誰でも意見を述べやすい記事に対してはネガティブなコメントもきっと多くつくだろうと予想していたのですが、実際には99%の人がポジティブなコメントを残してくださってインターネットの温かみを感じました。
一方で、カルチャー合うのだろうか？みたいな話や
趣味で作ったソフトウェアが海外企業に買われるまでの話 - knqyf263's blogb.hatena.ne.jpいい話だなあと思いつつ、競合潰しとアクハイヤーを兼ねてるんだろうなと感じる程度には心が汚れてる。ロックアップ条件とか気になる。企業のカルチャーが合うといいなあ。
2019/08/20 13:38
OSSとしてはもうダメなんじゃない？という指摘もありました。
趣味で作ったソフトウェアが海外企業に買われるまでの話 - knqyf263's blogb.hatena.ne.jp個人としては大成功だけど、OSSのプログラムは残念だけど死亡だな。
2019/08/21 00:01
これらに関しては自分もまさに不安に思っていた部分だったので、「いや〜分かる！！」みたいな気持ちでコメントを読んでいました。ですが既に書いたように非常に好きにやらせてもらいましたし、そのおかげもあってOSSとして結果も出せました。
ロックアップ条件とかも一切ありませんでした。そういった契約ではなく給料などで良い条件を提示することで残ってもらえるようにという配慮を感じるので良い会社だと思います。
一方で他社の話になりますが、OSS買収の話を持ちかけられたのにアイディアだけ盗まれて買収も雇用もされずといった非常に悲しい事件も2020年に起きました。そのことについてここで何か言いたいわけではないので会社名は伏せますが、自分は恵まれていた例だと思います。ですがそういう素晴らしいことも起きるということで少しは希望になれば幸いです。
また、
趣味で作ったソフトウェアが海外企業に買われるまでの話 - knqyf263's blogb.hatena.ne.jpすごいし夢のある話だけど、奥さんよくイスラエル付いていく気になったな
2019/08/20 15:30
や
趣味で作ったソフトウェアが海外企業に買われるまでの話 - knqyf263's blogb.hatena.ne.jpほへー。奥さんの感想も聞いてみたいというのは確かにある。
2019/08/21 02:11
など妻へのコメントもあったのですが、どちらかと言うと海外生活に慣れている妻に自分が付いてきた感じです。日本大好きな自分は海外に行くつもりはなかったのですが、妻から日々海外行けと刷り込まれた結果、気付いたら海外に来てました。人生長いので一度挑戦してみたい気持ちは内心あったのに気づかないフリをしていたところ、後押しされたというのが本当のところです。
妻は引っ越してわずか1ヶ月で犬を飼い始めヘブライ語学校に通い始めました。自分が海外生活に慣れてきたなーとか言ってる間にそれら全ての手続きが終わっていたので驚きました。物件探しなども自分は仕事だったので全て妻がやりました。挙句、こちらの病院でコロナ禍で子供まで産んでいます。自分は日本での出産を提案したのですが、こんな経験普通できないからということで妻がこちらを選択しました。
今はこっちの友人経由で仕事を見つけてきて社会復帰しようとしています。保育園の見学に行ったら英語速すぎて自分は何も聞き取れなかったのですが、妻が話を進めて結局申し込んでました。側から見ているともはや日本人のメンタリティじゃないなと思いますが、そのおかげで自分も何とか日本人のほとんどいない国で暮らせています。
趣味で作ったソフトウェアが海外企業に買われるまでの話 - knqyf263's blogb.hatena.ne.jpこれ、奥さんも凄くない？
2019/08/20 19:13
完全にその通りです。
今後について
目標を達成したので新しいことやるぞ！と言いたいところですが、先日新たな機能をリリースしたばかりです。
この機能はコンテナスキャン機能とかけ離れていてズルみたいな気がしますし本当はClairを上回ってからリリースしたかったのですが、ギリギリ間に合わずでした。ただリリースが7/12で超えたのが7/22なので大きな影響はなさそうだし良いかという感じです。
上の機能はベータ版のような感じでまだまだこれからです。他にも多数アイディアがあり、自分ももっと進化させたいという気持ちがあるのでしばらくはアクティブな開発が続きそうです。
スター数と知名度は必ずしも比例しないと言いましたが、Clairは知っているけどTrivyは知らないという人はまだ多くいます。リリース時期に4年間もの差があるため、その差を埋めるには至っていないということです。そういった観点でもまだ頑張らないといけません。
常々言っていますがこの業界は先が読めないので1年後にはどうなっているか分かりません。コンテナが一気に廃れてWebAssemblyになるかもしれませんし、後発のツールが圧倒的な力で既存ツールを置き換えていくかもしれません。その時はその時で新たな流れを歓迎しつつ楽しもうと思います。
まだアクティブに開発を続けると言いましたが、一方で自分の中であまりにも大きな目標だったので次は何を目標にしようと悩んでいるところです。有給もほとんど取らずに働いてきたので、一度秋ぐらいにゆっくり休んで今後のことを考えたいと思っています。未だに英語も怪しい自分を迎え入れて移住も全面サポートしてくれて、仕事では好きにOSS開発させてくれている会社に報いたいという気持ちがずっとあって、何かしら目に見える形で成果を出したいと思っていたので今回の件で精神的には大分楽になりました。CTOにあなたの目は正しかったと言えるようになってホッとしています。おかげでゆっくり休みでも取るかという気持ちになれました。
まとめ
個人プロジェクトから企業に移ってもOSSを楽しく続けることができ、ここ数年間の目標が達成できました。うまくいくのかと先行きを気にしてくださっていた方もいたようなので本記事で現状を共有しました。
他の人から見たら大したことないじゃん、という内容かもしれませんが自分にとっては大きな目標でした。そんな小さなことで喜べるなんて幸せなやつだなと温かく見守ってくださると幸いです。
競合OSSや類似製品に関して誤解や失礼があってはならないと思い冷静に公平に書いているつもりですが、内心はめっちゃ嬉しいので「よっしゃぁぁぁぁぁぁぁ！！！！！！！！！！！！（小躍り）」ぐらいのテンションです。もし何か失礼に当たる表現があれば恐らく自分の意図するところではないので修正します。
ここに至るまで多くの人に大変お世話になりました。この場を借りてお礼申し上げます。
