Per anni, il software open source è stato considerato una sorta di vangelo nel settore dell’ICT4D. I Principi per lo Sviluppo Digitale lo hanno addirittura elevato a Principio 6 e la Digital Public Goods Alliance ha costruito un movimento globale intorno ad esso. Anche UNICEF Innovation ha dichiarato che avrebbe sviluppato solo software open source a partire dal 2026.
Tuttavia, un recente rapporto di NetHope intitolato Harnessing AI for Humanitarian Impact ha messo in discussione questa convinzione. Il rapporto, che analizza 11 implementazioni di AI umanitaria, contiene una frase che sfida uno dei pilastri del settore: “L’open source non elimina i costi, li ridistribuisce. Le commissioni di licenza sono sostituite da richieste di coordinamento: mantenimento delle codebases, documentazione degli strumenti, onboarding dei contributori e governance delle infrastrutture condivise. Per le Ong con risorse limitate, questi costi di coordinamento possono essere pari o superiori al prezzo di una licenza commerciale.”
Le fonti di finanziamento e il conflitto di interessi
Prima di approfondire questa scoperta, è importante notare che il NetHope Center for the Digital Nonprofit che ha prodotto l’analisi, ha quattro partner: BoxOktaPagerDuty e Microsoft. Questi partner vendono soluzioni software proprietarie, il che potrebbe suggerire un conflitto di interessi. Tuttavia, ciò non significa che i risultati del rapporto siano sbagliati. NetHope è un’organizzazione seria e i casi di studio sono ben documentati.
Esempi concreti di costi nascosti
Il rapporto di NetHope non è un caso isolato. Anche altre organizzazioni hanno riscontrato problemi simili. Ad esempio, la comunità OpenLMIS finanziata da USAID e dalla Fondazione Gates ha scoperto che il mantenimento del software open source richiedeva risorse significative. Alla fine, hanno scelto di affidare la manutenzione a un partner commerciale, Vitalliance nel 2026.
Un altro esempio è DEEP una piattaforma di analisi dei dati umanitaria documentata nel rapporto di NetHope. DEEP ha chiuso nel 2026 non perché fosse fallito, ma perché il suo ciclo di finanziamento è terminato. L’open source non l’ha salvato, semplicemente nessuno stava pagando il “costo di coordinamento”.
Mikael Hailu del Norwegian Red Cross ha sollevato un punto simile nell’, sottolineando che la maggior parte degli strumenti open source nel Sud del mondo sono “specifici per la missione, strettamente legati a settori come la sanità pubblica, l’istruzione o i servizi sociali” con basi di utenti più ristrette rispetto a progetti come Apache o Linux.
Infine, Development Gateway ha argomentato che “l’open source è visto come un’opzione intrinsecamente sostenibile. Questo è un malinteso sia del valore dell’open source che dei cicli di vita della tecnologia.” Hanno osservato un sistema internazionalmente applaudito andare offline perché il governo non aveva previsto i costi di hosting. L’open source non ha prevenuto questo, potrebbe averlo reso più probabile, permettendo a tutti nella catena di finanziamento di assumere che qualcun altro si stesse occupando della manutenzione.
Implicazioni per l’acquisizione di software
Tre cose dovrebbero cambiare nel modo in cui il settore parla di open source nel 2026, senza abbandonare il principio. Prima di tutto, smettiamo di considerare “lo renderemo open source” come un piano di sostenibilità. Non lo è. Un vero piano di sostenibilità nomina chi paga per il coordinamento, la manutenzione, la formazione, l’hosting, le patch di sicurezza e la governance dei contributori per i prossimi cinque anni, in dollari, con un finanziatore nominato.
In secondo luogo, bilanciamo esplicitamente lo strato di coordinamento open source come una voce di bilancio. Il quadro di NetHope dell’open source come “strategia di riallocazione dei costi” piuttosto che una strategia di riduzione dei costi è il modello mentale giusto. Il costo non è svanito. Si è spostato da una fattura del fornitore al calendario del personale, dove è più difficile da vedere e più facile da sottofinanziare.
Infine, smettiamo di trattare i fornitori commerciali come un fallimento morale. A volte un servizio software commerciale gestito con un accordo di livello di servizio, un team di sicurezza e un obbligo contrattuale di mantenere il prodotto è la scelta più economica, più sostenibile e più responsabile per un caso d’uso umanitario particolare.
L’approccio maximalista dell’open source, secondo cui le Ong finanziate con denaro pubblico non dovrebbero mai utilizzare strumenti proprietari, ha prodotto vittime reali: strumenti che sono morti perché nessuno è stato pagato per mantenerli vivi e decisioni di acquisizione basate sull’ideologia piuttosto che sull’adattamento.
L’open source rimane essenziale per l’infrastruttura digitale pubblica, per gli strumenti che devono sopravvivere a qualsiasi singolo fornitore e per il codice che non dovrebbe essere tenuto in ostaggio dalle decisioni di prezzo di un’azienda. Tuttavia, per gli strumenti software operativi utilizzati dalle Ong, la domanda non è più “open o proprietario”. È “chi finanzia lo strato di coordinamento e per quanto tempo”. La risposta onesta a questa domanda determinerà se lo strumento esisterà nel 2030. La licenza allegata ad esso non lo farà.
