一部のオープンソースライブラリがバイナリを提供しないのはなぜですか？

一部のオープンソースライブラリがバイナリを提供しないのはなぜですか？一部のプロジェクトは、特にWindowsビルドの場合、ソフトウェアの現在のビルドを維持しているサードパーティに遅れることに気付きました。

図書館の採用の障壁のように思えるので、お願いします。開発者は環境を構築して構築する必要があるため、開発者にとってはより多くの作業です。また、開発者は、ライブラリを誤って構築することでバグが発生することを心配する必要があります。

編集：コメントと回答に対処するためのいくつかの更新。議論の中心ではないので、例を削除しました。また、私の質問を「オープンソースライブラリが提供する傾向がある」ではなく「一部のオープンソースライブラリが提供する」と言い直しました。

Windowsバイナリの作成はまったく異なる仕事であるため、まったく異なる知識ベースとツールセットが必要です。Linux開発者についてこれを理解するのは難しいようです。

• 永遠に思われることのためにWindowsを使用しました。
• Windowsは自宅にのみインストールされています。
• Linuxをあちこちで使用していますが、Linuxの管理や開発ではなく、ユーザーとしてのみ使用しています。
• gccはLinuxで最も一般的に使用されるコンパイラですが、自分のコンピューターにインストールしたことはありません。
• あなたは主にWindows上で自分でソフトウェアに取り組んでいますが、Linuxのバグ修正を他の誰かがそれを互換性のあるものにしてバイナリを配布する仕事をしても構いません。
• すでに持っている誰かが完全にビルドを行う意思がある場合、別のOSやツールチェーンにお金を払いたくありません。

カイロはライブラリであり、アプリケーションではありません。PostgresにはWindowsバイナリがあるようです。小規模なプロジェクトは、インフラストラクチャ/リソースがないため、ビルドを提供しないことがよくあります。

これは、「何かをしたいのなら、シャベルをつかむ」というオープンソースの哲学の一部です。当然、ユーザーが自分でプログラムをコンパイルするだけで、開発者の作業負荷が軽減されます。これらのすべてのアーキテクチャ、OSなどについて心配する必要はありません。

ただし、消費者レベルの製品（Firefox、Paint.NET、Audacity、Keepassなど）を作成していて、ユーザーの獲得に関心がある場合は、常に、常に、常に！ バイナリを含めます。あなたのウェブサイトをつまずき、あなたの製品に興味を持っている人のたった2％だけが、

• 適切なSCMクライアントをダウンロードします
• ソースツリーのコピー全体を確認する
• 必要なIDEまたはコンパイラツールをダウンロードします（一部のプロジェクトでは簡単に数百MB）
• 必要なすべての依存関係をダウンロードしてインストール（および環境変数を設定）
• 新規コンパイルを実行します（一部のプロジェクトで簡単に10分間のプロセス）
• エラーや問題に対処したり、発生したりします（小規模なプロジェクトでは文書化されていない可能性があります。「ああ、最新版は実際にはトランクではなくブランチの書き換えです！」）
• すべてをアンインストールするか、コンピューターにすべて残して、更新のために再コンパイルします。

（明らかにLinuxでは物事は非常に賢明ですが、ほとんどの消費者はまだWindowsを使用しています。）

新規ユーザーにとっては、「Windowsバージョン！ダウンロードして実行」と言う方がはるかに簡単です。

ただし、多くのオープンソースプロジェクトは消費者レベルではありません。彼らは、この種の試練に対してはるかに高い耐性を持つプログラマーをターゲットにしているため、バイナリはDIYです。私の経験では、プログラマーはユーザーと同じくらい怠け者になる可能性がありますので、注意してください。:)

Write Once Compile Anywhere環境（C、C ++など）で記述されたアプリケーションの作成者は、一般的なアーキテクチャ用のバイナリを作成およびパッケージ化するディストリビューター（apt、rpm、yumなど）にコンパイル手順を押し下げることで恩恵を受けます。これにより、作成者の労力を最小限に抑えて最大限の移植性のあるアプリケーションを実現し、コアコンピテンシー（アプリケーションを開発し、複数のアーキテクチャ向けにコンパイルおよびホストするのではなく）に集中できるようになります。一部のWOCAアプリケーション作成者は、Windowsのような特別な場合に追加費用を支払うことをいとわないでしょう。なぜなら、他の誰も期待しないからです。ユーザーはそれを期待し、市場をあきらめたくないからです。

一方、Write Once Run Anywhere環境（Java）または特定のターゲットアーキテクチャ（OS Xアプリケーションなど）で記述されたアプリケーションは、単一のバイナリを提供することができます。一度費用がかかります。

最後に、ユーザーは通常、ソースからビルドするか、OSパッケージマネージャーを使用するかのどちらかで快適であるため、このモデルは使いやすさも向上します。ユーザーは、バイナリ（パッケージマネージャー）の入手先を知っており、一貫したインストールおよびパッケージ管理ライフサイクルエクスペリエンスを持ち、必要な場合にソースを入手する場所を知っています。

とにかく提供しているソースをビルドするのではなく、ビルド（明らかに非常に大きいことがあります）を提供する帯域幅を噛み砕くのはなぜですか？言うまでもなく、自分のマシンでプロジェクトをビルドすると、プラットフォームに合わせてコンパイルされるため、常により良い結果が得られます。

2つの理由が考えられます。

まず、複数の種類のハードウェアで複数のオペレーティングシステムを実行しています。ビルドする必要があるバイナリターゲットの数は管理不能になります。32ビットまたは64ビットのハードウェアで実行されているWindowsの3つのバージョン（XP、Vista、7）がまだ一般的に使用されています。そこに6つのバイナリターゲットがあります。Linux側の状況はさらに悪く、神で実行されているはるかに多くのディストリビューションがどのハードウェア（x86、PPC、MIPS、SPARC、PA-RISCなど）を知っているかです。すべての可能な組み合わせのために構築するつもりですか？そのための機器やソフトウェアもありますか？PIIでNTを実行している（神が私たちを助ける）誰かがまだいる場合、それらのバイナリをビルドしますか？

次に、出荷元は、ユーザーが特定の環境に合わせてビルドを最適化できることを意味します。必要な最適化を有効にしたり、必要に応じてソース自体を調整したりできます。

通常、オープンソースプロジェクトの価値は、それがアプリケーション、システム、モジュール、またはライブラリであっても、必要に応じて調査および/または修正できることです。ソースの配布は、発行モデルに固有のものです。

バイナリを配布すると、悪意のある目的のために何らかの方法で変更されたというリスクが生じます。ソースからプロジェクトをコンパイルすると、そのリスクを軽減しようとします。

これにはいくつかの理由があります。多くの（ほとんどではないにしても）オープンソースプロジェクトがLinuxで始まります。したがって、最初のプロジェクトはこのシステムで行われ、パッケージングは​​チームメンバーによって行われます。

Windowsインストーラーの作成は余分な作業であり、Linux開発者にはない知識が必要です。したがって、コアチームの外部の誰かがこの仕事を引き受ける場合、彼はしばしば特別に言及されます。

OS Xや特定のLinuxディストリビューションなど、他のシステムでも同じことが言えます。それは、誰が余分な仕事をするための知識と時間を持っているかによります。