Non esiste una definizione univoca di successo nei progetti open source.
Tutti amano l'open source in questi giorni. Microsoft ha appena rilasciato il suo software 3D Movie Maker con una licenza open source. Spotify ha una serie di progetti che ha rilasciato e ai quali contribuisce, e ha appena annunciato un fondo per supportare i manutentori dei progetti. C'è persino il codice del motore di gioco del Medioevo (1998) in open source.
Open source:copertura da leggere
Con questi progetti e milioni di altri disponibili, è una domanda giusta da porsi... perché? O meglio, perché la stragrande maggioranza di questi progetti è importante e per chi? La maggior parte dei progetti, dopotutto, non sarà mai Kubernetes.
Dopo più di due decenni nell'open source, tuttavia, sto iniziando a capire che questa è la domanda sbagliata.
L'esempio del petardo
Prendi Firecracker, un progetto di microvirtualizzazione open source che AWS ha rilasciato nel 2018. Firecracker è stato quasi universalmente acclamato come una tecnologia interessante... e poi per lo più è scomparso dalla vista del pubblico. Ho scritto di alcuni dei primi successi della community, ma anche quello (Weave Ignite per migliorare la facilità d'uso di Firecracker, tra le altre cose) proveniva da uno stretto partner AWS. Per dare a Firecracker più peso nella community, ho suggerito ad AWS di seguire Google e di aprire la governance attorno a Firecracker, non solo al suo codice.
AWS non ha ascoltato ma, non per la prima volta, la mia opinione non sembrava avere importanza. (È un modo educato per dire che forse mi sbagliavo.)
Avanti veloce fino al 2022 e Petardo si sta abituando tranquillamente in molti posti interessanti. Dico "sottovoce" perché, beh, perché qualcuno dovrebbe gridare la propria infrastruttura dai tetti? Ma quando ho chiesto, sono emersi alcuni utenti interessanti, come Stripe, Fly.io, System Initiative e altri. Naturalmente, è ancora vero che la maggior parte dei collaboratori di Firecracker sono impiegati da AWS.
Ma anche se Firecracker fosse rimasto una community di uno (AWS), probabilmente ne sarebbe valsa la pena. In effetti, questo è essenzialmente ciò che ho sostenuto mentre lavoravo per AWS, indicando che c'erano chiare ragioni orientate al cliente per l'open source Firecracker, indipendentemente dal coinvolgimento della comunità. L'open source ha assicurato che Firecracker avrebbe funzionato bene con la comunità Linux e ha consentito ai clienti "guadagni combinati di prodotto" più stretti.
Milioni di petardi
Ora riproduci questo esempio di Firecracker moltiplicato per oltre cento milioni di repository GitHub (e altri open source). Non si tratta di essere il prossimo Kubernetes. Per ogni progetto open source, si tratta di soddisfare le esigenze del singolo sviluppatore, di un'azienda o di una comunità più ampia.
A volte quei bisogni potrebbero essere grandi. In una conversazione che ho avuto con il capo dell'ingegneria di Lyft e fondatore di Envoy Matt Klein, ha sottolineato che "Per la maggior parte delle persone che open source qualcosa, in realtà è un netto negativo" perché "se non ci investono, se non lo fanno se fai tutte queste cose [come PR, marketing e assunzioni], ti lanceranno qualcosa oltre il muro". Per Klein, ottenere un coinvolgimento significativo a livello di settore in Envoy ha contribuito a rendere il progetto degno dell'investimento che lui (e, per estensione, Lyft) aveva fatto.
Ma probabilmente non tutti hanno bisogno di ottenere quel tipo di ritorno. Nel caso di Firecracker, l'open sourcing del codice e la semplice collaborazione dei clienti sarebbero stati sufficienti, come ho ragionato. Per Google, al contrario, che stava probabilmente cercando di far avanzare una realtà multicloud attraverso Kubernetes, doveva andare alla grande. Ogni progetto avrà esigenze diverse e diverse misure di successo.
Quindi non sei il prossimo Kubernetes? Va bene. Né tu sei il prossimo Petardo? Anche bene. Per gli sviluppatori open source, la chiave è capire cosa significa un progetto sano per le tue esigenze particolari e non farti distrarre dalle definizioni di successo degli altri.
Disclosure:lavoro per MongoDB ma le opinioni qui espresse sono mie .
Link alla fonte