Leggi Sviluppo Software – Legge di Linus

Tutti conoscono Linus Torvalds come il padre del sistema operativo Linux.

A lui si devono tante idee, innovazioni nel mondo dell’informatica: dal primo sistema operativo libero (Linux appunto), a Git (per la gestione dei sorgenti), ecc…

Nella fase di realizzazione del sistema operativo Linux, per la gestione delle funzionalità del progetto, optò per usare un approccio che viene chiamato bazaar. In che cosa consiste?Immaginate un immenso bazar  dove ci sono tanti venditori e la merce di tutti i venditori è esposta alla visione di tutti, sia di chi passa nel bazar per comprare, sia di chi vende; quello che fece Torvalds è creare la prima versione di Linux e mettere i sorgenti a disposizione di tutti, agevolando la condivisione e la partecipazione di altri programmatori; e i programmatori che sono stati attratti, si sono comportati esattamente come le persone che entrano nel bazar: tutti hanno potuto visionare il codice, e tutti hanno potuto modificare il codice e intervenire per migliorarlo, al punto che alcuni hanno creato dei propri sistemi operativi basati su Linux, oppure ne hanno esteso e rivisto le funzionalità migliorando complessivamente il prodotto.

Questo è  un approccio che si contrappone al modello cattedrale: nel modello a cattedrale il sorgente è reso nascosto e visibile solo a pochi, e chi entra nella cattedrale può solo ascoltare il racconto che gli altri fanno di quel codice sorgente, ma non possono vederlo. Il codice è visibile solo da alcuni esperti, e anche loro comunque ne vedono solo una parte. In termini di sicurezza, il vantaggio di questo modello è quello di creare un effetto di sensazione di sicurezza raggiunta tramite la segretezza del sorgente, più che per qualità dello stesso.

Questa contrapposizione tra i due modelli è descritta nel libro di Eric Raymond, La Cattedrale e il bazaar, in cui lo stesso Raymond racconta la differenza tra un progetto fatto con lo spirito del software libero e uno fatto con lo spirito del codice protetto.

Anche wikipedia è un progetto che segue il modello bazaar: tutti possono leggerla e averne accesso, tutti la possono modificare, ogni modifica è visibile a tutti, e l’obiettivo è creare così una conoscenza distribuita, consapevole e condivisa fra tutti.

La qualità di wikipedia si basa sul fatto che se qualcuno ne altera i contenuti o scrive cose errate, gli altri frequentatori del bazaar possono rettificare, correggere e addirittura scacciare chi ha comportamenti non etici dal bazaar.

All’interno del libro di Raymond, ispirato dal successo di Linus Torvalds, si trova quella che viene considerata la Legge di Linus:

given enough eyeballs, all bugs are shallow

ovvero:

Dato un numero sufficiente di occhi, tutti i bug vengono a galla

Sembra un concetto molto semplice: più persone sono in grado di vedere più problemi.

Ma il suo significato è decisamente molto forte, dirompente, perché non dice solo che più persone vedono più problemi, ma che esiste un numero sufficiente di persone in grado di far emergere tutti i bug.

E questo ha cambiato il modo di fare software. Come? Di seguito alcuni esempi nel mondo del software o della tecnologia che devono molto alla Legge di Linus

• Wikipedia: come già detto,  pone la sua qualità proprio su questa legge
• Open Source: la legge di Linus è stata alla base del movimento del software libero e dell’open source che ha rivoluzionato il mondo del software e il modo di produrre software
• Pair Programming,: è una pratica delle metodologie XP che nasce da questa legge, perchè 2 occhi sono in grado di produrre un software migliore
• Etichal Hacking:  questo movimento ha alla base l’idea che gli hacker aiutano aziende e organizzazioni mettendo a disposizione i loro occhi per verificare la vulnerabilità di siti e applicazioni
• Testing: diverse tecniche di testing sono basate proprio sulla legge di Linus

A ciò si aggiunge un effetto intrinseco nelle modalità di lavorare in team nelle aziende che producono software, ma non solo; la Legge di Linus infatti è anche un forte invito alla cooperazione/collaborazione:

• se non riesci a trovare il problema nel tuo codice, lascia che qualcuno ti aiuti, non isolarti, anzi…
• lascia agli altri la possibilità di vedere il codice perché in due o più sarete in grado di trovare il bug più facilmente

Praticamente un invito alla cooperazione, alla trasparenza e alla condivisione delle conoscenza tra developer (e tester) ad ogni livello, fino alla Collective Ownership del codice

Le altre Leggi alla base dello Sviluppo Software