In che modo lo sviluppo del software GNU sostiene economicamente?

Mi scuso se questa domanda è fuori tema, ma è contemporaneamente un'economia e una domanda di programmazione. Se dovesse andare in un'altra comunità SE, per favore indicami.

In teoria, il software GNU è interamente sviluppato da volontari durante il loro tempo libero o da società che finanziano volontariamente i programmatori per sviluppare software GNU (utilizzando le entrate provenienti da un altro settore della loro attività).

Capisco come possa funzionare perfettamente per un progetto su piccola scala che può essere svolto in un paio di weekend di pioggia da un singolo individuo (diciamo ad esempio un gioco di sudoku), perché dopo tutto la programmazione per computer è un hobby estremamente divertente e gratificante, e non ho problemi a vedere le persone sviluppare programmi di piccole o medie dimensioni durante il loro tempo libero e condividerli con il mondo.

Il problema è che questo si riduce in modo estremamente scarso per programmi più grandi per i seguenti motivi:

1. Per quanto la programmazione sia divertente, poiché il progetto che deve essere implementato diventa più grande, il tempo necessario per implementare la funzionalità desiderata aumenta molto rapidamente. Lo sviluppo di un programma su larga scala richiede un'incredibile quantità di tempo, ad esempio potrebbero essere necessari 15 anni di tempo libero e ferie per la programmazione di un sistema operativo da parte di un individuo e, al momento del rilascio del suo software, sarà completamente obsoleto .
2. Dato che altre persone scrivono programmi in un modo diverso da quello che avresti fatto tu, leggere e comprendere il codice di qualcun altro richiede molto tempo, nella maggior parte dei casi quanto scriverebbe il tuo codice da zero. Modificare il codice di un'altra gente e cercare di migliorarlo, come è incoraggiato dalla filosofia GNU, richiede quasi altrettanto tempo quanto sviluppare il proprio clone di detto programma con le funzionalità che si desidera aggiungere.
3. Non appena 2 o più persone dovranno collaborare per sviluppare un programma più ampio, questo crea un sacco di problemi decisionali che non sorgerebbero mai in un progetto a singolo sviluppatore. Il risultato è che, ad esempio, se un gruppo di 2 programmatori collaborasse per un progetto che richiederebbe 10 anni per un singolo uomo, non ce la farebbero in 5 anni ma probabilmente in 8.
4. Se le persone che collaborano per lo stesso progetto si incontrano solo su Internet, è facile che un membro del progetto svanisca improvvisamente (o perché ha perso interesse o perché fisicamente non può più essere su Internet), rendendo così anche la collaborazione Più forte

Quindi, mentre capisco perfettamente come programmi semplici possono essere sviluppati con la mentalità GNU, non vedo assolutamente come programmi così grandi come GNU / Linux o gcc siano possibili su questo modello. gcc ha circa 7 milioni di righe di codice. So che le righe di codice non significano molto, poiché in una fase successiva di un progetto il programmatore più produttivo è quello che rimuoverà effettivamente le righe di codice (semplificando e / o ottimizzando il progetto), ma questo dà una visione d'insieme di quanto un progetto gcc è.

Quindi, in teoria, chiunque può modificare liberamente gcc durante il tempo libero, ma in pratica? È stato sviluppato da persone molto professionali come lavoro, non come hobby. Chiunque realizzi un compilatore come hobby alla fine si arrenderà poiché il costo / beneficio non ne vale la pena:

• Lo sviluppo di un programma di grandi dimensioni è un progetto così lungo a lungo termine, che preferirebbero usare il loro tempo libero per avere altre attività più gratificanti o più divertenti a breve termine
• Se dovessero comunque sviluppare un programma di grandi dimensioni, preferirebbero farlo per un'azienda che li pagherà piuttosto che farlo gratuitamente

Al fine di attirare le persone interessate allo sviluppo di un programma come GNU / Linux, gcc o Open Office a lungo termine, dovrebbe essere gratificante. Quindi la mia domanda è: perché ci sono persone che contribuiscono al grande progetto GNU, se non ricevono uno stipendio per questo?

