La chiusura della classifica AI di decomp.dev mette a nudo un gioco di numeri vuoto

decomp.dev ha congelato il proprio indice pubblico e la classifica dopo due anni, affermando che l'AI aveva trasformato progressi misurabili in una competizione dannosa. La chiusura della classifica AI di decomp.dev non cancella il sito né i suoi archivi storici. Rimuove il tabellone condiviso che un tempo aiutava gli esperti di reverse engineering a trovare progetti, seguirne i progressi e celebrare un lavoro difficile.

Il creatore Luke “encounter” Street afferma che l'AI non è di per sé l'unico problema. Usata con supervisione umana e revisione del codice, può accelerare significativamente la decompilazione dei giochi. Il conflitto inizia quando questa velocità premia fork ostili, codice sottoposto a scarsa revisione e porting PC affrettati in modo più visibile rispetto a una ricerca accurata.

Questa distinzione conta anche oltre il retrogaming. I progetti aperti usano spesso metriche pubbliche per motivare i contributori, ma tali metriche presuppongono che ogni unità di progresso rappresenti uno sforzo approssimativamente comparabile. L'AI rompe questa premessa. Quando le percentuali di completamento possono crescere attraverso metodi molto diversi, una classifica smette di misurare un risultato condiviso e comincia a plasmare i comportamenti attorno a un numero inaffidabile.

Cosa cambia realmente con la chiusura della classifica AI di decomp.dev

decomp.dev sta ritirando le proprie funzioni pubbliche di scoperta e classificazione, non eliminando ogni record di progetto raccolto.

Street ha lanciato decomp.dev nel 2024 per centralizzare i progressi nella decompilazione con matching. La decompilazione con matching consiste nel riscrivere un programma affinché il nuovo codice sorgente produca codice macchina identico al binario originale quando viene compilato nelle condizioni corrette.

Questo lavoro è diverso dal chiedere a un decompilatore di produrre codice approssimativamente leggibile. Gli sviluppatori studiano l'assembly, deducono strutture dati, recuperano il flusso di controllo, identificano il comportamento del compilatore e modificano ripetutamente il codice sorgente. Un progetto può impiegare giorni per far corrispondere una sola funzione ostinata, perché una piccola differenza a livello di sorgente modifica l'output del compilatore.

Il sito rendeva leggibile quel lento processo. I visitatori potevano vedere percentuali di completamento, attività recenti e cambiamenti storici in numerosi progetti. Una frazione di punto percentuale poteva rappresentare un'indagine approfondita, quindi osservare il numero crescere offriva ai contributori una forma utile di riconoscimento.

L'avviso di dismissione di Street del 15 ottobre afferma che l'indice centrale e il supporto all'aggiunta di progetti vengono disabilitati. Le pagine dei progetti esistenti e le informazioni storiche resteranno disponibili e continueranno a tracciare i progetti noti. La decisione congela quindi la competizione pubblica preservando al contempo gran parte dell'archivio.

Questa sfumatura è stata talvolta persa nelle prime coperture. decomp.dev non sta semplicemente scomparendo dall'oggi al domani. Il suo creatore sta ritirando le parti che trasformano progetti indipendenti in un'unica gara visibile.

Secondo l'avviso, l'indice ha attirato persone che volevano davvero imparare e contribuire. Ha anche attirato partecipanti che trattavano la percentuale come un obiettivo separato dalla ricerca che la sosteneva. Street ha concluso che l'indice pubblico e la classifica stavano causando più danni che benefici.

La mossa segue le lamentele riguardo a persone che effettuano fork di repository esistenti e usano l'AI per “completare” un lavoro iniziato da un altro team. Le licenze open source possono consentire i fork, ma il permesso legale non risolve le questioni relative al riconoscimento, al consenso della comunità o a una gestione responsabile.

Un fork può inoltre ottenere attenzione prima che il team originale abbia tempo di valutare il codice generato. Questo crea un incentivo difficile. I maintainer devono accelerare il proprio lavoro, dedicare tempo ad analizzare l'output di altri oppure vedere un progetto derivato e approssimativo conquistare la narrazione pubblica.

La copertura della chiusura descrive un'altra fonte di tensione: opportunisti che corrono a pubblicare porting appena funzionanti basati sulla ricerca della comunità. Una schermata del titolo giocabile o un trailer curato possono diffondersi molto più rapidamente di una spiegazione accurata delle lacune in termini di precisione.

