Perché alcune librerie open source non forniscono binari?

Perché alcune librerie open source non forniscono binari? Ho notato che alcuni progetti rimandano a terze parti che mantengono le build correnti del software, in particolare per le build di Windows.

Chiedo perché sembra una barriera per l'adozione di una biblioteca. È più lavoro per lo sviluppatore poiché deve creare il suo ambiente per costruirlo. Uno sviluppatore deve anche preoccuparsi di aver introdotto dei bug costruendo la libreria in modo errato.

EDIT : alcuni aggiornamenti per rispondere a commenti e risposte. Ho rimosso gli esempi poiché non sono centrali nella discussione. Ha anche riformulato la mia domanda in quanto "alcune biblioteche open source forniscono" piuttosto che "le biblioteche open source tendono a fornire" ... non si sono rese conto che le persone si sarebbero offese.

Perché creare binari di Windows è un lavoro completamente diverso che richiede una base di conoscenza e un set di strumenti completamente diversi. Le persone sembrano avere difficoltà a capire questo riguardo agli sviluppatori Linux, quindi lasciatemi cambiare.

• Hai usato Windows per quello che sembra per sempre.
• Windows è installato solo a casa.
• Hai usato Linux qua e là al lavoro, ma solo come utente, non amministrando o sviluppando per Linux.
• Sai che gcc è il compilatore più comunemente usato per Linux, ma non l'hai mai installato sul tuo computer.
• Lavori principalmente sul software per te stesso su Windows, ma non ti dispiace fare correzioni di bug per Linux se qualcun altro fa il lavoro per renderlo compatibile e distribuire i binari.
• Non vuoi pagare per un altro SO e toolchain quando qualcun altro che ha già è perfettamente disposto a fare le build.

Il Cairo è una biblioteca, non un'applicazione. Postgres sembra avere i binari di Windows . I progetti più piccoli spesso non forniscono build perché non dispongono dell'infrastruttura / delle risorse.

Fa parte della filosofia open source di "se vuoi fare qualcosa, prendi una pala". Naturalmente, riduce il carico di lavoro per gli sviluppatori se gli utenti compilano semplicemente il programma da soli. Non c'è bisogno di preoccuparsi di tutte quelle architetture, sistemi operativi, ecc ...

Ma se stai realizzando un prodotto di livello consumer (Firefox, Paint.NET, Audacity, Keepass, ecc.) E ti preoccupi di acquisire utenti, dovresti sempre, sempre, sempre! include i binari. Probabilmente solo il 2% delle persone che inciampano sul tuo sito Web e sono interessate al tuo prodotto, stanno per:

• Scarica il client SCM appropriato
• Dai un'occhiata a un'intera copia dell'albero dei sorgenti
• Scarica l'IDE o gli strumenti del compilatore necessari (facilmente diverse centinaia di MB per alcuni progetti)
• Scarica e installa tutte le dipendenze necessarie (e imposta le variabili ambientali)
• Esegui una nuova compilazione (facilmente un processo di 10 minuti su alcuni progetti)
• Affrontare eventuali errori o problemi o che sorgono (che in piccoli progetti probabilmente non sono documentati - "oh sì, l'ultimo è in realtà nella riscrittura dei rami, non nel tronco!")
• Disinstalla tutto o lascialo tutto sul tuo computer e ricompila per gli aggiornamenti.

(Ovviamente su Linux le cose sono molto più sanitarie, ma la maggior parte dei consumatori usa ancora Windows.)

È molto più facile per i nuovi arrivati ​​dire "ooh, versione di Windows! Scarica. Esegui".

Tuttavia, molti progetti open source non sono a livello di consumatore; prendono di mira i programmatori, che hanno una tolleranza molto più alta per questo tipo di calvario, e quindi i binari sono fai-da-te. Nella mia esperienza, tuttavia, i programmatori possono essere pigri quanto gli utenti, quindi fai attenzione. :)