Vorrei iniziare dicendo che non sono un programmatore e non ho mai contribuito a nessun progetto open source. Tuttavia, mi sono interessato all'open source da molto tempo e credo di comprendere i concetti generali dell'open source e come funziona.

Per cominciare, vorrei dire che l'open source non significa che non puoi fare soldi con il software. Significa solo che il codice deve essere disponibile al pubblico. Aziende come Red Hat e Canonical guadagnano non vendendo il software, ma vendendo le loro competenze. Se non voglio che la mia azienda gestisca un server Linux, posso ottenere il software gratuitamente. Ma ho bisogno di qualcuno che lo installi, lo installi e fornisca supporto. È qui che entra in gioco uno specialista, ad esempio Red Hat, che guadagna. Per l'azienda ha senso, perché assumere il proprio specialista sarebbe probabilmente molto più costoso. Questo dà anche a queste aziende un incentivo a contribuire con il codice. Vogliono che il loro prodotto sia buono, così le persone lo useranno e dai loro servizi.

Ma parliamo dei tuoi punti sulla scalabilità.

1. La cosa bella dell'open source è che non devi sviluppare tutto da zero. Un sistema operativo come Ubuntu non è stato creato da una sola persona. Molte persone hanno invece contribuito a diverse parti del sistema (in realtà penso che sarebbe difficile trovare una persona con tutte le competenze per creare ed un sistema operativo efficace). Ad esempio, la gente di Ubuntu non sviluppa il kernel Linux. Usano solo uno sviluppato da altri. Quindi ciò che era senza open source probabilmente impossibile, ora è possibile, perché puoi basarti sul lavoro di altre persone.

2. Leggere e comprendere gli altri non richiede più tempo che scrivere il tuo. Almeno non in molti casi. Oltre a ciò, non devi capire tutto il codice che usi. Se voglio scrivere un programma per Linux, non devo capire come funzionano in dettaglio tutte le parti di quel programma. Devo solo sapere cosa fanno. Posso quindi prendere queste parti e metterle insieme ad altre parti per creare il mio programma. Oppure posso prendere un programma esistente e modificarlo per le mie esigenze.

3. strumenti come git e github rendono incredibilmente facile collaborare. Ottieni semplicemente il codice e apporta modifiche. Quindi le invii al responsabile del progetto. Se è buono, sarà accettato.

4. le persone entrano ed escono continuamente dai progetti. Ma se il progetto è popolare, ci lavorerà abbastanza.

Ecco alcuni dei motivi per cui l'open source funziona.

1. Penso che la ragione principale per cui il software open source sia diventato così buono sia che il gran numero di persone che lavorano a un progetto, assicura un livello di esperienza che difficilmente posso archiviare in un piccolo team di sviluppatori. Sebbene possa sembrare strano, questo singolo fatto sembra superare tutti i problemi negativi che possono sorgere nell'open source.

2. Nella programmazione commerciale, il progetto muore con l'azienda. Diciamo che alcuni software di un'azienda che poi si chiude. Quindi sei fregato, poiché non riceverai aggiornamenti e correzioni di bug e dovrai essere aggiornato da un nuovo software. Con l'open source puoi semplicemente trovare un'altra società per supportare il tuo software o svilupparlo da solo.

Se sei ancora interessato, ti suggerisco di leggere La Cattedrale e il Bazar

Lo sviluppo di software open source viene eseguito per diversi motivi, ma è un malinteso comune che viene svolto principalmente da hobbisti o professionisti, ma come un progetto collaterale. Sto rispondendo a questa domanda per l'open source in generale, non per i software con licenza GNU in particolare. Ma la mia risposta è inclusiva.

Diciamo che sono uno sviluppatore di software (lo sono) e sto lavorando a un progetto software complesso (lo sono). Una buona architettura suddivide un problema in pezzi indipendenti e, man mano che lo sviluppo procede, gli sviluppatori spesso riconoscono che alcuni pezzi di cui hanno bisogno sono comuni a molti problemi. Ecco alcuni percorsi tipici da seguire:

1. Sviluppano loro stessi quel pezzo e diventa proprietà dell'azienda. Oppure acquistano una soluzione a codice chiuso da un'altra società.
2. Trovano un progetto open source che risolve questo problema ed è perfetto e la licenza è adatta. Lo incorporano semplicemente nel loro progetto, che potrebbe essere necessario o meno open-source in base alla licenza e al modo in cui viene utilizzato. Non contribuiscono al progetto.
3. Trovano un progetto open source che risolve quasi questo problema ma presenta difetti o carenze. Ci migliorano e possono apportare tali miglioramenti al progetto di base.
4. Non trovano nulla che gli piaccia abbastanza, quindi iniziano il loro progetto e decidono di open-source.

I vantaggi di 2-4 sono che più persone finiscono per contribuire sia alla progettazione che al codice del progetto, e si inserisce in una specie di ecosistema in cui sopravvivono idee forti (se lo si desidera procreazione) e no a quelle deboli. La correzione di bug e l'aggiunta di funzionalità diventano sforzi della comunità. Negli scenari n. 2 e 3, gli sviluppatori che adottano il progetto beneficiano di solidi principi di ingegneria e codice maturo. 3 e 4 sono correlativi. Nello scenario n. 4, gli sviluppatori traggono vantaggio quando altre persone adottano e migliorano il codice e lo restituiscono (n. 3). È vantaggioso contribuire di nuovo al progetto in modo che i tuoi miglioramenti vengano cementati mentre altre correzioni e miglioramenti si aggiungono a questi, di cui continui a beneficiare. Nella mia esperienza, tutti questi scenari sono all'ordine del giorno.

Nel mio attuale progetto software, sono uno di circa 12 sviluppatori e ho lavorato su un sistema per circa due anni. Abbiamo incorporato circa 5.000 progetti open source! Abbiamo generato solo alcuni nuovi progetti FOSS e abbiamo contribuito a circa mezza dozzina. In questo caso non siamo particolarmente bravi cittadini (altre società sono molto meglio), ma questo ti mostra la vastità di come tutto questo funziona. Anche su piccoli progetti, i contributi dell'open source possono facilmente contare in dozzine o centinaia. Se non utilizzassimo alcun software open source, i costi di sviluppo aumenterebbero di un fattore 100-10.000.

La scalabilità avviene a causa della modularità del design e anche attraverso questo tipo di processo di sopravvivenza del più adatto in cui il codice può essere refactored, biforcato e così via. La sopravvivenza è di solito migliore delle alternative proprietarie perché anche se il codice non viene più mantenuto, è disponibile e altre persone che trovano valore in esso possono mantenerne il proprio fork. Le aziende vanno e vengono e i dipendenti vengono assunti e lasciati ancora più velocemente. Se si aggiunge una dipendenza software per la quale non si dispone del codice sorgente o si ha a disposizione solo un piccolo team interno, si è verificato un rischio sostanziale. Grandi progetti come il kernel Linux, gcc, Android e altri hanno spesso un grande numero di aziende che contribuiscono attivamente.

Non è vero che è più facile scrivere codice buono e corretto che leggerlo (nella maggior parte dei casi). Né devi leggere tutto il software che stai utilizzando anche se stai apportando modifiche. Devi immergerti profondamente in sezioni di esso e leggere molto, ma non il tutto. Potrei dire di più qui sui test unitari, ma lo ometterò per brevità.

La maggior parte dei software open source non è sviluppata da persone nel loro tempo libero. La pratica è così straordinariamente vantaggiosa che funziona senza un mercato di ottimizzazione. Personalmente sospetto che un qualche tipo di approccio guidato dal mercato sarebbe di grande aiuto, ma non so quale potrebbe essere l'approccio. La gente sostiene che esiste un mercato in cui la reputazione è la valuta, ma non penso che sia un modello preciso. Una valuta al lavoro è il tempo necessario per adottare un nuovo software. Vuoi trovare e utilizzare qualcosa che sia attivo, semplice, con una buona documentazione, ecc. Quindi, come un acquirente, stai cercando il prodotto di migliore qualità per il minor tempo investito.