Congelare la classifica rimuove un amplificatore di questa corsa. Non impedisce la decompilazione assistita dall'AI, i fork dei repository o porting concorrenti. Semplicemente smette di assegnare a tali sforzi una posizione pubblica condivisa.

Perché decomp.dev ha chiuso il tabellone invece di vietare l'AI

Un divieto generalizzato dell'AI tratterebbe l'assistenza responsabile e la generazione senza revisione come la stessa pratica, costringendo al contempo un singolo appassionato a sorvegliare un confine instabile.

Street riconosce esplicitamente che l'AI può aiutare la decompilazione quando persone competenti la guidano e ne revisionano i risultati. Un modello può suggerire nomi, preparare traduzioni, spiegare istruzioni poco familiari o generare codice candidato che un essere umano può testare. Questi impieghi possono ridurre il lavoro ripetitivo senza sostituire il giudizio tecnico.

Il problema è che “assistito dall'AI” copre un ampio spettro. Un progetto potrebbe usare un modello per spiegare un'ottimizzazione del compilatore dopo ore di analisi manuale. Un altro potrebbe accettare grandi patch generate senza comprenderne il comportamento. Entrambi possono avere la stessa etichetta.

Anche le prove presenti nei repository sono incomplete. Un progetto può dichiarare l'uso di modelli nella documentazione, nei metadati dei commit o nelle note dei contributori. Un altro può ometterlo del tutto. Il codice scritto da esseri umani può essere scadente, mentre il codice generato può ricevere un'attenta revisione. Un semplice distintivo sì-o-no non può stabilire la qualità.

La moderazione dipenderebbe quindi da giudizi soggettivi su intenzioni, competenza e assistenza accettabile. Street sostiene che decidere quali progetti meritino visibilità non dovrebbe diventare la responsabilità di un singolo appassionato. Qualsiasi politica di esclusione inviterebbe a controversie sia da parte dei sostenitori dell'AI sia dei suoi critici.

Un divieto mancherebbe inoltre la debolezza più profonda del sistema. La classifica misurava il progresso del matching, non manutenibilità, attribuzione, documentazione, test o supporto a lungo termine. Persino una rilevazione perfetta del codice generato dall'AI non renderebbe una singola percentuale rappresentativa di tutte queste qualità.

Street ha invece rimosso la superficie competitiva. Si tratta di un intervento più circoscritto rispetto al controllo di ogni repository, ma prende di mira l'incentivo creato da decomp.dev stesso. Senza una classifica pubblica, i partecipanti ricevono meno ricompense a livello di piattaforma per spingere un numero verso l'alto prima che il loro lavoro sia pronto.

La scelta ricorda un modello di moderazione familiare. Quando una piattaforma non può classificare in modo affidabile ogni contributo discutibile, può ridurre la visibilità della metrica che incoraggia tali contributi. Questo approccio sacrifica i vantaggi della scoperta per proteggere le norme della comunità.

Ammette anche una dura verità sulla collaborazione aperta. L'apertura fornisce il materiale che permette ai nuovi arrivati di imparare, verificare i risultati e costruire sul lavoro precedente. La stessa apertura consente a un fork opportunistico di assorbire anni di conoscenza accumulata e spingere i suoi maintainer verso un traguardo più commercializzabile.

L'AI comprime questo secondo percorso. Può trasformare la cronologia di un repository, funzioni parzialmente abbinate, documentazione e discussioni sulle issue in contesto per una generazione rapida. Il codice risultante richiede comunque validazione, ma produrre qualcosa che sembri finito diventa più facile.

Questo non rende ostile ogni fork. Il forking resta una salvaguardia importante quando i maintainer scompaiono o i progetti rifiutano cambiamenti utili. Le implementazioni indipendenti possono anche testare approcci tecnici diversi.

Il comportamento contestato è più specifico. Consiste nell'usare il lavoro incompiuto di un altro team per rivendicare il completamento, attirare attenzione o distribuire un porting contribuendo poco allo sforzo originale. L'AI riduce il tempo e la competenza necessari per tentare questa manovra.

La decisione di decomp.dev evita quindi di presentare la disputa come esseri umani contro macchine. Il suo conflitto principale è tra ricerca accurata e teatro del completamento. L'AI conta perché rende il teatro più rapido, economico e facile da scalare.

