La cattedrale e il bazaar/Le pre-condizioni necessarie per lo stile bazaar
 |
Questo testo è completo. | |
Traduzione dall'inglese di Bernardo Parrella (1999)
| ◄ | Qualche altra lezione da Fetchmail | Il contesto sociale del software open source | ► |
I primi lettori e revisori di questo scritto hanno ripetutamente sollevato domande sulle pre-condizioni necessarie per il successo dello sviluppo in stile bazaar, comprendendo con ciò sia le qualifiche del leader del progetto sia lo stato del codice al momento della diffusione pubblica e della nascita della possibile comunità di co-sviluppatori.
È alquanto evidente come lo stile bazaar non consenta la scrittura del codice partendo da zero. Si possono fare test, trovare i bug, migliorare il tutto, ma sarebbe molto difficile dar vita dall’inizio a un progetto in modalità bazaar. Linus non lo ha fatto. Neppure io. La nascente comunità di sviluppatori deve avere qualcosa da far girare e con cui giocare.
Quando s’inizia a costruire la comunità, bisogna essere in grado di presentare una promessa plausibile. Non è detto che il programma debba funzionare particolarmente bene. Può anche essere crudo, pieno di bug, incompleto, scarsamente documentato. Non deve però mancare di convincere i potenziali co-sviluppatori che possa evolversi in qualcosa di veramente ben fatto nel prossimo futuro.
Quando Linux e fetchmail vennero diffusi pubblicamente, erano dotati di un design di base forte e attraente. Molte persone ritengono che il modello bazaar da me presentato riveli correttamente questa fase critica, per poi da qui saltare alla conclusione che sia indispensabile un elevato livello di intuizione e bravura da parte di chi guida il progetto.
Ma Linus prese il suo design da Unix. All’inizio ho fatto lo stesso con il popclient originario (anche se poi risultò molto diverso, assai più di quanto è accaduto con Linux, fatte le debite proporzioni). È dunque vero che il leader/coordinatore di un progetto in stile bazaar debba possedere un eccezionale talento nel design? Oppure può cavarsela facendo leva sui talenti altrui?
Non credo sia essenziale che il coordinatore possa produrre design eccezionali, ma è assolutamente centrale che sia capace di riconoscere le buone idee progettuali degli altri.
Ciò appare evidente da entrambi i progetti di Linux e fetchmail. Pur non essendo un designer particolarmente originale (come discusso in precedenza), Linus ha dimostrato un ottima intuizione nel saper riconoscere il buon design per poi integrarlo nel kernel di Linux. Ed ho già descritto come l’idea più potente di fetchmail (SMTP forwarding) mi sia arrivata da qualcun altro.
I primi lettori di questo testo mi hanno fatto i complimenti mettendo a fuoco la mia propensione a sottovalutare l’originalità del design nei progetti in stile bazaar perchè ne possiedo a volontà io stesso, e quindi la dò per scontata. In effetti, c’è qualcosa di vero in quest’affermazione; il design (in alternativa al codice o al debugging) è la mia capacità migliore.
Ma il problema con il fatto di essere bravi e originali nel design del software è che tende a divenire un’abitudine – prendi a fare cose carine e complicate quando invece dovresti tenerle semplici e robuste. Proprio per questa ragione mi sono crollati addosso vari progetti, ma con fetchmail sono stato attento a non farlo.
Credo insomma che il progetto di fetchmail abbia avuto successo in parte perché ho limitato la mia tendenza a esser bravo; ciò va (almeno) contro l’essenzialità dell’originalità del design per il successo dei progetti a bazaar. Consideriamo Linux. Supponiamo che Linus Torvalds avesse cercato di tirar fuori le innovazioni fondamentali dal design del sistema operativo nel corso dello sviluppo; quali probabilità esistono che il kernel risultante fosse ugualmente stabile ed efficace come quello che abbiamo ora?
È chiaro che occorrano capacità di un certo livello per il design e il codice, ma personalmente mi aspetto, da quasi tutte le persone che pensano seriamente di lanciare un progetto bazaar, un livello superiore. Il mercato interno della reputazione della comunità open source esercita una sottile pressione sulle persone in modo che non si lancino dei progetti se non si è abbastanza competenti per seguirli. Finora quest’approccio ha funzionato piuttosto bene.
Esiste un altro tipo di capacità normalmente non associata allo sviluppo del software che ritengo importante al pari della bravura nel design per i progetti bazaar – anzi, forse ancora più importante. Il coordinatore o leader deve essere in grado di comunicare efficacemente con gli altri.
D’altronde è ovvio che per metter su una comunità di sviluppatori occorra attirare gente, coinvolgerli in quel che stai facendo, tenerli contenti per il lavoro che fanno. Lo sfrigolìo tecnico aiuta molto in questo senso, ma è ben lungi dall’esser tutto. È anche importante il tipo di personalità che proietti.
Non è certo una coincidenza che Linus sia un tipo simpatico, capace di piacere alla gente e di farsi aiutare. Da parte mia, io sono un estroverso energetico cui piace lavorare tra la folla, oltre ad avere qualcosa dei modi e dell’istinto del comico. Per far funzionare il modello a bazaar, aiuta parecchio essere in grado di esercitare almeno un po’ di fascino sulla gente.