C’è un’immagine romantica e quasi religiosa che circonda il mondo dello sviluppo: una prateria digitale dove programmatori brillanti collaborano gratuitamente per il bene dell’umanità. Ci hanno venduto l’Open Source come l’utopia meritocratica definitiva.

Ma se gratti via la vernice dell’altruismo, quello che resta è uno dei sistemi di estrazione di valore più efficienti e spietati dell’era moderna.

GitHub oggi non è sempre un tempio della condivisione. Per troppe aziende e “imprenditori” digitali è diventato un buffet gratuito dove ci si abbuffa del lavoro non pagato di milioni di sviluppatori.

1. La trappola psicologica del “Curriculum su GitHub”

Tutto inizia con una sottile manipolazione. Al giovane sviluppatore viene ripetuto fino alla nausea che GitHub è il suo “nuovo CV”. Ti convincono che devi regalare il tuo tempo, le tue competenze e le tue notti insonni per “farti un nome” e collezionare stelline sulle repository.

L'ILLUSIONE: regalare codice ➔ ottenere visibilità ➔ essere assunto
LA REALTÀ:   regalare codice ➔ generare valore gratis ➔ essere ignorato

Molti caricano progetti spinti dall’idealismo e dalla filosofia della conoscenza libera; altri sperano di attirare l’attenzione dei recruiter Big Tech. La realtà? Stai solo lavorando gratis per chi ha già miliardi a bilancio. Stai arredando la vetrina di un negozio di cui non possiedi nemmeno le chiavi.

2. Il parassitismo delle Big Tech e la guerra delle licenze

Il grande paradosso dell’Open Source moderno è questo: multinazionali da centinaia di miliardi prendono librerie e infrastrutture create da volontari e le usano per costruire servizi a pagamento (SaaS) o addestrare modelli proprietari.

Non è un’esagerazione retorica, è un dato strutturale:

  • Il caso Elasticsearch, Redis e Terraform: Aziende come Elastic, Redis e HashiCorp hanno dovuto stravolgere le proprie licenze storiche — passando a licenze protettive come SSPL o BSL — dopo che i colossi del Cloud (come AWS) hanno preso il loro software Open Source, lo hanno impacchettato e rivenduto come servizio gestito, incassando i profitti senza restituire quasi nulla alla community.
  • Legale non significa giusto: Se rilasci codice sotto licenza permissiva (MIT o Apache 2.0), le aziende hanno il pieno diritto legale di prendere il tuo codice, rinominarlo e rivenderlo. Non stanno violando le regole: stanno usando esattamente la licenza ingenua che gli hai regalato.

Il rischio, la manutenzione e la fatica restano pubblici e gratuiti; il profitto e le revenue diventano privati e blindati.

3. Dai “Fork” illegali al mercato nero del rebranding

Oltre all’estrazione di valore da parte dei colossi, c’è una categoria ancora più fastidiosa: i “pirati dei SaaS”.

Qui bisogna fare una distinzione fondamentale per non cadere in errore:

  1. Abuso di Licenze Permissive (Legale, ma discutibile): Chi prende un progetto MIT/Apache, rifà la grafica al frontend, cambia i nomi alle variabili di backend e lo rivende su Gumroad o AppSumo come “soluzione proprietaria”. È frustrante, ma è legale.
  2. Violazione palese di Licenze Copyleft (Illegale): Chi prende codice sotto licenza GPL o AGPL, lo impacchetta in un servizio chiuso e si rifiuta di condividere i sorgenti o di citare l’autore. Questo è un illecito vero e proprio.

Perché nessuno fa causa? Perché lo sviluppatore indipendente non ha 30.000€ da dare a uno studio legale per inviare una lettera di Cease & Desist a una società estera. I predatori lo sanno benissimo e scommettono sull’impossibilità pratico-economica di far valere la licenza.

4. La crisi del burnout e la sicurezza globale

Il risultato di questo meccanismo non è solo l’ingiustizia economica: è il collasso psicologico dei creatori.

I dati dello State of the Open Source Maintainer Report di Tidelift parlano chiaro:

  • Circa il 60% dei maintainer lavora senza essere pagato per il mantenimento di progetti critici.
  • Il 60% dei maintainer ha pensato di abbandonare o ha già abbandonato i propri progetti.
  • La prima causa? Il burnout (44%), alimentato da aziende e utenti che pretendono bugfix immediati e supporto gratuito H24.

Un esempio agghiacciante di questa dinamica è stato il caso XZ Utils (CVE-2024-3094): una libreria di compressione fondamentale per l’infrastruttura di quasi tutto il mondo Linux era gestita da un singolo sviluppatore esausto e in burnout. Un gruppo di malintenzionati ha sfruttato proprio quel burnout con tecniche di ingegneria sociale per farsi cedere le chiavi del progetto e inserire una backdoor devastante.

Non è un caso isolato. È il sintomo di un sistema strutturalmente rotto: aziende che dipendono per il 95% dall’Open Source, ma che contribuiscono economicamente in misura marginale alla sua sopravvivenza.

Conclusione: Smettere di essere “utili idioti”

Sia chiaro: l’Open Source come concetto di cooperazione pura è una delle invenzioni culturali più belle dell’umanità. Ma la versione romanticizzata che ci viene venduta oggi su GitHub è diventata la copertura per uno sfruttamento sistematico.

Non metto più liberamente i miei progetti su GitHub non perché io sia “contro” la condivisione, ma perché rifiuto di fare la parte del volontario inconsapevole in un’industria che fattura miliardi.

Se vuoi davvero proteggere il tuo lavoro intellettuale, hai tre alternative:

  1. Abbandona la MIT di default: Se vuoi che il tuo codice resti libero, usa la GPLv3 o l’AGPLv3, che obbligano chiunque usi o eroghi il tuo software via rete a rilasciare le modifiche.
  2. Adotta licenze “Fair Source” o BSL: Modelli che permettono l’uso gratuito per individui e piccoli progetti, ma chiedono un pagamento alle aziende che superano determinate soglie di guadagno.
  3. Pensa prima al tuo valore: Prima di rendere pubblica una repository, chiediti: Sto costruendo un mondo migliore per tutti o sto solo regalando i mattoni a chi poi mi farà pagare il biglietto per entrare nell’edificio?