L'impatto dell'AI sulla decompilazione dei giochi va oltre un codice più rapido

L'AI cambia il significato del progresso quando una percentuale di completamento non riflette più un processo di ricerca comune.

Il modello originale di decomp.dev gamificava la pazienza. I contributori potevano osservare un progetto difficile avanzare in piccoli incrementi, sapendo che ogni miglioramento aveva superato controlli di compilazione e matching. Il tabellone trasformava lavoro tecnico invisibile in un segnale condiviso.

Quel meccanismo funzionava finché il progresso restava scarso. La scarsità rendeva significativo ogni incremento. I contributori dovevano comprendere abbastanza bene il programma di destinazione, il compilatore, l'architettura e il progetto circostante da produrre codice che soddisfacesse rigorosi requisiti di matching.

L'AI non elimina necessariamente tali requisiti. Il codice macchina corrisponde al target oppure no. Tuttavia, un modello può generare e rivedere rapidamente molti candidati, soprattutto quando un essere umano fornisce l'output degli strumenti e circoscrive il compito.

Street afferma che questo approccio guidato può accelerare la decompilazione “in modo significativo”. Il cambiamento importante non è che la correttezza diventi improvvisamente facoltativa. È che il percorso verso un risultato corretto può comportare molta meno ricostruzione umana diretta.

Questo rende ambigua la percentuale. Può ancora descrivere quanta parte del codice corrisponde, ma dice meno sul modo in cui i contributori sono arrivati a quel punto. I lettori potrebbero inferire una profondità di comprensione, documentazione o revisione che il numero non ha mai garantito.

L'ambiguità cresce quando “decompilazione” diventa una scorciatoia per “porting PC”. Un progetto di decompilazione ricostruisce e studia principalmente il codice di un gioco. Un source port adatta il codice ricostruito per eseguirlo su un'altra piattaforma. La ricompilazione statica traduce il codice macchina in anticipo, spesso arrivando a un risultato giocabile senza produrre lo stesso tipo di sorgente leggibile.

Questi percorsi possono sovrapporsi, ma non sono intercambiabili. Una decompilazione completa con matching può esistere senza un porting facile da usare. Una ricompilazione statica può produrre una build giocabile senza ricreare codice sorgente leggibile funzione per funzione.

Street sostiene che le comunità di decompilazione abbiano storicamente posto l'accento sulla ricerca. Gli sviluppatori vogliono capire come funzionano i giochi, recuperare decisioni progettuali, documentare sistemi datati ed esporre dettagli tecnici che gli studi originali non hanno mai pubblicato.

I porting restano un risultato prezioso. Possono migliorare la compatibilità, supportare display moderni, abilitare modifiche e mantenere utilizzabili i giochi più vecchi sull'hardware attuale. Il conflitto emerge quando il porting visibile diventa l'unico risultato che il pubblico valorizza.

I progetti basati sulla ricompilazione statica offrono ora un modello diverso. La directory recomps.wtf distingue la decompilazione dalla ricompilazione statica e chiede ai progetti di dichiarare il coinvolgimento dell'AI. Le sue pagine descrivono se l'AI abbia aiutato a denominare funzioni, preparare strumenti di traduzione o controllare il lavoro.

Questo modello incentrato sulla divulgazione non risolve il controllo qualità, ma conserva informazioni che una singola classifica nasconde. I lettori possono valutare un progetto in base al metodo, allo stato, alle piattaforme supportate, alle release e alla documentazione anziché a un'unica percentuale universale.

L'impatto più ampio dell'AI sulla decompilazione dei giochi è quindi istituzionale. Le comunità hanno bisogno di nuovi modi per rappresentare il lavoro dopo che l'automazione ne modifica il costo. Una metrica progettata per lo sforzo manuale può rimanere tecnicamente accurata pur diventando socialmente fuorviante.

I team software al di fuori del retrogaming affrontano lo stesso problema. Righe modificate, issue chiuse, test generati e ticket completati sono facili da contare. L'AI può gonfiare ciascun numero senza fornire comprensione o affidabilità proporzionali.

La risposta non è nascondere tutti i dati sulla produttività. È affiancare alle metriche di output prove su revisione, profondità dei test, provenienza, manutenzione e comportamento nel mondo reale. I team che preservano tali evidenze possono costruire un archivio ingegneristico consultabile invece di affidarsi a meri conteggi dell’attività.

