La cattedrale e il bazaar/La posta deve passare

Da Wikisource.
Jump to navigation Jump to search
La posta deve passare

../La cattedrale e il bazaar ../L'importanza di avere utenti IncludiIntestazione 5 settembre 2014 75% Open Source

Eric Steven Raymond - La cattedrale e il bazaar (1997)
Traduzione dall'inglese di Bernardo Parrella (1999)
La posta deve passare
La cattedrale e il bazaar L'importanza di avere utenti


Dal 1993 mi occupo del lato tecnico di un piccolo provider Internet gratuito chiamato Chester County InterLink (CCIL) in West Chester, Pennsylvania (sono tra i fondatori di CCIL e autore del software specifico per il nostro bulletin-board multiutenti – si può dare un’occhiata facendo telnet su locke.ccil.org <telnet://locke.ccil.org>. Ora dà accesso a quasi tremila utenti su trenta linee). Grazie a questo lavoro posso collegarmi a Internet per 24 ore al giorno con una linea a 56K di CCIL – in realtà, è proprio quel che mi viene richiesto!

Di conseguenza sono ormai abituato alle email istantanee. Per vari motivi, era difficile far funzionare la connessione SLIP tra la mia macchina a casa (snark.thyrsus.com) e CCIL. Quando finalmente ci sono riuscito, mi dava fastidio dover fare ogni tanto telnet su locke per controllare la posta. Volevo fare in modo che i messaggi arrivassero direttamente su snark così da esserne tempestivamente avvisato e poterli gestire a livello locale.

Il semplice “sendmail forwarding” non avrebbe funzionato, perché la mia macchina personale non è sempre online e non ha un indirizzo IP statico. Mi serviva un programma in grado di raggiungere la connessione SLIP e tirar via la posta per farla arrivare localmente. Sapevo dell’esistenza di simili cose, e del fatto che in genere facevano uso di un semplice protocollo noto come POP (Post Office Protocol). E sicuramente doveva già esserci un server POP3 incluso nel sistema operativo BSD/OS di locke.

Mi serviva un client POP3. Ne ho localizzato subito uno online. Anzi, ne ho trovati tre o quattro. Per un po’ ho usato un pop-perl, ma era privo di quella che pareva una funzione ovvia, la capacità di effettuare un “hacking degli indirizzi della posta prelevata in modo che il reply funzionasse correttamente.

Questo il problema: supponiamo di ricevere un messaggio da qualcuno di nome ’joe’ su locke. Se lo inoltro su snark e poi cerco di fare reply, il mio programma di posta proverebbe simpaticamente a inviarlo a un inesistente ’joe’ su snark. Modificare a mano ogni indirizzo per aggiungere “@ccil.org” diventerebbe in un attimo un problema serio.

Chiaramente questa era un’operazione che toccava fare al computer per conto mio. Ma nessuno dei client POP esistenti sapeva come! E questo ci porta alla prima lezione:

1. Ogni buon lavoro software inizia dalla frenesia personale di uno sviluppatore.

Forse ciò avrebbe dovuto risultare ovvio (è risaputo da tempo che “la necessità è la madre di tutte le invenzioni”), ma troppo spesso gli sviluppatori trascorrono le giornate impegnati a guadagnarsi da vivere con programmi di cui non hanno alcun bisogno e che non apprezzano. Ma non nel mondo Linux – il che spiega l’alta qualità media del software originato dalla comunità Linux.

Mi sono forse lanciato in un’attività frenetica per scrivere il codice di un client POP3 nuovo di zecca in grado di competere con quelli esistenti? Nemmeno per sogno! Ho esaminato attentamente le utility POP che avevo in mano, chiedendomi: “qual’è la più vicina a quel che sto cercando?” Perché:

2. I bravi programmatori sanno cosa scrivere. I migliori sanno cosa riscrivere (e riusare).

Pur non ritenendomi un programmatore tra i più bravi, cerco di imitarli. Importante caratteristica di costoro è una sorta di ozio costruttivo. Sanno che si ottiene il meglio non per le energie impiegate ma per il risultato raggiunto, e che quasi sempre è più facile iniziare da una buona soluzione parziale piuttosto che dal nulla assoluto.

Linus Torvalds, per esempio, non ha mai cercato di riscrivere Linux da zero. È invece partito riutilizzando codici e idee riprese da Minix, piccolo sistema operativo per macchine 386 assai simile a Unix. Alla fine il codice Minix è scomparso oppure è stato completamente riscritto – ma per il tempo che è rimasto lì presente è servito come impalcatura per l’infante che sarebbe infine divenuto Linux.

Con lo stesso spirito, mi sono messo a cercare una utility POP basata su codici ragionevolmente ben fatti, da utilizzare come base di sviluppo.

La tradizione di condivisione dei codici tipica del mondo Unix ha sempre favorito il riutilizzo dei sorgenti (questo il motivo per cui il progetto GNU ha scelto come sistema operativo di base proprio Unix, nonostante alcune serie riserve sullo stesso). Il mondo Linux ha spinto questa tradizione vicina al suo al limite tecnologico; sono generalmente disponibili terabyte di codice open source. È quindi probabile che, impiegando del tempo a cercare il lavoro di qualcuno quasi ben fatto, si ottengano i risultati voluti. E ciò vale assai più nel mondo Linux che altrove.

Proprio quel che è successo a me. Conteggiando i programmi trovati prima, con la seconda ricerca ottenni un totale di nove candidati – fetchpop, PopTart, get-mail, gwpop, pimp, pop-perl, popc, popmail e upop. Il primo su cui mi sono concentrato è stato ’fetchpop’ di Seung-Hong Oh. Ho inserito l’opzione “header-rewrite” e ho apportato altri miglioramenti, poi accettati dall’autore nella release 1.9.

Alcune settimane dopo, però, mi sono imbattuto nel codice di ’popclient’ scritto da Carl Harris, ed mi sono trovato di fronte a un problema. Pur offrendo alcune buone idee originali (come la modalità “daemon”), fetchpop poteva gestire solo POP3 e il codice rifletteva un certo approccio da dilettante (Seung-Hong era un programmatore brillante ma inesperto, ed entrambe le qualità risultavano evidenti). Il codice di Carl era migliore, alquanto professionale e solido, ma il suo programma difettava di varie opzioni presenti in fetchpop, opzioni importanti e piuttosto complesse da implementare (incluse quelle aggiunte dal sottoscritto).

Restare o cambiare? Nel secondo caso avrei buttato via il codice che avevo già scritto in cambio di una migliore base di sviluppo.

Un motivo pratico per passare all’altro programma era il supporto per protocolli multipli. POP3 è il più usato tra i server per l’ufficio postale, ma non è il solo. Fetchpop e l’altro rivale non avevano POP2, RPOP, o APOP, e io stesso stavo meditando, giusto per divertimento, l’aggiunta di IMAP (Internet Message Access Protocol, il protocollo per l’ufficio postale più recente e più potente).

Avevo però altri motivi teorici per ritenere una buona idea il fatto di cambiare, qualcosa che avevo imparato molto tempo prima di Linux.

3. “Preparati a buttarne via uno; dovrai farlo comunque.” (Fred Brooks, “The Mythical Man-Month”, Capitolo 11)

In altri termini, spesso non si riesce a comprendere davvero un problema fino alla prima volta in cui si prova a implementarne la soluzione. La seconda volta forse se ne sa abbastanza per riuscirci. Per arrivare alla soluzione, preparati a ricominciare almeno una volta.

Be’, mi son detto, la mia prima volta erano state le modifiche a fetchpop. Adesso era ora di cambiare, e così feci.

Dopo aver mandato a Carl Harris il 25 Giugno 1996 una prima serie di aggiustamenti per popclient, mi resi conto che da qualche tempo egli aveva perso interesse nel programma. Il codice era un po’ polveroso, con vari bug in giro. Avrei dovuto fare molte modifiche, e ci mettemmo rapidamente d’accordo sul fatto che la cosa più logica fosse che il programma passasse in mano mia.

Senza che me ne accorgessi più di tanto, il progetto era cresciuto parecchio. Non mi stavo più occupando soltanto di sistemare i piccoli difetti di un client POP già esistente. Mi ero addossato l’intera gestione di un programma, e mi venivano in mente delle idee che avrebbero probabilmente portato a modifiche radicali.

In una cultura del software che incoraggia la condivisione del codice, non si trattava altro che della naturale evoluzione di un progetto. Questi i punti-chiave:

4. Se hai l’atteggiamento giusto, saranno i problemi interessanti a trovare te.

Ma l’atteggiamento di Carl Harris risultò perfino più importante. Fu lui a comprendere che:

5. Quando hai perso interesse in un programma, l’ultimo tuo dovere è passarlo a un successore competente.

Senza neppure parlarne, io e Carl sapevamo di perseguire il comune obiettivo di voler raggiungere la soluzione migliore. L’unica questione per entrambi era stabilire se le mie fossero mani fidate. Una volta concordato su questo, egli agì con gentilezza e prontezza. Spero di comportarmi altrettanto bene quando verrà il mio turno.