目次

はじめに

第1章 本当に「誰でもできる」の?

1.1 どんな人ならOSSに関われる?
1.2 OSSにフィードバックすると何が嬉しいの?
1.3 「つよいエンジニア」になるために本当に必要なもの

第2章 OSSを探そう

2.1 身のまわりにたくさんあるOSS
2.2 ソフトウェアがOSSかどうかを調べよう

第3章 何をフィードバックしたらいいのか分からない

3.1 フィードバックできるネタは日常の中にある
3.2 「注意が必要な点」で終わらせるのはもったいない
3.3 使い始めこそフィードバックのチャンス!
3.4 「有名ソフトウェアの」「あからさまな不具合」でも報告してみよう
3.5 常につまずきに敏感でいよう

第4章 どこにフィードバックしたらいいか分からない

4.1 フィードバック窓口を調べよう
4.2 ユーザーコミュニティと開発者コミュニティ、どちらに投稿するべきか
4.3 フィードバックのエスカレーション
4.4 誰の問題を解決したいか、という観点で投稿先が変わる
4.5 イシュートラッカーの使い方
4.6 「開発者」としてソフトウェアの改善・問題解決に関わろう

第5章 どう報告すればいいのか分からない

5.1 報告に欠かせない3つの基本要素
5.2 再現条件をまとめよう
5.3 後退バグを報告しよう

第6章 英語での報告の仕方が分からない

6.1 むしろ英語の文を書きすぎない方がいい!?
6.2 「日本語の文章を英語に変換する」のではなく、「同じことを説明する英語の文章を作る」と考えよう
6.3 平易に言い換えてみよう
6.4 主語を意識して「SVOの平叙文」で考えよう
6.5 ありふれた動詞や形容詞を使おう
6.6 困ったときは箇条書きにしよう
6.7 自信が無ければ英和翻訳にかけてみよう
6.8 つたなくても格好悪くても、伝えた者勝ち!

第7章 それでもためらってしまうあなたへ

7.1 重複する報告、していいんです
7.2 場違いな報告、していいんです
7.3 報告や提案は、却下されてもいいんです
7.4 「対案」無しでも報告・提案していいんです

第8章 プルリクエストしてみたい!

8.1 初めてのプルリクエストで気をつけたいこと
8.2 プルリクエストのテーマはひとつに絞ろう
8.3 テストを直してみよう
8.4 ダーティなハックをそのまま提案するのはやめよう

第9章 他の人のフィードバックから学ぼう

9.1 初回使用時のつまずきを減らす提案
9.2 画面上の表示に関わる問題の、より分かりやすい説明
9.3 リリースマネジメントの不備の指摘
9.4 日本語圏に特有の問題の報告
9.5 プロジェクトオーナーが把握していない使い方への対応
9.6 プロジェクトオーナーの普段の作業環境と異なる作業環境への対応

第10章 要望が通らない!

10.1 問題を解消してもらえない場合もある
10.2 要望や報告が却下される理由
10.3 要望が通らなくても、熱くならないようにしよう
10.4 反論・抗弁するときに気をつけること

第11章 プルリクエストをマージしてもらえない!

11.1 既存のコードをよく読もう
11.2 コード以外の部分も「馴染む」プルリクエストにしよう
11.3 他の事例紹介からも学ぼう
11.4 何をしても駄目なときは

第12章 仕事が忙しくてOSS活動に時間を割けない!

12.1 企業とOSSの健全な関係って?
12.2 フィードバックしないと損をする!
12.3 さらに先のことを見据えたフィードバック
12.4 リスクを最小化して、メリットを享受するために

第13章 バグ報告やパッチ提供以外の形でのOSS開発への参加

13.1 翻訳への参加
13.2 Wikiの内容のメンテナンス
13.3 いわゆる「雑用」の負担軽減

第14章 ライセンスについてより正確に知る

14.1 コードと著作権
14.2 オープンソースの定義って?
14.3 コピーレフト型のライセンスで気をつけること
14.4 オープンソースと自由なソフトウェア

おわりに