L’esperienza di decomp.dev mostra cosa accade quando il significato sociale di una metrica cambia più rapidamente dell’interfaccia che la visualizza. Il numero continua a muoversi, ma la comunità non concorda più su cosa debba significare quel movimento.

La vera sfida è tra ricerca accurata e visibilità incentrata sulle port

Una port approssimativa può conquistare attenzione in poche ore, mentre la ricerca che rende possibili port durature può richiedere anni e rimanere in gran parte invisibile.

La decompilazione di giochi seguiva un tempo una sequenza relativamente chiara. I ricercatori ricostruivano il codice, documentavano il comportamento e producevano gradualmente una base sorgente corrispondente. Gli sviluppatori di port potevano poi adattare quella base ai sistemi moderni.

La ricompilazione statica ha indebolito quella sequenza, rendendo possibile ottenere un risultato giocabile prima. L’AI la indebolisce ulteriormente, aiutando sviluppatori meno esperti a generare rapidamente glue code, livelli di piattaforma, script di build e patch.

Questa velocità crea un valore reale. Più giocatori possono tornare a giochi che gli editori non supportano più. Gli sviluppatori possono testare le idee prima e i nuovi arrivati curiosi possono partecipare senza padroneggiare ogni dettaglio prima di iniziare.

Tuttavia, la prima build giocabile non equivale a una release affidabile. Una port deve gestire input, audio, tempistiche, rendering, salvataggi, differenze tra piattaforme e stati di gioco insoliti. I problemi possono restare nascosti quando i test si concentrano sul raggiungere il gameplay o sul registrare un trailer.

Un rapporto di luglio sul campo di battaglia delle port ha documentato questa tensione attorno a Donkey Kong 64. Sviluppatori esperti della comunità hanno criticato un progetto concorrente fortemente basato sull’AI e avviato un’altra ricompilazione sostenuta da una conoscenza pluriennale del gioco.

Il disaccordo non riguardava semplicemente il fatto che un modello avesse toccato il codice. I critici sostenevano che modifiche poco comprese sarebbero diventate più difficili da mantenere e avrebbero potuto produrre bug gravi. La loro preoccupazione verteva sulla proprietà del progetto dopo la release iniziale.

Il codice generato può essere testato, revisionato e mantenuto come qualsiasi altro contributo. Il rischio aumenta quando chi lo accetta non sa spiegarne il comportamento. Le correzioni future richiedono allora di comprendere sia il gioco originale sia un’implementazione generata le cui ipotesi non sono mai state documentate.

La visibilità premia un insieme diverso di competenze. Un progetto con annunci frequenti, rapidi guadagni percentuali e video coinvolgenti può dominare la discussione prima che gli specialisti completino un audit. Quando emergono i fallimenti, il pubblico potrebbe già associare quel progetto al completamento del gioco.

Ecco perché una classifica non è neutrale. Dirige l’attenzione verso ciò che misura. Quando classifica il completamento, i contributori sentono la pressione di completare. Quando il pubblico equipara il completamento a un’imminente port per PC, i manutentori subiscono la pressione di produrre gameplay visibile.

Street descrive questa progressione come un vuoto gioco di numeri. L’espressione individua un fallimento degli incentivi, non una semplice avversione estetica verso il codice generato dall’AI. I partecipanti ottimizzano il punteggio perché il punteggio controlla l’attenzione.

Il modello complica anche l’attribuzione dei meriti. Un nuovo fork può mostrare rapidi progressi solo perché un team precedente ha mappato i formati dei file, assegnato nomi alle funzioni, documentato gli strumenti di build e risolto problemi del compilatore. L’accelerazione visibile del fork può celare il lavoro ereditato che la sostiene.

Le licenze open source stabiliscono permessi legali, ma le comunità sane dipendono da norme che le licenze non codificano pienamente. Tali norme includono attribuzione, comunicazione, rispetto per i manutentori e l’impegno a restituire i miglioramenti a monte.

Un fork tecnicamente consentito può comunque danneggiare la cooperazione se presenta un lavoro condiviso come una gara individuale. Al contrario, un fork ben gestito può preservare una ricerca abbandonata o esplorare una direzione che i manutentori originali non desiderano seguire.

La distinzione richiede contesto. È proprio ciò che la classifica non poteva esprimere. Collocava i progetti in un quadro comparativo senza mostrare abbastanza della loro origine, degli standard di revisione, delle relazioni tra progetti o dei risultati previsti.

