Ciò che entra realmente in primo piano nel modello open source è il problema della catena di fornitura.

Una volta che un argomento del genere viene scritto come “sigillato”, l’attenzione verrà attirata su un quadro eccessivamente drammatico. I cambiamenti più comuni nel progetto sono meno drammatici: la fonte pubblica di download diventa instabile, iniziano ad apparire siti mirror, una determinata versione viene rimossa dagli scaffali, il ritmo degli aggiornamenti continui viene interrotto e la catena di ragionamento nelle mani del team deve improvvisamente reggersi a se stessa.

Il livello hosting si fa carico per primo della pressione

Più si discute del modello open source, più è facile vedere chiaramente una cosa: ciò che può essere direttamente toccato dalle politiche, dai controlli sulle esportazioni e dalle regole della piattaforma spesso non sono i documenti ponderati che sono stati distribuiti, ma l’hosting pubblico, l’inferenza online, la distribuzione delle versioni e gli ingressi predefiniti.

Ciò significa che, sebbene sembri “sigillato”, il percorso che in realtà è interrotto è spesso il percorso più semplice. Quello che prima era un semplice processo di recupero di un URL, impostazione di un’interfaccia di hosting e chiamata, una volta improvvisamente è cambiato in ricerca di un’immagine, aggiunta di una firma, controllo dell’hash, controllo della licenza e conferma della versione di rollback. Le azioni possono sembrare piccole, ma se collegate tra loro formano una filiera completa.

Una volta effettuato il fork della versione, il nome non spiega più il problema.

La parte più difficile del modello open source non è mai “se ce n’è uno”. Una volta che il peso si diffonde su più immagini, più magazzini organizzativi e più rami di messa a punto, comportamenti diversi cresceranno sotto lo stesso nome.

In questo momento non basta più discutere “se il modello esiste ancora”. La domanda più problematica è: quale è la linea principale, quale è solo un’immagine speculare, quale è stata addestrata due volte e quale conserva ancora il comportamento di ragionamento originale. Il nome può ancora rimandare allo stesso progetto, ma i risultati hanno cominciato a divergere. A questo punto, se la squadra considera ancora “lo stesso nome” come “la stessa cosa”, i risultati online prima o poi saranno diversi.

Questa è anche la più grande differenza tra i modelli open source e le API closed source. L’API closed source è disconnessa e le prestazioni sono molto semplici; il modello open source è biforcato e in superficie il servizio è ancora in esecuzione, ma dietro le quinte la versione, le dipendenze e i limiti di comportamento sono stati modificati. Ciò che è veramente inquietante spesso non è il fallimento, ma “sembra ancora funzionare”.

Ciò che realmente deve essere corretto è l’origine, il rollback e la ricorrenza offline.

Quando questo tipo di cambiamento arriva al progetto, la prima cosa da compensare non sono le emozioni, ma tre cose: origine, rollback e ricorrenza offline.

La fonte deve essere riconducibile a magazzini specifici, presentazioni specifiche e documenti di peso specifici. Il rollback deve essere in grado di restituire la versione precedente del comportamento, non solo un nome. La riproduzione offline deve essere in grado di eseguire nuovamente lo stesso ciclo di esperimenti quando la rete è instabile, il mirror viene perso o il pacchetto upstream viene eliminato.

Molte squadre di solito sentono che queste cose sono lontane da loro. Solo un giorno, quando un aggiornamento upstream cambia lo stile di output, o una certa sincronizzazione delle immagini è lenta, si scopre che il problema non è affatto nella capacità del modello, ma nella catena di dipendenze che non viene gestita come un cittadino di prima classe. Quanto più il modello è open source, tanto più ovvio è questo. Perché ciò che l’open source porta non è un “ingresso libero” sempre stabile, ma una filiera sempre più lunga.

La parte più fisica solitamente non è il corpo del modello.

Quando si tratta di un ambiente di produzione, il punto in cui è più probabile che si verifichi un errore non è solitamente l’ontologia del peso, ma la voce predefinita, gli aggiornamenti automatici e le dipendenze implicite.

Se un team considera un determinato portale online come l’unica fonte, può ancora richiamarlo oggi, ma potrebbe dover trovare temporaneamente un sostituto domani; se considera una stazione specchio come la verità predefinita, la deriva della versione si insinuerà silenziosamente nell’addestramento e nella valutazione; se il ritmo di aggiornamento è troppo serrato, la stabilità del comportamento di oggi non è chiara e la nuova versione di domani sarà online.

Quindi questo tipo di problema assomiglia alla politica internazionale, ma quando si tratta di ingegneria, assomiglia più alla governance della catena di fornitura. Chi controlla la voce, chi è responsabile della firma, chi definisce il rollback, chi salva la vecchia versione e chi può ricostruirla offline, questi sono i limiti che continueranno a influenzare la consegna. Dopo che il modello stesso sarà reso pubblico, lo spazio lasciato alle azioni esterne si ridurrà; lo spazio lasciato al team per comporre le proprie lezioni diventerà più ampio.

Se il modello open source sarà “sigillato” è una questione un po’ ristretta. Un giudizio più realistico è: più è open source, più è difficile tenerlo fermo con una singola azione; ma più è open source, più ha bisogno di gestire versioni, sorgenti, rollback e ricorrenze offline. Se questa catena di approvvigionamento non viene contenuta, qualsiasi fluttuazione esterna verrà amplificata fino a trasformarsi in un incidente che assomiglia ad un “incidente modello”.