はじめに

 「#駆け出しエンジニアと繋がりたい」というハッシュタグを巡って、初級者と中・上級者の間で断絶が起こっています。

 「技術的な知見を身に着けて成長したいけど、どこから取り組めばいいか分からないので、同じ悩みを抱える人同士で連帯したい」という人達がいる一方で、ベテランの方々は「駆け出し同士で繋がっても意味なくない?」と冷めた見方をしている、そんな構図であるように筆者には見えています。

 

 世の中に無数にある「OSS開発の現場」には、先達の助けを得ながら実際の世界を少しずつ良くしていくという体験があり、「駆け出しエンジニア」というレベルから脱して中・上級者になる道がある、と筆者は考えています。

 ですが、「OSS開発には誰でも参加できる」とはよく言われるものの、実際に参加している人は少数派です。OSSプロジェクト側は門戸を開いているつもりなのですが、その門をくぐって「OSSを使う人」から「OSS開発に関わる人」になるためには、なかなか越えられない心理的なハードルがあるようです。

 そのようなハードルを取り払い、OSSを使うだけの立場から一歩先に進んで、「OSS開発に参加して改善に協力する」「OSSへ有意義なフィードバック1をする」側、いわゆるコントリビューター2になるための方法や考え方を紹介しよう、というのが本書のコンセプトです。GitHub公式の「Open Source Guides」の、コントリビュートの仕方の案内と同じ領域を、より実践的に語った感じといえるでしょう。

 

 本書は「フィードバックするための準備」に焦点を当てた第1~4章、「最初のフィードバック」に焦点を当てた第5~9章、「フィードバックした後のこと」に焦点を当てた第10~14章の3つのパートで構成されています。対象読者としては、次に挙げるような人に役立ててもらうことを想定しています。

 ・したい提案、解決したい問題があるが、どう伝えればいいか分からずためらっている。

 ・特に具体的なフィードバックがあるわけではないが、好きなOSSがあってそれに関わりたい、何か力になりたいと思っている。

 ・最新のツールやライブラリーを使って製品やサービスを作りたい。「最新版」を不具合を恐れずに使えるようになりたい。

 ・技術者として学びを得て成長したい。分かりやすい成果を出して一旗揚げたい。

 「Gitの使い方」「GitHubの使い方」のような特定のツール・サービスの使い方、コーディング上のテクニックなど、個別の具体的な話は本書では基本的に省略して、参考資料を適宜紹介するだけに留めています。言い換えると、本書は「ツールの使い方は分かったけど、いつどこで使えばいいかが分からない」という人向けのコンテンツと言えます。

 

 本書の内容は、OSS開発に関わる人を継続的に増やそうという取り組みであるOSS Gateの一環の「OSS Gate東京ワークショップ」において、サポーターとして参加する中で見聞きしたことや、寄せられた質問に対して答えた内容に基づいています。

 ・https://oss-gate.github.io/

 OSS Gateワークショップは、「OSSへのフィードバック経験が豊富な人の助けを得ながら、仲間と一緒に、初めてのフィードバックを実際にやってみる」イベントです。東京、京都、大阪、広島、札幌の各エリアで現地の有志による開催実績があり、全体では2016年から2020年3月までの間で計70回近く開催されてきました。

 開催形態の性質上、本書の初版リリースに前後して騒がれ始めた新型コロナウィルスの感染拡大につながりかねないため、2020年4月現在は定期開催は難しくなってしまいましたが、開催時にはぜひ足を運んでみてください。また、初めてのフィードバックを実際にやって自信が付いたら、次の回ではサポーターとして参加して、後進の人の手助けをしてみて頂ければ幸いです。

 本書によってOSSへのフィードバックに挑戦する人が増えて、世の中の問題がひとつでも多く解決されることに繋がってくれれば、なによりです。

1. 障害を報告したり、要望を伝えたり、パッチやプルリクエストの形でコードを提供したりすること。

2. フィードバックを通じてプロジェクトに協力する人のこと。直訳すると「貢献者」ですが、それだと「滅私奉公」のような仰々しいイメージを持つ人もいるかと思いますので、本書ではカタカナ語でこのように表記することにします。

第1章 本当に「誰でもできる」の?

1.1 どんな人ならOSSに関われる?

