Come è stato creato Linux? I processi dietro la gestione di 13.500 sviluppatori

Oggi probabilmente hai usato Linux – specialmente se non hai un iPhone. E se hai navigato sul web oggi, c’è una grande possibilità che anche il sito web che hai visitato sia stato servito da Linux.

Linux è un sistema operativo, ma a differenza di software come Microsoft Windows e macOS, Linux è stato sviluppato da una comunità auto-organizzata di volontari.

Nel tempo, con lo sforzo di oltre 10.000 sviluppatori e processi in evoluzione per gestire la portata del lavoro, il kernel di Linux è cresciuto fino a oltre 20.000.000 linee di codice in totale. Costituisce la base stabile per…

• Tutti i telefoni e tablet Android del pianeta
• 66% dei server del mondo
• 100% dei primi 500 supercomputer

Questa tecnologia non è venuta da un team orchestrato con un denso libro di politiche e strati di gestione. È venuta da poche politiche accuratamente scelte e culturalmente incorporate, e da una missione condivisa.

In questo post, guardo come una tecnologia così essenziale, complessa e importante possa essere stata prodotta così efficacemente senza una struttura di gestione tradizionale. Ma prima…

Perché il kernel di Linux è così impressionante?

Un kernel è il vero nucleo di un sistema operativo. È l’orchestratore di tutti gli altri processi software sul vostro computer o smartphone, dividendo le risorse e fornendo un modo per l’hardware e il software di comunicare.

Nelle parole di G. Pascal Zachary, il kernel di un sistema operativo può essere paragonato a “un capo del personale domestico che era così diligente da servire la famiglia ai piani alti in qualsiasi momento, notte e giorno su chiamata, gestendo ogni richiesta”. Il kernel mantiene la macchina in funzione, indipendentemente da ciò che incontra. È stato un salto essenziale dal mondo in cui i computer potevano eseguire solo un’applicazione alla volta, al mondo che conosciamo oggi.

Il kernel Linux, basato su UNIX, è stato sviluppato nei primi anni ’90 da Linus Torvalds.

Nel 1991, Torvalds aveva rilasciato la prima versione – solo 10.000 linee di codice – e scatenato l’eccitazione nella comunità di sviluppo del software con l’umile annuncio via e-mail che si vede qui sopra.

Potenziati dal potere collaborativo di internet per la prima volta nella storia, gli sviluppatori hanno contribuito con le loro capacità di codifica e il tempo di prova gratuitamente, mentre la base di utenti del kernel esplodeva in dimensioni. Se erano disposti a sperimentare, gli utenti potevano provare a mettere insieme una patch se trovavano qualcosa di rotto, e discutere su come migliorare il software.

Come Eric S. Raymond vede nel suo libro sui primi software open source, The Cathedral and The Bazaar, la gestione di Linus Torvalds degli sviluppatori del kernel crebbe fino a diventare efficiente, auto-organizzata e più che capace di produrre probabilmente uno dei pezzi di software più complessi e ampiamente utilizzati sul pianeta.

In questo pezzo, esamino i processi e le politiche che sono emersi come supporto necessario per il progetto del kernel Linux, come si è evoluto nel corso degli anni.

Come ha fatto Torvalds, senza un processo formale, quando era uno studente di informatica di 21 anni, a guidare il progetto del kernel alle vette che ha raggiunto…

…E comunque, cosa c’è di così difficile nel gestire gli sviluppatori?

Secondo una ricerca di Geneca, oltre il 75% dei dirigenti aziendali e IT crede che i loro progetti software siano destinati a fallire. La difficoltà di produrre software affidabile e di gestire coloro che lo fanno ha generato innumerevoli libri di management, studi sulla produttività e framework di leadership.

“La pura complessità del software significa che è impossibile testare ogni percorso”, scrive il CEO di Kynetix Paul Smyth su Finextra. “Un’applicazione software è come un iceberg – il 90% non è visibile. La maggiore complessità dell’applicazione si trova sotto la linea di galleggiamento”.

Ogni progetto software di dimensioni significative, che sia un CRM o un sistema operativo come Microsoft Windows, è troppo grande per entrare nella testa di una sola persona. Richiede la conoscenza condivisa e la collaborazione di molti collaboratori. Questo significa che gli sviluppatori lavorano su parti specializzate dell’applicazione mentre hanno bisogno di capire come il loro lavoro ha effetti sull’insieme.

“Nessuna mente può comprendere tutto”, ha osservato il manager di una squadra di 250 sviluppatori di software Microsoft mentre stavano costruendo un sistema operativo da zero, secondo G. Zachary in Show stoppers! un libro che racconta la storia di un team di sviluppatori di software Microsoft che correvano per completare Windows NT nel 1993.

Più grande è il progetto, più lentamente possono essere implementati i cambiamenti. Una ricerca di Steve McConnell lo dimostra, trovando che il codice viene scritto ad un ritmo 5-10 volte più lento su progetti di oltre 10.000.000 linee. Inoltre, uno studio sulle pratiche di sviluppo di Microsoft ha rivelato che ci sono circa 10-20 bug per ogni 1.000 linee di codice.

