2024 年のオープンソースに対する決意 - 何を変える必要があるか?

過去数年間で、オープンソースはますます二極化してきました。一方では、オープン ソース イニシアチブ (OSI) のオープン ソースの定義に熱心に取り組んでいる人々がいます。その一方で、OSI の承認を受けていないライセンスに移行した商用オープンソース ベンダーも複数あります。

これは 2024 年のオープンソースにとって何を意味しますか?オープンソース コミュニティはどのようにしてその立場を守り、オープンソース ソフトウェアが新しいソフトウェア プロジェクトの最初の選択肢であり続けることを保証できるでしょうか?

解決策 #1: オープンソースに対する信頼が失われています。クリティカルマスを獲得し、コミュニティを成長させ、潜在的な顧客ベースをより効率的に開発するために、企業がオープンソースライセンスの下でソフトウェアをリリースすることを修正する必要があります。しかし、その後、競合他社が同じソフトウェアを使用して、自社と競合する独自の製品やサービスを構築していることがわかります。オープンソースの大手企業の多くは、自社の市場シェアを保護し、競合他社を防ぐために、非オープンソース ライセンスに移行しています。しかし、それらはオープンソース全体の評判も傷つけました。これらのベンダーは、コミュニティ、市場へのリーチ、開発者へのアクセスに関してオープンソースが提供する利点を望んでいますが、コントロールを放棄したくなく、競合他社を締め出したいと考えています。

オープンソースを信じている私たちにとって、これは苦痛です。オープンソース ソフトウェアが価値があるのは、それがサポートするコミュニティ アプローチと、ソフトウェアを選択する開発者の手に制御が保持されるためです。コミュニティ開発とソフトウェアへのアクセスの基盤としてのオープンソースへの信頼がなければ、誰もが損をします。

その答えは、単一の企業ではなくコミュニティのニーズを反映した、オープンソースへのさらなるアプローチが必要であるということです。私たちは、どんな犠牲を払ってでも成長を求め、その後に IPO や買収を行うベンチャーキャピタルの資金調達モデルから距離を置く必要があります。オープンソース財団は、コミュニティと関係するすべてのメンバーのニーズを代表しています。クリティカルマスに達すると、プロジェクトの管理者として機能し、コミュニティをより効果的に代表できるようになります。

個々の企業は、自社のビジネス ニーズに合わせて、オープンソース コミュニティの管理方法や貢献方法を改善することもできます。 Confluent や DataStax などの企業は、コミュニティによって管理され、コミュニティのために管理されるオープンソース プロジェクトと、顧客向けの製品を分離する方法の成功例です。 2024 年には、より多くのオープンソース企業が彼らに倣い、ビジネス モデルとコミュニティ サポートを別々の目標として扱うのではなく、両方を一緒に構築する必要があるでしょう。

解決策 #2: オープンソースの定義へのアプローチについて話し合わなければなりませんここ数年、クラウド コンピューティングの出現前にまとめられたオープン ソースの定義 (OSD) を進化させるよう求める声が多くありました。サービスのプロバイダー。

Server Side Public License (SSPL) や Elastic License などのライセンスを使用している企業は、コミュニティに利益を返さない競合他社にプロジェクトを悪用されるのではなく、自社のプロジェクトを保護し、存続可能性を維持していると主張しています。オープンソースでは、マルウェア作成者やその他の悪者がコミュニティによって開発されたソフトウェアから利益を得られるため、これらのプロジェクトを潜在的に使用できる人を制限する必要があると主張する人もいます。これらの議論にはいくつかの良い点もありますが、誰もがプロジェクトに必要に応じてソフトウェアを使用できるべきであるというオープンソースの基本的な精神に反しています。

しかし、オープンソースはいつまでも立ち止まっているわけにはいきません。数十年前に、フリーおよびオープンソース ソフトウェア愛好家の小規模ながら団結したグループの活動に基づいて始まったものは、異なるニーズと異なるビジョンを持つ複数のグループに成長し、進化しました。倫理的または非競争的制限のあるソース利用可能ライセンスの支持者は、ソース コードにアクセスできず、他のこともできなくなるプロプライエタリ ソフトウェアと同じグループに自分たちをみなしていません。

OSD は、何がオープンソースとみなされるのか、何がそうでないのかを明確に示します。しかし、実際には利用可能な選択肢はもっとたくさんあるのですが、これを 2 つの陣営が対立していると見るのは簡単です。 BSD ライセンスに基づいてライセンスされたソフトウェアで実際にできることは、AGPL 3.0 と比べて大きな違いがあります。これらのライセンスにはそれぞれ理由があって存在します。違いは、オープンソースはソフトウェアへの無料アクセス以上のものであるということですが、それはそれを使用する多くの人にとって大きなプラスポイントです。代わりに、重要なのはコントロールです。

オープンソースとは、単に特定のソフトウェアに使用されるライセンスをはるかに超えたものでなければなりません。それはコミュニティ、プロジェクトの将来のためのガバナンス モデル、そしてプロジェクトが長期にわたって生み出すことができる価値に関するものです。ただし、ライセンスは、そのソフトウェアの使用方法を制御するものです。オープンソースの将来に関するこのオープンで率直な議論がなければ、そもそもオープンソースについて非常に重要なものを失う危険があります。強力なオープンソース コミュニティがなければ、ソフトウェアでできることとできないことの制御をベンダーに渡してしまう危険があります。

解決策 #3 - 良いことも悪いことも含めて、プロジェクトの将来についてもっと真剣に考えなければなりませんテクノロジー業界では常に変化が起こっていますが、次の大きな飛躍がどこで起こるかを予測するのは困難です。たとえば、ChatGPT が立ち上げられ、生成 AI が大きな関心を集めるまで、AI は数十年前から存在していました。外部の観察者にとっては、何も起こっていないように見えたかもしれませんが、その後、すべてが変わりました。卵の中で育つ鶏のように、勃発の瞬間までには多くのことが起こり、多くの展開や誤ったスタートがありました。

これはオープンソースにとって何を意味するのでしょうか?それは、市場で起こっている大きな変化に対応し、市場で他に何が起こっているかに基づいて、これまでに可能だと考えられていたよりも多くの視聴者に新しいプロジェクトを届けることを意味します。これは、開発者とプロジェクト リーダーが、自分たちと取り組んでいるプロジェクトに何が起こるかを理解する必要があることを意味します。

同時に、多くのオープンソース プロジェクトは、本来あるべき影響を与えていないか、支持されなくなっています。 Sonatype の調査によると、作成者やコミュニティによって「積極的に保守」されているオープンソース プロジェクトはわずか11%であり、これは前年比 18% の増加に相当します。開発者は、ソース コードに制御を移譲し、別の人にプロジェクトのリーダーシップを引き継がせることを検討すべきでしょうか?企業や個人がコストをカバーするのに十分な収益を上げられない場合、どのようにして連盟や財団が引き継ぐことができるのでしょうか?そして、まだ使用されているものの、積極的にメンテナンスされていない古いプロジェクトはどうなるのでしょうか?

オープンソースの持続可能性について語るには、商業市場の機会はないかもしれないが、時間をかけてサポートする必要があるプロジェクトについて考えることが含まれます。これらは他のソフトウェア ツールやオペレーティング システムに組み込まれている可能性があり、実行可能な場合は世話をし、実行できない場合は置き換える必要があります。最後の解決策は、2024 年中にどこに参加して、これらの取り組みに貢献者やメンテナーをサポートできるかを考えることです。