どんな人が実際に関わってるの?

 「OSS開発者」や「OSSコントリビューター」と聞いて、皆さんはどんなイメージを持つでしょうか?

 ・世界を相手に実力一本で渡り合う凄腕の、いわゆる「つよいエンジニア」

 ・難しい英語で丁々発止の議論のできるマルチリンガル

 ・お客さんからの無茶振りに悩まされるなんて苦労とは無縁

 ・自宅やカフェからMacBookで悠々自適のリモートワーク

 ・転職市場では引く手あまたでオファー殺到

 2019年8月には、とある日本人が個人で開発したOSSがイスラエルのセキュリティ企業の目に留まり、買収された上で作者自身もその専任担当者として雇用されるに至った1、という話が話題になりました。

 そこまで劇的でなくとも、OSSプロジェクトでの活動がきっかけとなって有名企業に転職された方は筆者の周囲にも何人もいます。「GitHub上での活動を実績のアピールに繋げよう」という打ち出し方をしている転職サービス2すらあります。

 こういった話を聞けば聞くほど、気が遠くなる。「OSSを使うだけの名もないエンジニア」の自分には無縁の、遠くかけ離れた世界、雲の上の憧れの世界だ……。そんな風に思ってしまう人もいるんじゃないでしょうか。

 

 安心してください。実際の所、OSS開発者・コントリビューターのみんながみんなそういう生き方をしているわけではありません。大多数の人はむしろ「どこにでもいるような普通の人達」です

 SI業界で働きながらOSSに関わっている人もいれば、Webサービスやソフトウェア開発とは無縁の業界にいながら趣味でやっている人もいます。かくいう筆者も、従業員10人未満の零細企業に所属して、毎朝雑居ビルの一室にある事務所に出勤してWindows PCに電源を入れ、お客さんからの問い合わせメールに回答しつつアサインされた案件の開発をこなし、夜になったら帰宅するという、ごく普通のサラリーマン生活を送っている「OSS開発者」の一人です。

図1.1: スポットライトが当たるのはごく一部だけ

 ただ、働き方や仕事の内容・ライフスタイルなどは様々でも、OSSに関わる人には共通する「すごさ」があると筆者は考えています。それは、問題の根本的な解決を図りたいと思っていて、そしてその想いを実現するために行動している、という点です。

僕たちは根本的な解決を図りたい

 OSSを使っていて問題に遭遇したとき、「不具合に遭遇した……どうやって回避しよう」と思う人は少なくないでしょう。

 でも、ちょっと待ってください。回避策とは本来、問題を根本的には解決できないときの次善の策のはずです。根本的に解決できるなら、それに越したことはないですよね。

 真っ先に回避策を採りたくなるのには、色々な理由があると思います。

 ・未知のことに挑戦するのが恐ろしい。

 ・納期が厳しいのに、失敗したら時間を無駄にしてしまう。

 ・素人が関わると逆に迷惑をかけてしまう気がする。

 ・プロの仕事に文句を付けるなんて失礼な気がする。

 ・問題の解決はプロジェクトオーナーの責任だと思う。

 でも、突き詰めて考えると、これらのためらいの根っこには、自分がそこに関わっていいと思っていないという認識があるのではないでしょうか。

 少なくとも筆者はそうでした。自分はただのユーザーで、そのOSSを作っているのはすごい人達だ。ユーザーの自分は使うだけで、直すのはすごい人達の領分だ。ただのユーザーに過ぎない自分には、すごい人達のようなことはできない。無意識のうちにそう考えていました。

 

 ですが、先に述べたとおり、今OSSの開発に関わっている人達も多くは「普通の人達」です。しかも、OSSは多くのプロプライエタリ3な製品とは違ってソースコードが手に入ります。さらに、「フィードバックはこちらへどうぞ」と案内してすらいますので、「文句を言ったら失礼かも……」などと忖度する必要もありません。必要な物は揃っていますし、許可だってしてくれているのですから、自分にも、あなたにも、やってやれないということは無いはずです。

 そこで勇気を持って、そのOSS自体を修正して成果を還元したり、情報を提供したり、といった行動を取ること。それが「OSSへのフィードバック」の実態です。問題を根本的に解決するために最適な行動を取ったら、結果としてOSSへのフィードバックとなっていたという、ただそれだけのことなのです。

 大丈夫、有用なフィードバックを行うための能力は後から付いてきます。必要なのは、最初の一歩を踏み出そうという思い切りだけです。

1.2 OSSにフィードバックすると何が嬉しいの?

