オープンソースソフトウェアとは何を意味するのか？他の人に説明する必要がある時、オープンソースの価値と本質をどのように手軽かつ効率的に伝えるか？オープンソースという言葉が1997年に初めて提唱されて以来、業界はオープンソースに関して多くの得難い経験と教訓を得ており、これらの経験と教訓を忘れるべきではありません。
そのために、私は12の文化的遺伝子を収集しました。私の考えでは、それらは歴史を共有し、舞台を設置し、オープンソースの定義とそれがソフトウェア業界全体に持つ意味に文脈を提供するのに役立ちます。
最初のいくつかの文化的遺伝子はソフトウェアの構築に関係しています。私は、それらが成功したオープンソースプロジェクトと見なされるものを定義していると考えています。なぜなら、それらはソフトウェア自体に関わる基本的な側面だからです。これらの文化的遺伝子を理解しているプロジェクトだけが成功します。寛容なライセンスを採用し、コミュニティを重視するソフトウェアは、優れたソフトウェアを構築・維持するための最も優れた、最も効率的なソフトウェア再利用メカニズムであるかもしれません。
第一の文化的遺伝子：私たちはソフトウェアを書き始めて以来、ソフトウェアを共有してきました。
1950年代後半、IBMはコンピュータ会議を開始しました。この会議は今日まで続き、SHAREと呼ばれています。DECは60年代に開始し、DECUSコミュニティをサポートしました。その会議では、他の人が書いて貢献したソフトウェアが入ったテープを購入できました。USENIXは70年代に起源を持ち、当時はテープを使用して初期のUNIXバージョンをリリースしていました。しかし、この共有の慣行は40年代のプリンストン高等研究所の最初のプログラム可能コンピュータでの開発作業にまで遡ることができます。
第二の文化的遺伝子：優れたソフトウェアを書くことは困難な作業です。
私は、共有がこの単純な現実に帰着すると考えています：優れたソフトウェアを書くことは困難です。ソフトウェア開発分野には2つの大きな比率があります：開発者が1日平均で書くことができるコード行数、合理的な開発プロセスから生じる1000行あたりのバグ数。言語の進化からアーキテクチャの再利用まで、ソフトウェアのすべての進歩は、より少ないコード行でより多くのより優れたソフトウェアを書くという中心思想を中心に展開しています。ソフトウェア構築の信頼性、構成管理、レビューツールとプロセス、テストの進歩はすべて、合理的なソフトウェアデリバリープロセスから生じるバグ数を減らすことを目的としています。
第三の文化的遺伝子：無秩序なスケーリングはありません。
優れたソフトウェアを書くには規律が必要です。成功した製品やオープンソースプロジェクトとしてのソフトウェアを見ると、構築時に通常、ピアレビューが行われ、バージョン管理と構成管理が実施され、ビルド自動化とテストフレームワークがソフトウェアと共に完備されています。レビュー、構成管理、ビルドとテストの自動化がなければ、ソフトウェアはユーザーコミュニティ内でスケールできず、製品としても何千ものユーザーの間でスケールできません。ソフトウェアを維持する必要があるコアチームは、「ソフトウェアは何を実行するか」という質問に答えることができなければなりません。
リーナスの法則は、「十分な注目があれば、すべてのコードバグが表面化する」と大まかに表現できます。私は、これが実際にはコミットレビュープロセスの重要性を示していると考えています。研究によると、レビュー段階で発見されるバグはテスト段階で発見されるものよりも多いことが示されています。健全なコミュニティは、コードチェックイン(check-in)において厳格なレビュープロセスを持っているはずです。
第四の文化的遺伝子：ソフトウェアは本質的に動的です。
プログラムは使用によって改善されます。バグが発見されたら修正されます。新しい用途が発見され、新機能が推進されます。プログラムは絶えず磨かれ、強化されます。プログラムはある環境から別の環境に移植されます。残念ながら、著作権は1980年にソフトウェアリリースパイプラインを「保護」するメカニズムとなりました。人々はソフトウェアの進化がどれほど速いか、派生版の開発がどれほど速いかを理解していないかもしれませんし、IoTとWorld Wide Webの出現後、この動的性質がさらに加速することを理解していないかもしれません。私たちが共有するネットワーク帯域幅は、テープサイズのポケット、会議スケジュール、雑誌出版の遅延から、24時間365日のリアルタイムグローバルビルド、リリース、メンテナンスへと変わりました。
オープンソースソフトウェアのコミュニティ側面に関連するいくつかの文化的遺伝子を見てみましょう。
第五の文化的遺伝子：あなたが得るものは常に与えるものより多いです。
これはコミュニティ協調開発の経済効率です。継続的な貢献はプロジェクトソフトウェアの発展の生命線と言えます。貢献者がコードを貢献したり修正版を提供したりすることには大きなリスクはありませんが、得られるメリットは、ソフトウェア全体を貢献者が適切と考える方法で使用できることです。通りがかりの貢献に関しては、これが開発者が与える唯一の重要な貢献である可能性があり、彼らの経験と専門知識に関係ありません。
得られる見返りが貢献より大きいことは、個人にも会社にも当てはまります。Red Hat、Intel、IBMなどの大企業からの専用リソースと投資により、彼らはLinuxオペレーティングシステム全体を活用して異なるビジネス戦略を実行できます。会社は優れたソフトウェアプロジェクトを顧客の問題を解決する製品に変えることができます。
第六の文化的遺伝子：ただ乗りする人がいることは成功の鍵です。
巷では、オープンソースプロジェクトのユーザー1000人ごとに、100人がソフトウェアのバグを報告し、そのうち10人が潜在的な修正版を貢献し、そのうち1人だけが貢献ガイドラインを注意深く読むと言われています。実際、コミュニティが成功するには3つの道があります（コミュニティの成功はコード貢献で測定されます）。1つは、プロジェクトが多くのユーザーを獲得するために、ソフトウェアが異常にインストールと使用が容易である必要があります。2つ目は、ユーザーベースの中に開発者がいることです。ソフトウェアは、変更したい開発者（自分の利益のために）が簡単に変更できるように、異常にビルドとテストが容易である必要があります。3つ目は、貢献が絶え間なく続くように、プロジェクトに変更を貢献し返すことが異常に容易である必要があります。ただ乗りする人が多いことは、あなたがうまくやっていることを意味します。このように、ユーザーが多ければ、開発者にとって大きな可能性があり、貢献の可能性も随之生じます。しかし、プロジェクトの責任は容易さを確保することです。
オープンソースプロジェクトを構築しようとする企業は、コミュニティを理解するのに苦労することがよくあります。彼らは、誰かが自分のために何かを提供してくれると考えます。彼らは、コミュニティ（開発者ウェブサイトなど）と協力するのではなく、指示を出すことに慣れています。企業とオープンソースに適用される3つの文化的遺伝子があります。
第七の文化的遺伝子：製品とプロジェクトを混同しないでください。
プロジェクトは実際には、インストールして実行した後、ある問題を解決できる実行可能なソフトウェアのセットです。それはコードで語る協力と交流です。プロジェクトは製品ではないことを理解する必要があります。製品は、顧客の問題を解決することで利益を得るものです。多くの優れたソフトウェアは、うまく運営され、エンジニアリング技術の作業をいくらか減らすオープンソースプロジェクトから生まれていますが、それを顧客にとって問題を解決する製品にするには、まだ困難な作業が必要です。例えば、Linuxカーネルはプロジェクト、Fedoraはディストリビューションプロジェクトですが、RHELは製品です。製品は、顧客の価値に対する期待を満たすことで利益を得ます。製品はデフォルトでインストール・実行され、保証と賠償が付属し、サービス（サポート、アップグレード、トレーニング、コンサルティング）および特定の製品に関するドキュメントもあります。それらはハードウェアとサービスを含むより大規模な製品ポートフォリオの一部である可能性があります。
この文化的遺伝子の推論は、「誰もあなたのためにあなたの製品を構築してくれない」かもしれません。
第八の文化的遺伝子：顧客とコミュニティを混同しないでください。
第七の文化的遺伝子がエンジニアリング技術とビジネスモデルに関係するなら、第八の文化的遺伝子はメッセージと販売に関係します。コミュニティと顧客の価値観は同じではありません。顧客は問題解決を加速し、リスクを排除するためにお金を払いますが、コミュニティ（およびコミュニティ内の個人）は協力を通じて独自のソリューションを構築します。オープンソースソフトウェアを使用する一部の企業は、プロジェクトコミュニティが製品パイプラインの一部であると考えています。コミュニティフォーラムで顧客を見つけると、さらにそう考えます。彼らは、コミュニティプロジェクトが試してから買うものだとさえ考えるかもしれません。しかし、これらはすべて間違っています。
企業は関連コミュニティとの交流を、有料顧客との交流とは異なる方法で行います。各交流には特定のツールと交戦ルール、記録・考慮すべきメトリクスがあります。コミュニティメンバーは非常に価値がありますが、彼らは顧客ではありません。
第九の文化的遺伝子：オープンソースの定義よりずっと前から、企業は寛容なライセンスのソフトウェアを共有してきました。
Project Athena（X11、Kerberos）は1983年に始まりました。Open Software Foundation（OSF/Motif、OSF/1）は1988年に始まりました。DECとSunは初期のBSDバージョンからそれぞれUltrixとSunOSを開発しました。これは新しい行動ではありません。
最後に、いくつかの文化的遺伝子はオープンソースソフトウェアに関するライセンスと法的議論に関係しています。
第十の文化的遺伝子：ソフトウェアの自由とオープンソースライセンスは異なる議論トピックです。
ソフトウェアの自由とオープンソースソフトウェアについて議論することは、民主主義が資本主義より良いかどうかを議論するようなもの、あるいは言論の自由が自由市場より重要かどうかを議論するようなものです。それら自体は重要な議論であり、人々は特定のトピックに対して自然的な傾向を持っていますが、それらは異なる議論です。ソフトウェアの自由の言語はユーザーの権利によって定義され、オープンソースソフトウェアの言語はライセンスの属性によって定義されます。これらは異なる議論です。
第十一の文化的遺伝子：すべてのオープンソースプロジェクトにはライセンスが必要です。
ライセンスは、他の人がソフトウェアをどのように使用できるかを定義します。ソフトウェアは著作権法で保護されており、OSI承認ライセンスを選択する必要があります。あなたが選択するライセンスは、コミュニティで望む社会的契約を宣言します。近年、多くの人がApacheソフトウェアライセンスを「ビジネスに優しい」ライセンスとしてデフォルトで選択していますが、必ずしもそうではありません。相互ライセンスか随意ライセンスかは、自由ソフトウェアかオープンソースソフトウェアかについて話すことではありません。相互ライセンスは、エコシステムに優しい最良のライセンスかもしれません。
第十二の文化的遺伝子：財団には居場所があります。
非営利組織は、公平な競争環境とIP（知的財産）所有権の中立性を提供し、企業がうまく運営されたオープンソースプロジェクトに専念できるようにします。
結び
1990年代中期から後期、私は同僚と寛容なライセンスソフトウェアを使用してソフトウェア会社を立ち上げました。当時はオープンソースソフトウェアという用語はまだありませんでした。これは実際にはあまり謎ではありませんでした。私たちは約250の異なるライセンスを持つプログラムパッケージ（これらのライセンスにはBerkeleyライセンス、MITライセンス、GPLv2が含まれます）を収集・移植し、独自のソフトウェアと組み合わせ、重要なソフトウェアのいくつかはMicrosoftが所有し、そのライセンスが使用を許可していました。私たちはそれを会社が全面的にサポートする製品に開発し、その製品は自社製品のライセンスを採用しました。私たちは異なる方法でそれらの異なる協力コミュニティに参加しました。エンジニアとビジネス界の人々として、私たちはUNIXシステムコミュニティで成長し、長い協力と共有の歴史の恩恵を受けました。
振り返ってこれらの文化的遺伝子を見ると、20年前に書いたであろう文化的遺伝子と全く同じだと考えています。
あなたはどのような文化的遺伝子を追加しますか？どのような経験がありますか？コメントで交流しましょう。
転載请注明：开发者关系 »