I creatori di applicazioni scritte in un ambiente Write Once Compile Anywhere (C, C ++, ecc.) Traggono vantaggio dallo spingere il passo della compilazione verso i distributori (apt, rpm, yum, ecc.) Che creano e confezionano file binari per architetture popolari. Ciò consente di ottenere un'applicazione estremamente portatile con meno sforzi da parte dei creatori e consente loro di dedicare più tempo a concentrarsi sulla propria competenza principale (sviluppo dell'applicazione, non compilazione e hosting per più architetture). Alcuni creatori di applicazioni WOCA sono disposti a pagare il costo aggiuntivo in casi speciali come Windows perché - beh - nessun altro lo farà, gli utenti se lo aspettano e non vogliono rinunciare al mercato.

D'altra parte, le applicazioni scritte in un ambiente Write Once Run Anywhere (Java) o per una specifica architettura di destinazione (applicazioni OS X, ad esempio) sono in grado di fornire un singolo binario e spesso lo fanno poiché devono solo pagare la compilazione costa una volta.

Infine, i loro utenti si sentono generalmente a proprio agio a costruire dal sorgente o usando il loro gestore di pacchetti del sistema operativo, quindi questo modello offre anche una migliore usabilità. Gli utenti sanno dove trovare i binari (il loro gestore di pacchetti), hanno un'esperienza coerente nel ciclo di vita dell'installazione e della gestione dei pacchetti e sanno dove acquisire l'origine se ne hanno bisogno.

Perché dovrei voler masticare la larghezza di banda fornendo una build (che ovviamente può essere molto grande) piuttosto che costruire la fonte che ti sto fornendo comunque? Per non parlare del fatto che la creazione di un progetto sulla propria macchina produrrà sempre risultati migliori in quanto è compilato appositamente per la tua piattaforma.

Mi vengono in mente due ragioni.

Innanzitutto, hai più sistemi operativi in ​​esecuzione su più tipi di hardware; il numero di target binari che dovresti costruire diventa ingestibile. Esistono tre versioni di Windows ancora comunemente utilizzate (XP, Vista, 7) in esecuzione su hardware a 32 o 64 bit; sono 6 obiettivi binari proprio lì. La situazione è peggiore dal lato Linux, con una varietà molto più ampia di distribuzioni in esecuzione su Dio che sa quale hardware (x86, PPC, MIPS, SPARC, PA-RISC, ecc.). Costruirai per ogni possibile combinazione? Hai anche l'attrezzatura e / o il software per farlo? Se c'è qualcuno ancora in esecuzione (Dio ci aiuti) NT su una PII, hai intenzione di costruire un binario per loro?

In secondo luogo, la fonte di spedizione significa che gli utenti possono ottimizzare la build per il loro ambiente particolare; possono attivare tutte le ottimizzazioni di cui hanno bisogno o modificare la fonte stessa, se necessario.

In genere, il valore di un progetto open source, sia esso un'applicazione, sistema, modulo o libreria, è che può essere studiato e / o modificato secondo necessità. La distribuzione della fonte è intrinseca al modello editoriale.

La distribuzione di un binario comporta il rischio che sia stato modificato in qualche modo per scopi nefasti. La compilazione del progetto da fonti tenta di mitigare tale rischio.

Questo può avere diversi motivi. Molti (se non la maggior parte) progetti open source iniziano su Linux. Quindi il progetto iniziale è fatto per questo sistema e l'imballaggio è fatto dai membri del team.

La creazione di un programma di installazione di Windows è un lavoro extra che richiede conoscenze che gli sviluppatori Linux potrebbero non avere. Quindi, se qualcuno al di fuori del nucleo centrale intraprende questo lavoro, viene spesso menzionato in modo speciale.

Lo stesso può valere per altri sistemi come OS X o persino specifiche distribuzioni Linux. Tutto dipende da chi ha le conoscenze e il tempo per fare il lavoro extra.