実利的なメリットもたくさんある

 理想論には興味がない、現実的なことにだけ関心がある、という方もいらっしゃるでしょう。

 本書は基本的に、「OSSにフィードバックしてみたい」という動機をすでに持っている方を想定して書かれています。しかし、「会社で奨励されているのでとりあえずやってみようとしている」というようなケースでは、それほど強い動機がない場合もあります。そういう方のために、「問題が解決されること」以外の、OSSにフィードバックすることのメリットを改めて列挙してみます。

 

 個人としてOSSに関わることのメリットで、まず一番分かりやすいのは、「すごい人だ」と思ってもらえるという点でしょうか。

 実際にやったフィードバックの内容はそれほど高度でないとしても、「OSS開発者」「OSS開発に関わった」というだけで「よく分からんが、何だかすごそうだ」と思ってくれる人はまだまだいらっしゃるようです。ハッタリだとしても、それが仕事を任されるきっかけになることもあれば、自分自身にとっても新しいことに挑戦する自信になるでしょう。

 ……というのは半分くらい冗談ですが、「ちゃんと技術が分かる人」「優秀なITエンジニア」からの信用を得やすいということは実際あります。

 実績が見えないのになぜかITイベントでの登壇が多い有名な人を揶揄する「IT芸人」なんて言い方がありますが、OSSにフィードバックしたという事実は間違いなく「目に見える実績」ですし、その内容からは後述するような様々な情報を読み取れます。「この人は口先だけじゃない」と信用してもらえる材料を積み重ねる手段として、OSSへのフィードバックは非常に有効です。

 

 口先だけではない実力とはどういうものを言うか。たとえば、OSSへのフィードバックを重ねると、仕事の上で必要になるものと共通の技能が身につきます。「修正作業の中でプログラミング・コーディングの技術力」は勿論のこと、単に障害を報告するだけでも「伝わりやすい報告の書き方」「問題の再現手順を絞り込むための切り分け・調査能力」「要望する変更の必要性を説明する力」「判断材料を示して相手を説得する交渉力」など、IT業界で必要となる対人コミュニケーションの様々なスキルが磨かれます。

 そうしてOSS開発の世界で実績を積み上げていると、それを見て声をかけてくれる人が現れることもあります4。いわゆる「リファラル採用」というやつですね。

 

 問題の解消に取り組むことは、未知の・新しいことに挑戦するきっかけにもなります。筆者自身、自分がユーザーとしてOSSを使っていて障害に悩まされた場面で、どうしてもその障害を解消しないといけなかったため、そのOSSの問題箇所を調べて修正することを試みて、その中で今まで避けていた言語やライブラリーの使い方を習得した、ということが何度かあります。

 業務では触ることが無い技術に触れる機会にもなるので、会社で言われた仕事をしているだけよりも、幅広い知識が身に付いて成長できると言えるでしょう。

 別の角度から見ると、たくさんフィードバックの機会があるということ自体が、自身の挑戦の多さのバロメーターになるとも言えます。

 一般に、OSSは新しい物・まだあまり多くの人に使われていない物ほど、機能が不足していがちで、未修正の不具合が残っていがち、ドキュメントの整備も後回しになっていがちです。そういう物を使おうとすると何をしてもつまずくため、それらの問題を解決して回るために必然的にフィードバックの機会が増えます。筆者は、フィードバックを長い間していないと「ああ、最近全然新しいことやってないんだなあ」「知ってることの範囲でだけ作業してるなあ」と自分自身の停滞に間接的に気付かされる感覚があります。

 他の人の後追いばかりしていたり、すでに整備された道だけを進んでいたりすると、つまずいてフィードバックするという機会に恵まれにくくなります。勇気を出して、他の人がまだしていないことにぜひとも挑戦してみてください。