Rimuovere l’indice non ripristina la vecchia sequenza. I progetti assistiti dall’AI e le port rapide continueranno a comparire. Anche directory alternative competeranno per diventare il luogo in cui i giocatori le trovano.

La chiusura della classifica AI di decomp.dev fa qualcosa di più modesto. Rifiuta di lasciare che un rispettato servizio della comunità trasformi forme di lavoro incompatibili in un’unica gara.

Cosa non dimostra la chiusura sull’AI slop

La chiusura sostiene una critica degli incentivi, ma non dimostra che tutta la decompilazione assistita dall’AI sia inaccurata o indesiderata.

“AI slop” è un’etichetta emotivamente forte priva di una definizione tecnica stabile. Può descrivere codice generato non revisionato, presentazioni di scarso impegno, affermazioni fuorvianti, un volume eccessivo di release o semplicemente un lavoro che a un critico non piace.

Street riconosce questo problema di moderazione. Lo slop appare in forme diverse ed è difficile da definire con coerenza. La scelta degli strumenti di un progetto non può sostituire l’esame del suo codice, dei test, della documentazione e delle pratiche di manutenzione.

Anche le prove attuali sono in gran parte qualitative. Le lamentele pubbliche identificano fork ostili, port approssimative e comportamenti finalizzati a catturare attenzione. Non forniscono un tasso di fallimento completo che confronti progetti scritti da esseri umani e progetti assistiti dall’AI.

Questa lacuna conta. Un’analisi accurata non dovrebbe trasformare la decisione di un leader della comunità in una prova che l’AI non possa contribuire al reverse engineering. La stessa dichiarazione di Street respinge questa conclusione, riconoscendo un’accelerazione significativa sotto la guida di esperti.

Né un progresso più rapido rende automaticamente vuoto un risultato. Uno sviluppatore che usa l’automazione per eliminare il lavoro ripetitivo di matching può dedicare più tempo alla ricerca dell’architettura, alla convalida del comportamento e alla documentazione delle scoperte.

L’automazione è sempre stata parte della decompilazione. Strumenti di diff, disassembler, decompiler, compiler explorer e script riducono già il lavoro manuale. La nuova preoccupazione riguarda il modo in cui i sistemi generativi modificano scala, accessibilità e rapporto tra output e comprensione.

Esiste anche un punto di vista opposto legittimo. Spesso i giocatori si preoccupano più del funzionamento di una port che del modo in cui gli sviluppatori l’hanno prodotta. Se una build assistita dall’AI funziona accuratamente, rispetta le licenze del progetto, attribuisce i meriti al lavoro precedente e riceve supporto continuativo, molti utenti vedranno pochi motivi per respingerla.

Allo stesso modo, alcuni sviluppatori sostengono che revisori esperti possano usare l’AI senza rinunciare al controllo. Un modello può proporre codice, mentre test e giudizio umano stabiliscono se entrerà nel progetto. In questo flusso di lavoro, l’AI diventa un altro strumento fallibile.

Il caso più solido contro i progetti fortemente basati sull’AI non può quindi fondarsi sulla purezza. Deve indicare fallimenti osservabili, quali crash, comportamento inaccurato, problemi di sicurezza, attribuzione mancante, codice non manutenibile o false affermazioni sul completamento.

La discussione nella comunità dopo l’avviso rivela anche disaccordi sullo scopo della decompilazione. Alcuni partecipanti attribuiscono valore alla ricerca e alla conservazione. Altri usano apertamente i tracker dei progetti per stimare quando potrebbe arrivare una port per PC giocabile.

Nessuno dei due pubblici scomparirà perché decomp.dev rimuove il suo indice. La chiusura espone invece un problema di comunicazione tra loro. La stessa barra di avanzamento sosteneva due aspettative diverse.

Per i ricercatori, rappresentava conoscenza recuperata e codice corrispondente. Per gli spettatori interessati alle port, sembrava un conto alla rovescia per giocare su nuovo hardware. L’AI ha ampliato il divario rendendo i risultati giocabili disponibili prima e più spesso.

Le questioni legali restano separate e specifiche per ciascun caso. I progetti di reverse engineering evitano comunemente di distribuire risorse di gioco protette da copyright e richiedono agli utenti di fornire la propria copia. Questa impostazione non garantisce una protezione automatica a ogni progetto o implementazione.

