È follemente difficile fare un progetto open source di successo.
Contrariamente a quanto si può leggere nella risposta di Franklin Veaux (per il quale ho un enorme rispetto) non c'è un solo pezzo di software sul pianeta che non sia costruito sopra il software open source in qualche modo, forma o modo.
In molte, molte aree la questione degli "svantaggi" del software open source non ha nemmeno senso, perché non c'è alternativa.
Non è nemmeno come se si dovesse scegliere tra supporto e open source. Molte delle aziende open source di maggior successo in realtà esistono per fornire supporto ai loro prodotti open source. Queste non sono applicazioni desktop - le applicazioni desktop sono come gli unicorni del software open source. Sono al limite del mitico e tendono a sembrare peggio da vicino. Questi sono i mattoni chiave dell'internet che sperimentate e della tecnologia nel suo complesso.
Si possono guardare aziende come Elastic, Redhat, Hashicorp, Zyte, centinaia e centinaia di aziende, che offrono software open source e il loro prodotto è il supporto con esso. Anche esempi come Adobe non si può dire che siano puramente closed source in quanto Adobe ha davvero aperto pubblicamente grandi parti del loro codice. Il più famoso è lo standard PDF.
Così, ora che abbiamo eliminato questa sciocca nozione, parliamo degli effettivi svantaggi del software open source:
- Molto più oneroso per la documentazione e l'usabilità
- Come può testimoniare chiunque abbia lavorato in una startup, una base di codice closed-source può diventare piuttosto imperscrutabile molto rapidamente. Totale mancanza di documentazione, mancanza di test, evidenti vulnerabilità di sicurezza - tutti i 9 anni. Questo genere di cose è follemente comune in basi di codice grandi e piccole. Se mettete qualcosa del genere fuori nella comunità open source sarete o ignorati (nel qual caso la vostra iniziativa open source è fallita) o esclamati (nel qual caso la vostra azienda potrebbe fallire).
- Un progetto open source è fondamentalmente fatto per sostenere lo sviluppo esterno. Se non si pagano le persone per navigare nel codice, esse sono molto meno disposte a sopportare una cattiva base di codice. Per questa ragione la qualità del codice in una popolare libreria open source sarà anni luce avanti a qualsiasi equivalente opzione closed source.
- La costruzione della comunità è difficile
- Come ho detto, l'obiettivo finale di un progetto open source è quello di ottenere contributi produttivi di terze parti. Come detto sopra, la barra per il codice open source è molto, molto alta. Inoltre non si paga la gente per questo. Questo significa fondamentalmente che il vostro progetto deve essere abbastanza figo e accessibile da catturare il tempo dei migliori professionisti del settore nel loro limitatissimo tempo libero.
- E' molto più comune ricevere un centinaio di lamentele per la mancanza di documentazione, l'installazione difficile, o un commit mal concepito da uno studente di informatica troppo zelante.
- Le licenze sono complicate
- Diciamo che prendo un repo con una licenza copyleft. Diciamo AGPL. Poi diciamo che qualcuno decida di usare quel repo in un nuovo repo con la licenza BSD, più permissiva. Poi immaginiamo che un'entità commerciale avvolga quel repo BSD in un microservizio. Che obbligo ha l'azienda?
Vi fa girare la testa? Sì. Le licenze sono super confuse, spesso contraddittorie, e sono così raramente oggetto di controversie che non si può davvero avere fiducia in qualsiasi interpretazione specifica. Anche i capisaldi di internet come Creative Commons sono grandi incubi legali vaghi e inquietanti.
- Diciamo che prendo un repo con una licenza copyleft. Diciamo AGPL. Poi diciamo che qualcuno decida di usare quel repo in un nuovo repo con la licenza BSD, più permissiva. Poi immaginiamo che un'entità commerciale avvolga quel repo BSD in un microservizio. Che obbligo ha l'azienda?
- Come dimostra l'acquisizione di Autonomy (e un centinaio di altri piccoli fallimenti) - è molto raro avere una reale trasparenza nel codebase di un'azienda. Legalmente, anche l'acquirente più aggressivo non è autorizzato a ispezionare direttamente il codice sorgente di un'azienda. L'ispezione deve essere fatta attraverso strumenti automatizzati e terze parti esperte che hanno severi requisiti di riservatezza.
- Se si apre qualcosa di fondamentale si perde questa copertura. Qualsiasi potenziale acquirente vi giudicherà molto più duramente di un sistema closed source paragonabile perché possono, e perché c'è un gruppo di persone che crede sia il loro lavoro setacciare la vostra base di codice alla ricerca di un hash md5.
Francamente? L'open sourcing del tuo software non ha quasi mai senso. È un'enorme spesa e responsabilità per un ritorno minimo. Molti tipi di software non hanno senso in un'offerta open source. Se i dati privati o il calcolo sono una parte fondamentale della vostra offerta, allora non ha molto senso rendere open source il vostro codice.
Indubbiamente, Indico rende open source alcune aree chiave della nostra tecnologia. La ragione di ciò è più che altro culturale. Lo facciamo per restituire alla comunità e per costringerci a uno standard più elevato per alcuni pezzi chiave del nostro codice. Non direi che abbiamo dei repo open source veramente di successo, anche se certamente non potremmo fare il nostro lavoro senza di loro.