現実の問題を解決できることを楽しもう

 OSSへのフィードバックの実利的なメリットを色々と挙げてみました。とはいえ、それらはあくまで副次的なものに過ぎない、というのが筆者の考えです。

 これらだけがすべての価値だと考えてしまうと、「目立つ大きなプロジェクトでなければ、関わる意味がない」「目立つ大きなプロジェクトに関われないのでは、やる意味がない」ということになってしまい、最初の一歩を踏み出しにくくなってしまいます。

 そうではなく、OSSへのフィードバックの本質的な価値は、些細な物から大きな物まで、さまざまな現実の問題の解決に関われることそのものにあります。

 成熟して完成度が高まり分業化が進んだ社会や企業では、自分に任された職務の範囲のことしかさせてもらえず、その範囲を逸脱すると「余計な口出しをするな」「自分のことだけやれ」と咎められてしまう、ということが多いのではないでしょうか。

 それに対して、立場の垣根を越えて、問題に気が付いた人が、普段の職務の範囲を超えて問題の解決に取り組むことができる。越境して解決してくれる人の登場が望まれる。バザール方式5のOSSプロジェクトは、「口出ししあう」ことで成り立つ場だと言えます。

 

 何かの行動を継続するには、それに対する報酬が細かくあった方がいい、という話があります。ゲームでは「アイテムを手に入れた」「レベルが上がった」といった報酬が適宜示されるようになっています。でも現実ではそんな報酬の提示は滅多にないから、人はゲームにのめり込んでしまうのが当たり前なんだ、という話を聞いたことがあります。

 OSSへのフィードバックも、それに似ているかもしれません。問題が解決されれば「この問題は解決済み」「このプルリクエストはマージ済み」と印が付く、そういう「実績」を日々得たくて自分のために関わる。そういう関わり方でも全然いいんです。

1.3 「つよいエンジニア」になるために本当に必要なもの

遭遇した問題に立ち向かう、最初の一人になろう

 OSSへのフィードバックは誰でも挑戦できるということ、やると様々なメリットがあるということを、ここまでで述べてきました。改めて言われなくても、そんなこと当然知ってるよ! それができれば苦労はないんだよ! と思われたかもしれません。

 多くの人は、未知のことに対して「やらない理由」「自分が動かないで済む理由」を探すのに長けているものです。それは半ば本能的なもので、筆者自身も、強く意識し続けていなければついついそちらに流れてしまうという自覚があります。

 とある技術イベントの基調講演では、「何年間も解決されてこなかった問題を解決するために本当に必要だったのは、知識や技術力ではなく、問題に向き合うことだった」と話が結ばれていました6

 世界を少しでも良い方向に変えるために、問題から逃げずに立ち向かうこと。問題を根本的な所で解決したいと思い、実際に解決まで導くこと。意志の力でそのような選択ができること。それが希有なことだからこそ、OSS開発者・コントリビューターは尊敬される。「つよいエンジニア」とはそういう人のことを言うのではないかと筆者は考えています。

問題への立ち向かい方を知ろう

 とはいうものの、何の準備も後ろ盾もなく完全な手探りで問題に立ち向かうのはあまり現実的ではありません。もしあなたが時間をもてあましているなら、がむしゃらにいろいろ挑戦してみるのも学びが多くていいのですが、現代人は忙しいのでなかなかそうもいきません。

 そういうわけで、「すでに問題に立ち向かっている人達」のやり方を真似て実践してみよう、というのが本書の趣旨となります。

 どんなOSSプロジェクトにどんなフィードバックをしたいかは、人によって異なります。開発言語も開発スタイルもプロジェクトごとに全く異なるでしょう。また、「はじめに」で紹介したOSS Gateワークショップに参加された方の多くは、純粋に技術的な知識は充分にあるのに、対人コミュニケーションの面での不安がネックになっている様子でした。

 なので以降の章では、具体的なコーディングのような部分にまで踏み込んでの解説はなるべくせずに、それ以外の「OSSプロジェクトの開発者の人達とのコミュニケーションの取り方」「どんなOSSでも一般的に言えること」に焦点を当てて語るようにしています。基本的には執筆時点での情勢に合わせてはいますが、本質的には時代の変化・道具の変化に左右されない内容となっているのではないかと思います。

 

 彼を知り己を知れば百戦殆( あや)うからず。それでは、ここから先は日々OSS開発に関わっている人達の目線になって、OSSへのコントリビューション、特にフィードバックの仕方の実際のところを見ていきましょう。

1. オープンソース界隈を震撼させた、Trivy買収の舞台裏 ~ オープンソースを成功させるためにできること~|OPENSOURCE.TOKYO  https://opensource.tokyo/n/nc96669b27365

2. Findy  https://findy-code.io/

3. 「proprietary」は「占有権のある」という意味で、「誰でも自由に使えて改変もできる物」と対置して使われる形容詞です。ソフトウェアの場合、DRM(Digital Rights Management:デジタル著作権管理)のような技術的手段や、エンドユーザーライセンスの条件のような法的手段によって、改変・再利用を禁止している物を「プロプライエタリソフトウェア」と呼びます。

