I meccanismi di sviluppo di OS X per la prima volta sono stati esposti nella loro logica. A presentare alcuni dettagli del percorso di creazione del sistema operativo è stato Ryan Nielsen, cofondatore di Tumult (società nota a molti per Hype, software per le animazioni HTML5) ed ex membro senior del Mac OS X Project Management team, che ha parlato dell’argomento nel podcast Debug, intervistato dallo sviluppatore Guy English.
Nielsen – un personaggio importante nella storia di OS X, poiché ha guidato lo sviluppo del sistema operativo di Apple dal 2004 al 2010 – ha spiegato che “Il team di OS X aveva il potere decisionale su tutto ciò che concerne il sistema operativo”; “questo almeno fino all’arrivo di iPhone, il quale ha reso necessario compartimentalizzare in modo più rigoroso alcune funzioni”. “Il project manager non doveva pensare se il sistema poteva essere rilasciato o no, ma doveva uscire e basta”.
“Il project manager è spesso visto come un “hub”, ma in realtà è il collante che tiene uniti gli elementi di tutta la società”; “Quando individua un problema nei livelli inferiori del sistema, deve mobilitare le risorse per affrontare l’inconveniente prima possibile, fornendo una nuova build del sistema ai team che lavorano su applicazioni di più alto livello”. “Se un team è in ritardo, deve stimare il rallentamento, decidere se rimandare il problema, assegnare il compito ad altre squadre o rinviare la funzione ad altra data”. “In poche parole è una sorta di direttore d’orchestra che ha la visione d’insieme dello sviluppo in corso, permettendo ai vari team di lavorare isolatamente. È il canale di comunicazione tra le squadre, ma anche il loro leader; è il responsabile in casi d’intoppi e deve essere in grado di trovare soluzioni per sbloccare imprevisti”.
Lo sviluppo di OS X segue un percorso “naturale”, strutturalmente lento, un meccanismo che permette di prendere decisioni in modo pragmatico, caso per caso. Fino a OS X 10.7 Lion, OS X è stato pensato tenendo in mente alcuni “temi” o “una serie di obiettivi” previsti dal management, dal marketing o dagli ingegneri. Prese le decisioni, ad esempio definito cosa integrare in Snow Leopard, tutte le squadre hanno un unico scopo: pulire e ottimizzare il sistema. Dettagli in fase d’implementazione possono anche cambiare: il team che si è occupato della tecnologia Grand Central Dispatch (per ottimizzare l’esecuzione delle applicazioni su sistemi multi core o su sistemi basati sul multiprocessing simmetrico) è stato spesso chiamato a occuparsi di altri compiti, ed è stato autorizzato a fermare momentaneamente alcune funzionalità. “Dobbiamo comprendere che la realtà richiede a volte il mancato rispetto delle regole, l’accettazione di compromessi, il rivedere al ribasso gli obiettivi” dice Nielsen; “il risultato finale è forse inferiore a quello inizialmente immaginato, ma per altri versi migliore”.
Questa relativa libertà e l’architettura generale di OS X, permettono agli ingegneri di attuare cambiamenti rapidi. Non solo i team che si occupano del software hanno feedback immediato sul proprio lavoro, ma altri team possono immediatamente verificare l’assenza di problemi ai loro prodotti e viceversa. Il sistema di gestione delle versioni è sufficientemente robusto per applicare cambiamenti quando necessario o rimuovere funzionalità quando si stabilisce che queste devono essere riservate a futuri sistemi.
Il meccanismo rallenta con l’avvicinarsi dei keynote: tutto comincia a prendere forma e possibili fonti d’instabilità non devono essere introdotte nel sistema. Compito del project manager è scegliere la build di sistema stabile e completa da utilizzare per le dimostrazioni; se una funzione critica è in ritardo, deve essere controllata in dettaglio dagli ingegneri responsabili e questi devono assicurare condizioni di funzionamento accettabili, senza ovviamente introdurre instabilità nel sistema. I team che si occupano di iLife e iWork sono indipendenti da quelli che si sviluppano OS X; non lo sono, invece, quelli che si occupano di Safari, Mail e iTunes.
Con la disponibilità annuale di nuove versioni di OS X, le modalità di sviluppo del sistema sono cambiate. Nielsen ha lasciato Apple ma vari meccanismi sono rimasti invariati. Vincolato probabilmente da accordi di non divulgazione, e pesando con attenzione a quanto dice, afferma che OS X si sta avvicinando alle rolling release (meccanismo di aggiornamento continuo che non richiede installazioni per un rilascio successivo della distribuzione), un sistema che permetterà un’unica installazione e meccanismi di aggiornabilità a tempo indeterminato.
Alcune funzioni hanno richiesto fino a tre anni per la completa implementazione. Pensiamo ad esempio a iCloud: Apple ha pian piano integrato nuove funzionalità, avvicinandosi sempre più alla meta prevista. In Lion e Mountain Lion, abbiamo da questo punto di vista, avuto a disposizione versioni intermedie di quanto sarà offerto con OS X 10.9 Mavericks.
L’approccio di Apple è radicalmente diverso da quello seguito da Microsoft. Nielsen fa l’esempio di WinFS (Windows Future Storage), il sistema di storage basato sui database relazioni che Microsoft intendeva sviluppare per i suoi sistemi operativi: sulla carta una rivoluzione che però fu poi necessario abbandonare. Microsoft non ha perseguito “il rifiuto delle regole, i compromessi, non ha voluto rivedere al ribasso i propri obiettivi”. In contrapposizione a WinFS, Apple ha risposto con SpotLight, una funzione del sistema operativo, meno ambiziosa rispetto a un nuovo file system ma, di fatto, una soluzione concreta e pratica alle problematiche che stava affrontando Microsoft. Ripensare all’HFS+ sarebbe stato molto più complesso, benché ci sia stato un momento nel quale Apple stava con interesse guardando al file system ZFS, strada ora completamente abbandonata (almeno secondo Nielsen). Cupertino è ad ogni modo riuscita a trovare nel frattempo soluzioni quali il Core Storage, meccanismo al di sopra del file system che ha aperto la strada alla tecnologia di memorizzazione Fusion Drive.
I meccanismi di sviluppo in Microsoft sono più rigorosi e pesanti. I cambiamenti proposti dagli ingegneri sono segnalati in repository locali (una metodologia che permette di indicare funzionalità delle quali non è ancora del tutto sicuri); dopo la verifica, si procede verso il livello successivo verificando quali cambiamenti comporta la modifica in questione, eseguendo di test e integrando eventualmente il tutto nel repoitory centrale e compilando alla fine una nuova build di Windows. Progressi e stabilità delle funzioni sono verificati nella loro interezza; i vari team devono testare le funzionalità, prima di dare il via alla compilazione di una nuova build. Prima che qualcuno riceva la build di Windows con la modifica richiesta, potrebbero essere necessari anche settimane o mesi.
Il procedimento usato da Microsoft è indubbiamente più rigoroso, quello di Apple è più flessibile. A detta di Nielsen anche Microsoft potrebbe ora aver scelto un modello più flessibile, conscia dei benefici che ciò comporta.