Nonostante le dimensioni del progetto e il numero di collaboratori, lo sviluppo del kernel Linux avviene rapidamente e la sua grande ed entusiasta base di utenti cattura i bug e scrive patch per spedire rapidamente i miglioramenti.

Nei suoi primi giorni di sviluppo – intorno al 1991 – non era insolito per Torvalds rilasciare più di un nuovo kernel al giorno. Ora, in una fase più matura e da cui dipende l’80% degli smartphone e la maggior parte dei server internet, il periodo di rilascio desiderato va dalle 8 alle 12 settimane. Ogni rilascio, il kernel vede una media di 10.000 patch da 2.000 sviluppatori – il tutto lottando con oltre 20.000.000 di linee di codice.

Quali sono le tecniche di gestione e i processi necessari per orchestrare questo livello di collaborazione e produttività? Beh, non sono stati scritti da un capo dipartimento o da un autore di libri di business. Si sono sviluppate organicamente, con la guida del “dittatore benevolo” del progetto, Linus Torvalds.

Anche nella sua forma nascente, il kernel Linux è stato collaborato da centinaia di volontari che hanno presentato il loro lavoro direttamente a Torvalds per la revisione. Come ha fatto un hacker irascibile e antisociale a gestire le dispute, i contributi e la comunicazione tra migliaia di sviluppatori per quasi due decenni?

Come sono documentati la politica, il processo e 15.000.000 di linee di codice

A differenza di un’organizzazione tradizionale, i nuovi sviluppatori del kernel non sono strettamente “integrati” nella comunità, ma ci si aspetta che abbiano letto e compreso completamente la documentazione introduttiva. L’attenzione del progetto kernel per la documentazione era una necessità sia per la complessità tecnica che per l’enorme numero di sviluppatori.

Numerose FAQ, how-tos e guide per iniziare esistono nel repository della documentazione del kernel, e ancora di più nei wiki creati e mantenuti dagli sviluppatori del kernel di tutto il mondo.

Il modo in cui la documentazione viene scritta e migliorata riflette il modo in cui il kernel viene sviluppato; in modo collaborativo, aperto e incrementale.

Sfruttando gli occhi e le specializzazioni di un enorme gruppo di persone, la documentazione può essere creata, testata e corretta in modo molto più efficiente che se fosse fatta da un piccolo team dedicato. Per piegare la legge di Linus in termini che un editore di contenuti potrebbe capire meglio: con abbastanza occhi, tutti gli errori di battitura sono ovvi

Oltre al materiale per il supporto tecnico, la comunità di sviluppo del kernel ha creato una libreria di documentazione di processo progettata per appianare il lato umano della collaborazione.

Nella pagina dell’indice di “A guide to the Kernel Development Process”, un paragrafo recita:

“Lo scopo di questo documento è di aiutare gli sviluppatori (e i loro manager) a lavorare con la comunità di sviluppo con un minimo di frustrazione. È un tentativo di documentare come funziona questa comunità in un modo che sia accessibile a coloro che non sono intimamente familiari con lo sviluppo del kernel Linux (o, in effetti, con lo sviluppo del software libero in generale).”

Nessuno nasce con una conoscenza innata del sistema di controllo della versione git, o come inviare una patch ad una mailing list. Ecco perché il processo di sviluppo deve essere documentato – spiegare le stesse informazioni di base ad una persona alla volta non è scalabile!

Come viene gestita la comunicazione tra migliaia di sviluppatori

Le conversazioni tra sviluppatori avvenivano all’aperto, nelle mailing list di sviluppo del kernel. Ancora oggi, l’e-mail è lo strumento preferito per la sua semplicità. Queste mailing list venivano archiviate e organizzate, formando un corpo di documentazione vivente e storia.

L’effetto di comunicare in pubblico ha un effetto simile ai benefici dell’uso di uno strumento come Slack oggi – ogni informazione è resa sicura e ricercabile, invece di evaporare. Per gestire una tale marea di informazioni, tuttavia, il progetto kernel ha sviluppato una politica di comunicazione e l’ha distribuita come parte della documentazione.

La comunicazione e la collaborazione su tale scala non era possibile prima di internet, così i primi progetti come questo avevano bisogno di scrivere e distribuire soluzioni rapide ed efficaci per la gestione della comunità, il galateo e i problemi di presentazione del codice.

La documentazione del kernel include regole per l’invio delle patch, in modo da rendere più facile per gli altri rivedere, modificare e testare il codice contribuito. Questo significa che le patch devono essere inviate via email in testo semplice, non allegate. Le patch devono essere contenute in una sola volta per email, e obbedire a specifiche linee guida di stile di codifica:

Questa rigida standardizzazione è assolutamente necessaria per un progetto grande come il kernel, come lo è per progetti di qualsiasi dimensione. Aiuta a ridurre gli errori in uno spazio dove un singolo errore può avere un effetto a catena che produce codice instabile in futuro, o fa perdere tempo a molti tester e sviluppatori.

Come vengono (non) prese le decisioni critiche

Per citare Torvalds:

“Il nome del gioco è evitare di dover prendere una decisione. In particolare, se qualcuno ti dice “scegli (a) o (b), abbiamo davvero bisogno che tu decida su questo”, sei nei guai come manager. Le persone che gestisci devono conoscere i dettagli meglio di te, quindi se vengono da te per una decisione tecnica, sei fregato. Non sei chiaramente competente per prendere quella decisione per loro”. – Linux Kernel Development Documentation

Oltre ad evitare una gerarchia manageriale, il progetto Linux aveva regole e documentazione chiare che aiutavano a prendere decisioni senza la necessità di discussioni, dibattiti o (molte) guerre di fiamme nelle mailing list. Un’occhiata agli archivi vi mostrerà che la parte della flame war non è sempre possibile, ma ciò che è possibile è creare una politica che nega il peso della decisione.

“Quindi la chiave per evitare grandi decisioni diventa semplicemente evitare di fare cose che non possono essere annullate. Non farsi mettere in un angolo da cui non si può uscire. Un topo messo all’angolo può essere pericoloso – un manager messo all’angolo è semplicemente pietoso.”

Show Stoppers! rivela che la filosofia di Bill Gates è simile. Egli “ammirava i programmatori e invariabilmente li metteva a capo di progetti, dove potevano sia gestire che programmare per evitare una situazione in cui i manager professionisti, senza esperienza di programmazione o con conoscenze superate, avevano il sopravvento”.

Come i collaboratori sono orientati intorno ad un forte obiettivo comune

Nel caso di Linux, come in molti popolari progetti open source, il kernel non è emerso dopo essere stato progettato in modo collaborativo da un grande gruppo di collaboratori; piuttosto, è stato migliorato in modo incrementale senza prendere decisioni che destabilizzano la forte base di lavoro fino ad allora. Questo si lega bene con la filosofia di Torvalds sul processo decisionale nella gestione, ma anche con una filosofia incorporata nel codice stesso.

Linux è basato su UNIX, che è un sistema operativo precedente progettato intorno ad un insieme di principi simili allo zen. Come esplicitamente dichiarato nella filosofia UNIX:

“Progettare e costruire software, anche sistemi operativi, per essere provati presto, idealmente entro poche settimane. Non esitate a buttare via le parti maldestre e a ricostruirle.”

Sia Torvalds che Raymond (che cercò di replicare il successo della costruzione della comunità di Torvalds) scoprirono che rilasciare presto e spesso aiutava a radunare i collaboratori intorno a un progetto eccitante e in crescita in cui potevano vedere un futuro. Raymond si è ridotto a due cose chiave che un progetto non può non fare quando viene rilasciato nel mondo:

1. Eseguire
2. Convincere i potenziali co-sviluppatori (utenti) che il progetto può evolvere presto in qualcosa di grande

E’ con questi stessi principi che molte delle startup di oggi si lanciano – Process Street inclusa:

Questa è Process Street nel 2014.

E’ un processo ripetibile?

In superficie, l’improvvisa messa insieme di una delle più intricate creazioni umane sembra un’alchimia. Ma, smontando i componenti, è più facile vedere un processo sottostante. Al momento di scrivere The Cathedral and The Bazaar, Eric S. Raymond stava contemporaneamente portando avanti lo sviluppo di un client di posta elettronica open source. Con l’open-sourcing, Raymond stava tentando di replicare il coinvolgimento della comunità e il successo finale del progetto kernel.

Molti dei principi di base del modello Bazaar, come lo ha coniato, saranno immediatamente familiari a chiunque nel mondo delle startup:

• Ogni buon lavoro di software inizia grattando il prurito personale di uno sviluppatore.
• Trattare i tuoi utenti come co-sviluppatori è la via meno complicata per un rapido miglioramento del codice e un debug efficace.
• Rilascia presto. Rilascia spesso. E ascoltate i vostri clienti.
• Con una base di beta-tester e co-sviluppatori abbastanza grande, quasi ogni problema sarà caratterizzato rapidamente e la soluzione sarà ovvia per qualcuno.
• Se trattate i vostri beta-tester come se fossero la vostra risorsa più preziosa, loro risponderanno diventando la vostra risorsa più preziosa.
• La cosa migliore dopo avere buone idee è riconoscere le buone idee dei vostri utenti. A volte la seconda è meglio.
• Spesso, le soluzioni più sorprendenti e innovative vengono dal rendersi conto che il tuo concetto del problema era sbagliato.
• Per risolvere un problema interessante, inizia trovando un problema che sia interessante per te.
• A patto che il coordinatore dello sviluppo abbia un mezzo di comunicazione buono almeno quanto Internet, e sappia condurre senza coercizione, molte teste sono inevitabilmente meglio di una.

In breve, è un processo ripetibile. E che è stato adottato con successo dal mondo dell’open source nella mentalità delle startup. Si manifesta in agile, lean, six sigma, e gli atteggiamenti e la politica che le startup hanno sviluppato oggi. Anche se non è spesso menzionato nella stessa conversazione, la metodologia che si è evoluta intorno ai primi sistemi operativi condivide molto con l’idea odierna di iterare su un prodotto minimo vitale.