4. よほど目立った実績がある場合には「うちに来てほしい」と企業側から勧誘される場合もあるようですが、そうでないなら、「ただいま求職中です」のような声を上げたときに声をかけてもらえるといった温度感のようです。まだそれほど実績がないのに転職エージェントから声がかかるケースは、あまり実績を見ずに声をかけていることがあるので、浮かれすぎないように注意しましょう……

5. エリック・レイモンド著「伽藍とバザール」( https://cruel.org/freeware/cathedral.html )で名付けられた概念で、個人商店が集まって形成される市場(いちば)のように、大勢の人が勝手気儘にソフトウェア開発に参加する開発スタイルのこと。この反対にある、伽藍などの大規模建造物の建築計画のように、スケジュールを切って開発を進める従来型の開発スタイルのことを、同書では「伽藍方式」と称しています。なお、OSSプロジェクトであるかどうかとバザール方式かどうかは無関係であることに注意が必要です。本書の内容は、バザール方式のOSSプロジェクトへフィードバックする場面を想定して書かれています。

6. PHPカンファレンス関西2016で基調講演してきました - Mercari Engineering Blog  https://tech.mercari.com/entry/2016/07/20/160602

第2章 OSSを探そう

 OSSにフィードバックするということは、当たり前ですが、フィードバック先のOSSが必要です。

 本章では、フィードバック先を思いつけない人のために、無理のないフィードバック先OSSの見つけ方を紹介します。すでに「このOSSにフィードバックしたい」という対象が決まっている、またはフィードバックしたい対象がOSSと分かっている場合、この章は斜め読みで飛ばしてもらってもおおむね問題ないです。

2.1 身のまわりにたくさんあるOSS

 OSS Gateワークショップに来られた方に「フィードバックしたいOSSはありますか?」と聞くと、「Linuxカーネル」や「Docker」などの著名プロジェクトを挙げられることがよくあります。

 もちろん、本当にLinuxカーネルをガッツリ読んでパッチを書きたい人もいるとは思うのですが、単に「OSSと言われてそれらの有名なプロジェクトくらいしか思い浮かばなかった」と見受けられるケースでは、筆者はなるべくもっと身近な・小規模のOSSへのフィードバックから始めるようお薦めしています1

 「身近なOSS」なんて思いつかない、という人でも、普段の仕事で使うアプリケーションやコマンドを作業の順番に従って思い浮かべてみると、恐らくOSSがいくつも見つかるはずです。たとえば以下の要領です。

 ・インターネット上の情報を調べるためにChromeを起動した。

  ─ChromeのベースとなっているChromiumはOSSです。

  ─Chromiumが依存しているcrc32c、dom-distiller-js、enum34などの多数のライブラリー( chrome://credits/ で確認できます)もOSSです。

  ─Chromiumで使える拡張機能にもOSSが多くあります。

 ・作業を始めるために、ターミナルを起動して、Bashの上でgit cloneを実行した。

  ─GitはOSSです。

  ─BashもOSSです。

 ・Ruby on Railsで構築されたサービスのユニットテストを走らせるため、bundle installしてrake testした。

  ─Ruby on RailsはOSSです。

  ─RubyもOSSです。

  ─Gemfileに従ってbundle installでインストールされる多くのGemもOSSです。

  ─bundleコマンドを提供するBundlerもOSSです。

  ─rakeコマンドを提供するRakeもOSSです。

 ・ソースコードを編集するためにVisual Studio Codeを起動した。

  ─VSCodeはOSSです2

  ─VSCodeのベースになっているElectronもOSSです。

  ─ElectronのベースになっているChromiumもOSSです。

  ─VSCodeで使えるプラグインにもOSSが多くあります。

 ・Vue.jsで構築されたフロントエンドにファイルを追加し、ESLintでエラーがないことを確かめて、Babelでトランスパイルした。

  ─Vue.jsはOSSです。

  ─ESLintもOSSです。

  ─BabelもOSSです。

  ─ESLintやBabelのpackage.jsonに従ってインストールされた多くのNPMモジュールもOSSです。

 こうして見てみると、開発に使用しているフレームワーク自体ツールがOSSであったり、また、有名なOSSも名前を聞いたことのないような無数のOSSを利用して作られていたり、という状況であることが分かります。現代のソフトウェア開発の現場では、OSSを全く使わずにいられることはあまりないでしょう。

試し読みはここまでです。
この続きは、製品版でお楽しみください。