La cattedrale e il bazaar/Fetchmail diventa adulto
 |
Questo testo è completo. | |
Traduzione dall'inglese di Bernardo Parrella (1999)
| ◄ | Popclient diventa Fetchmail | Qualche altra lezione da Fetchmail | ► |
Eccomi qui con un design ben fatto e innovativo, un codice che ero certo funzionasse bene perchè lo usavo ogni giorno, e una spumeggiante lista di beta tester. Gradualmente mi resi conto che non ero più indaffarato con uno stupido programmino personale che forse avrebbe potuto interessare pochi altri. Stavo lavorando su un programma di cui ogni hacker dotato di mailbox Unix e connessione SLIP/PPP non avrebbe potuto fare a meno.
Grazie all’opzione di “SMTP forwarding”, superava sicuramente i programmi rivali fino a diventare potenzialmente una “categoria killer”, uno di quei programmi classici che occupano la propria nicchia in maniera perfetta, facendo scartare e quasi dimenticare ogni possibile alternativa.
Credo che simili risultati siano impossibili da perseguire o da pianificare. Devi esser trascinato dentro la storia da idee così potenti che, col senno di poi, quei risultati appaiono del tutto inevitabili, naturali, perfino prestabiliti. L’unico modo per provarci è farsi venire un sacco di idee, oppure avere la capacità di portare le idee degli altri al di là del punto in cui essi stessi credevano potessero arrivare.
Andrew Tanenbaum ebbe l’idea originale di realizzare un linguaggio di base Unix per il 386, da usare come strumento didattico. Linus Torvalds ha spinto il concetto del Minix ben oltre quanto lo stesso Andrew ritenesse possibile – ed è diventato qualcosa di meraviglioso. Allo stesso modo (pur se su scala minore) io ho preso alcune idee da Carl Harris e Harry Hochheiser, e le ho spinte oltre. Nessuno di noi è stato “originale” nel senso romantico in cui si immagina un genio. Ma a ben vedere la maggior parte della scienza, dell’ingegneria e dello sviluppo del software non viene realizzata da alcun genio originale, il contrario della mitologia dell’hacker.
I risultati ottenuti erano piuttosto notevoli – meglio, esattamente quel tipo di successo che ogni hacker sogna! E ciò significa che avrei potuto mirare anche a standard più elevati. Per rendere fetchmail così ben fatto come lo vedevo ora, avrei dovuto scrivere non soltanto per le mie necessità ma anche per includere il supporto di opzioni necessarie ad altri e tuttavia fuori dalla mia orbita. E fare ciò mantenendo al contempo semplice e robusto il programma.
La prima funzione di gran lunga più importante che scrissi dopo essermi reso conto di ciò, fu il supporto multiutente – la possibilità di prelevare la posta da più mailbox in cui erano stati accumulati tutti i messaggi per un gruppo di utenti, e quindi smistare ogni singolo messaggio ai rispettivi destinatari.
Decisi di aggiungere il supporto multiutente in parte perché alcuni lo richiedevano, ma soprattutto perché pensavo avrebbe buttato via ogni bug dal codice per un solo utente, costringendomi a fare attenzione alla gestione dei vari indirizzi. E così fu. Mi ci volle parecchio tempo per sistemare tutto nella RFC 822, non perché sia difficile mettere a posto ogni singola parte, ma perché coinvolgeva una montagna di dettagli interdipendenti e instabili.
In ogni caso, anche la funzione per gli indirizzi multiutenti si rivelò un’ottima decisione. Ecco come me ne sono accorto:
14. Ogni strumento dovrebbe rivelarsi utile nella maniera che ci si attende, ma uno strumento davvero ben fatto si presta ad utilizzi che non ci si aspetterebbe mai.
L’uso inatteso della funzione multiutenti è per una mailing list quando questa viene mantenuta sul lato client della connessione SLIP/PPP, attivando l’espansione dell’alias. Ne consegue che chi fa girare un PC tramite un account con un provider Internet è in grado di gestire una mailing list senza dover accedere continuamente ai file alias del provider.
Altra importante modifica richiesta dai beta tester fu il supporto per operazioni MIME in 8-bit. Qualcosa piuttosto semplice a farsi, poiché avevo fatto bene attenzione a mantenere il codice pulito per inserire l’8-bit. Non perché avessi anticipato tale richiesta, quanto piuttosto per rispettare un’altra regola:
15. Quando si scrive del software per qualunque tipo di gateway, ci si assicuri di disturbare il meno possibile il flusso dei dati – e mai buttar via alcun dato a meno che il destinatario non ti ci costringa!
Se non avessi rispettato questa regola, il supporto per MIME in 8-bit sarebbe risultato difficile e problematico. Così invece tutto quel che dovetti fare fu leggere la RFC 1652 e aggiungere poche stringhe per far generare l’header.
Alcuni utenti europei mi hanno costretto a inserire un’opzione per limitare il numero dei messaggi prelevati a ogni sessione (in modo da controllare i costi di collegamento, per via delle care tariffe imposte dalle aziende telefoniche nazionali). Ho resistito per parecchio tempo, e ancor’oggi non ne sono pienamente soddisfatto. Ma se scrivi programmi per tutto il mondo, devi dare ascolto ai tuoi clienti – e ciò rimane valido anche se non ti ricompensano in denaro.