Copland è un sistema operativo che Apple annunciò, finanziò e mostrò prima di riuscire a decidere che cosa dovesse davvero essere. Il progetto non arrivò mai sul mercato: tra il 1994 e il 1996 accumulò ritardi, funzioni, squadre e costi fino a diventare impossibile da integrare. Il suo fallimento lascia una lezione molto più utile della semplice cronaca: quando un progetto risponde a ogni ritardo aggiungendo qualcosa, smette di avanzare e comincia a gonfiarsi.
Copland non fallì perché Apple non avesse ingegneri capaci. Fallì perché il product management non riuscì a stabilire un confine e il project management non riuscì a difenderlo. Ogni componente poteva avere una ragione tecnica, ogni team poteva rivendicare un contributo importante, ogni nuova promessa poteva sembrare un modo per rendere accettabile una scadenza spostata. Alla fine, però, il prodotto era diventato la somma delle sue ambizioni, non una cosa che qualcuno potesse davvero consegnare.
Indice
Il punto di partenza era già un conflitto
Apple aveva un problema reale. Il System 7 del Macintosh conservava un’architettura adatta a un’epoca diversa: memoria condivisa, multitasking cooperativo e una dipendenza enorme dal comportamento delle singole applicazioni. Un errore in un programma poteva compromettere l’intero sistema. Il passaggio ai PowerPC rendeva ancora più urgente una base software capace di sfruttare meglio l’hardware.
Copland nacque nel 1994 con un obiettivo ambizioso: costruire un sistema operativo moderno, capace di competere contro Windows 95, senza abbandonare il mondo Mac esistente. Il progetto prevedeva memoria protetta, multitasking preemptive, cioè la possibilità per il sistema di interrompere un processo e dare tempo agli altri invece di lasciare che ogni applicazione decidesse da sola, e un’architettura basata sul microkernel NuKernel, codice nativo PowerPC e la compatibilità con le applicazioni scritte per System 7. La ricostruzione tecnica di Copland) mostra bene la difficoltà: non si trattava di aggiungere un pannello di controllo, ma di cambiare le fondamenta mantenendo in piedi la casa.
Questa tensione non rendeva il progetto impossibile in assoluto. Rendeva indispensabile una scelta di prodotto: quali obiettivi dovevano entrare nella prima versione e quali potevano aspettare? Apple, invece, iniziò a comportarsi come se ogni obiettivo fosse parte dello stesso rilascio.
Ogni squadra aveva una ragione per aggiungere qualcosa
Il feature creep non nasce sempre da una richiesta assurda. Spesso nasce da richieste ragionevoli che nessuno riesce a respingere. Copland doveva offrire un Finder più moderno, una gestione più solida dei processi, nuove funzioni di ricerca, supporto per più utenti, temi grafici e un’esperienza coerente con il salto generazionale dell’hardware.
Il problema arrivò quando ogni gruppo iniziò a considerare il proprio pezzo indispensabile per il successo dell’intero sistema.
Gil Amelio descrisse Copland come «una collezione di pezzi separati, ciascuno lavorato da una squadra diversa, che ci si aspettava si unissero magicamente».
Una funzione già sviluppata sembrava troppo preziosa per essere rimandata. Un’altra serviva a giustificare il nuovo framework. Un’altra ancora diventava il motivo per cui il rilascio non poteva essere più piccolo. Il perimetro cresceva senza che esistesse una decisione equivalente su ciò che sarebbe stato tagliato.
La frase individua il problema esatto: non mancavano singoli componenti, mancava un prodotto integrato che avesse la precedenza sui componenti.
La ricostruzione storica di The Long View mostra quanto materiale fosse confluito nel progetto: sistema operativo, Finder, interfaccia, filesystem, compatibilità, servizi e una lunga serie di idee che Apple continuava a presentare come parte del futuro del Mac. Il progetto non aveva più soltanto una roadmap. Aveva una collezione di desideri con una data di consegna attaccata sopra.
Il calendario diventò una narrazione
Nel 1995 Apple mostrò Copland a sviluppatori e stampa, alimentando l’aspettativa di un rilascio vicino. Una prima versione beta arrivò a un gruppo ristretto di sviluppatori nel novembre di quell’anno, ma non rappresentò l’inizio di una discesa ordinata verso il prodotto finale. La data promessa slittò, prima verso il 1996 e poi verso il 1997, mentre il progetto continuava a ricevere nuove funzioni.
Qui compare uno dei meccanismi più pericolosi nella gestione dei progetti: il ritardo crea pressione, la pressione spinge a promettere qualcosa di più, la promessa aggiuntiva richiede altro lavoro e quel lavoro produce un nuovo ritardo. La ricostruzione di Cult of Mac descrive proprio questa dinamica: Apple aggiungeva funzioni per rendere più accettabile il tempo ormai speso, ma quelle funzioni rendevano ancora più lontana la consegna.
Il calendario, a quel punto, non serviva più a organizzare il lavoro. Serviva a raccontare che il progetto era ancora vivo. Una data spostata poteva essere presentata come prudenza. Un nuovo obiettivo poteva essere presentato come ambizione. Una demo poteva sostituire una release. Il linguaggio cambiava, ma il prodotto non diventava più vicino.
Un progetto sano usa le milestone per scoprire presto che cosa non funziona. Copland le trasformò in appuntamenti con la comunicazione: ogni scadenza mancata produceva una nuova spiegazione, non una riduzione dello scope.
Più persone non significano più controllo
Nel 1996, secondo le ricostruzioni disponibili, circa 500 ingegneri lavoravano a Copland e il budget annuale avrebbe raggiunto circa 250 milioni di dollari. Il numero dei 500 milioni circola spesso quando si racconta il progetto, ma non è una cifra contabile ufficiale univoca: le fonti distinguono tra budget annuale, costo complessivo e stime di ricostruzione. La differenza non è un dettaglio: anche il racconto dei costi deve rispettare la disciplina che Copland non ebbe.
Il punto manageriale resta comunque netto. A un certo livello di spesa, aggiungere persone non risolve più il problema. Aumenta il numero delle dipendenze, delle interfacce, delle decisioni e dei conflitti da coordinare. Se l’architettura non è integrata e il perimetro non è protetto, un’organizzazione più grande può produrre più codice senza produrre un prodotto più vicino.
Il costo vero non era soltanto il denaro. Era l’illusione che un investimento già enorme obbligasse Apple a continuare. Il progetto aveva assorbito così tante risorse da rendere psicologicamente difficile dire: «Questa strada non porta alla consegna». Così il budget passato diventava una ragione per investire ancora, invece di una ragione per valutare con freddezza se fermarsi.
Un buon sistema di governance avrebbe dovuto fissare soglie precise: una data entro cui dimostrare un nucleo funzionante, un numero massimo di funzioni nella prima release, criteri di stabilità, una decisione obbligatoria in caso di mancato raggiungimento. Senza soglie, ogni revisione diventa una trattativa e ogni trattativa tende a salvare il lavoro già fatto.
Il product management aveva smesso di scegliere
La domanda che il progetto non si fece
La differenza tra un progetto complesso e un progetto fuori controllo non è il numero delle funzioni. È la presenza di una gerarchia tra quelle funzioni.
Il product management avrebbe dovuto rispondere a una domanda semplice e scomoda: qual è il problema che Copland deve risolvere per primo? Se la risposta era la stabilità del Mac, la prima versione doveva proteggere memoria, processi e compatibilità con uno scope ridotto. Se la risposta era il rilancio dell’immagine del sistema operativo, non si poteva contemporaneamente pretendere una riscrittura profonda dell’architettura, un nuovo Finder, un ambiente multiutente, una personalizzazione grafica estesa e una compatibilità quasi totale.
Il project management, dal canto suo, avrebbe dovuto trasformare quella scelta in un piano verificabile: componenti integrati presto, demo tecniche che non fossero soltanto scenografie, responsabilità chiare e una lista esplicita di ciò che non sarebbe entrato nella prima versione.
Copland dimostra che «non ora» è una decisione di prodotto, non un fallimento. Il fallimento arriva quando nessuno pronuncia quelle due parole e il progetto prova a essere tutto contemporaneamente.
La lezione di Copland vale più della sua fine
La lezione non è che i grandi progetti debbano essere piccoli. È che devono avere un ordine. Un’organizzazione può affrontare un cambiamento tecnico enorme, ma deve separare la fondazione dal resto: prima un nucleo funzionante, poi le funzioni che lo rendono completo.
Da Copland si possono ricavare almeno cinque regole pratiche:
- definire una prima versione che abbia senso da sola: non una raccolta di componenti in attesa del futuro;
- congelare lo scope prima che il ritardo diventi un incentivo ad aggiungere: una nuova funzione deve sostituirne un’altra, non sommarsi a tutte;
- integrare presto e spesso: i componenti devono convivere quando è ancora possibile cambiare architettura;
- misurare il progresso sul prodotto funzionante: non sul numero di team, demo, documenti o funzionalità dichiarate;
- stabilire in anticipo quando fermarsi: cancellare un progetto non cancella il lavoro già fatto, ma può impedire che altro lavoro venga sprecato.
La parte più difficile riguarda l’ultima regola. Fermare un progetto significa ammettere che la decisione iniziale non era più difendibile. Le organizzazioni preferiscono spesso spostare la data, cambiare il nome della fase o promettere una versione successiva. Copland mostra il costo di questa prudenza apparente.
Un fallimento può lasciare una strada migliore
Copland venne cancellato nel 1996. Alcune sue componenti confluirono in Mac OS 8, ma la strategia per il sistema operativo successivo cambiò. Apple cercò una base già più solida, arrivò a NeXTSTEP e da quella scelta nacque il percorso che avrebbe portato a Mac OS X.
La storia del passaggio dal Classic OS a OS X è raccontata anche nella ricostruzione pubblicata su melamorsicata.it. Quel collegamento è una conseguenza, non la morale della vicenda: la decisione importante fu riconoscere che continuare Copland non aumentava più le probabilità di arrivare a un prodotto.
Apple cambiò strada solo quando smise di finanziare l’idea di portare al termine tutto. La lezione di Copland è semplice: un progetto si salva prima con i tagli che con le aggiunte.