Le directory alternative stanno già sperimentando regole più esplicite. Il modello di divulgazione dei progetti etichetta il lavoro assistito dall’AI e spiega i metodi tecnici. Sistemi simili offrono ai lettori più contesto, ma la loro efficacia dipende da autodichiarazioni accurate e da una moderazione attiva.

La conclusione scettica è diretta. decomp.dev ha documentato un fallimento di governance della comunità, non uno studio controllato sulla qualità del software. La sua risposta merita attenzione perché il sito occupava una posizione centrale, non perché risolva ogni dibattito sul codice generato dall’AI.

Tre segnali mostreranno se la comunità può ricostruire la fiducia

La prossima fase dipende dal fatto che i progetti sostituiscano il prestigio basato sulla velocità con prove trasparenti di qualità, origine e manutenzione continuativa.

Il primo segnale è se gli indici alternativi adotteranno informative significative sui progetti. Un elenco utile dovrebbe distinguere tra decompilazione con matching, port del sorgente e ricompilazione statica. Dovrebbe inoltre descrivere l’uso dell’AI, le relazioni a monte, lo stato dei test e la maturità della release.

Le etichette da sole non basteranno. “Assistito dall’AI” può coprire un commento generato o gran parte di una base di codice. Informative migliori spiegheranno cosa ha prodotto il modello, chi lo ha revisionato e come i manutentori hanno verificato il risultato.

Se le directory convergeranno su informative dettagliate, la decisione di Street apparirà come un ripristino che ha incoraggiato una misurazione migliore. Se ricreeranno una gara di completamento classificata con qualche badge aggiunto, gli stessi incentivi torneranno sotto un nuovo dominio.

Il secondo segnale è il modo in cui i fork più visibili interagiscono con i progetti da cui hanno ereditato. Occorre osservare attribuzioni chiare, pull request a monte, monitoraggio condiviso delle issue e comunicazione con i manutentori originali.

Un fork che restituisce correzioni e documenta le proprie differenze può rafforzare un progetto aperto. Un fork che sembra esistere solo per rivendicare il completamento, catturare attenzione e abbandonare la manutenzione rafforzerà le preoccupazioni sulle gare di port assistite dall’AI.

La cronologia del repository offre prove più utili dei video promozionali. Correzioni regolari, build riproducibili, risposte dettagliate alle issue e contributi revisionati mostrano se un team comprende ciò che ha pubblicato.

Il terzo segnale è la qualità dopo la release. Le port fortemente basate sull’AI affronteranno il loro test più severo quando gli utenti andranno oltre la sequenza iniziale. L’accuratezza tra salvataggi, meccaniche sensibili al tempismo, scene rare, controller, hardware grafico e sistemi operativi conterà più della velocità di lancio.

Anche le distinzioni tecniche tra decompilazione, ricompilazione e port diventeranno importanti quando gli utenti segnaleranno problemi. Un bug può avere origine nel codice di gioco tradotto, in un livello di piattaforma, in un componente derivato da un emulatore o in un miglioramento aggiunto dalla port.

I progetti in grado di diagnosticare tali livelli conquisteranno fiducia. I progetti i cui manutentori non sanno spiegare la propria implementazione faranno fatica quando il codice generato incontrerà casi limite sconosciuti.

Questi segnali possono rafforzare o indebolire la tesi alla base della chiusura. Informative migliori, fork costruttivi e release durature dimostrerebbero che le comunità possono assorbire l’AI senza abbandonare la qualità. Dispute ricorrenti sui meriti e port non funzionanti confermerebbero l’avvertimento di Street: gli incentivi attuali premiano i risultati sbagliati.

La chiusura della classifica AI di decomp.dev è in definitiva una decisione di governance. Street non ha disabilitato l’AI, chiuso ogni repository o dichiarato che l’assistenza automatizzata non abbia alcun ruolo legittimo. Ha ritirato un tabellone dopo che i suoi numeri hanno smesso di rappresentare i valori che era stato creato per celebrare.

Sviluppatori e utenti hanno ora una scelta concreta. Possono valutare i progetti in base a chi ha concluso per primo, oppure esaminare come il lavoro è stato realizzato, testato, attribuito e mantenuto. Nei prossimi mesi, quali prove conteranno più della prossima dichiarazione di completamento al 100 per cento?