Utilizzavo la email in modo quasi istantaneo, poi mi sono reso conto
che era noioso tenere sempre aperto il telnet per controllare la posta.
In realt� volevo essere avvisato dell'arrivo di nuova posta sul mio computer e utilizzavo gli strumenti che avevo.
Il protocollo nativo di Internet, SMTP, non faceva il caso mio, perch� lavora bene quando le macchine sono connesse, mentre il mio PC non era sempre connesso e non aveva un IP statico.
Quello che mi serviva era un programma che raggiungesse
la mia connessione intermittente e mi inviasse la mia posta.
Sapevo che esisteva un semplice protocollo chiamato POP
che ora � ampiamente diffuso, ma che allora non avevo.
Mi serviva un client POP3. L'ho cercato in rete e l'ho trovato,
anzi ne ho trovati 3 o 4. Ne ho usato uno per un po',
ma non aveva una funzione che sembra ovvia,
quella di conservare l'indirizzo del mittente,
che � chiaramente una cosa che il computer deve fare per me.
E questo ci porta alla prima lezione:
1. Il primo lavoro � togliere dal software i problemi personali dello sviluppatore.
Forse sembra ovvio, ma troppo spesso gli sviluppatori realizzano per la paga programmi che non servono e che non amano. Questo non avviene nel mondo Linux e questo pu� spiegare perch� la qualit� del software � cos� alta.
Cosa dovevo fare: buttarmi a sviluppare furiosamente un nuovo client POP3 per completare quelli esistenti? No, ho guardato attentamente quelli che esistevano chiedendomi: "quale si avvicina ai miei bisogni?". Perch�
2. I buoni programmatori sanno quello che scrivono. I grandi sanno cosa riscrivere (e riusare).
Poich� non pretendo di essere un grande programmatore, cerco di imitarli. Un tratto importante dei grandi � la pigrizia costruttiva. Loro sanno che che si fa qualcosa non per lo sforzo, ma per il risultato e che � pi� facile partire da una soluzione parziale, piuttosto che dal nulla.
Linus Torvalds, per esempio, non ha tentato di scrivere Linux da zero, ma ha cominciato riutilizzando idee e codice di Minx, sistema operativo per cloni PC simile a Unix. Si pu� essere certi che tutto il codice Minx � stato eliminato o � stato completamente riscritto, ma mentre era l� ha fatto da culla all'infante che sarebbe diventato Linux. Con lo stesso spirito ho cercato gli applicativi POP scritti abbastanza bene da esser usati come base di sviluppo.
La tradizione di condividere il sorgente, propria del mondo Unix,
� sempre stata amica del riuso (e questo spiega perch�
il progetto GNU ha scelto Unix come OS di base, nonostante
serie riserve sul sistema stesso).
Il mondo Linux ha portato questa tradizione
ai suoi limiti tecnologici: ci sono terabytes di open sources
disponibili a tutti.
Cos� passare il tempo a cecare qualcosa di abbastanza buono
d� risultati migliori nel mondo Linux.
E cos� � successo a me.
Con quelli che avevo trovato prima,
sono arrivato a 9 candidati (fetchpop, PopTart, get-mail, gwpop, pimp, pop-perl, popc, popmail and upop).
Ho cominciato con `fetchpop' di Seung-Hong Oh.
Ho inserito le caratteristiche che volevo e ho aggiunto
altri miglioramenti, che sono stati accettati dall'autore
nella versione 1.9.
Poche settimene dopo, per�, ho visto il codice del `popclient'
di Carl Harris � ho scoperto di avere un problema.
Sebbene avesse alcune buone idee orginali, 'fetchpop'
poteva trattare solo POP3 ed era un codice quasi amatoriale
(Seung-Hong era a quel tempo un brillante programmatore senza esperienza e mostrava entrambe le cose). Il codice di Carl
era migliore, professionale e solido, ma
non aveva parecchie caratteristiche importanti.
Restare o cambiare? Se decidevo di cambiare dovevo buttar via
il codice che avevo fatto e funzionava per una base di sviluppo.
Un motivo pratico per cambiare era la presenza di un supporto multiprotocollo. POP3 � il protocollo pi� usato, ma non l'unico:
"fetchpop" e gli altri non facevano POP2, RPOP e APOP
e mi era venuto il vago pensiero di aggiungere
IMAP (Internet Message Access Protocol, ilprotocollo pi� recente e potente), cos�, per divertimento.
Ma avevo un motivo pi� teorico per pensare che cambiare
� una buona idea, cosa che avevo imparato molto prima di Linux.
3. ``Preparati a buttare via qualcosa, tanto lo farai comunque. (Plan to throw one away; you will, anyhow.'' (Fred Brooks, ``The Mythical Man-Month'', Chapter 11)
O, per metterla in un altro modo, spesso non si capisce davvero il problema fino a quando non si implementa personalmente una soluzione (la seconda volta forse ne sai abbastanza per farlo bene). Cos� se vuoi fare qualcosa di giusto devi essere pronto a ricominciare almeno una volta [JB].
Bene, mi dissi, le modifiche a "fetchpop" erano state il mio primo tentativo. Cos� ho cambiato. Dopo aver spedito le mie patches a Carl Harris il 25 giugno 1996, mi ero reso conto che lui aveva perso l'interesse per il suo popclient. Il codice era un po' polveroso e aveva piccoli bachi che lo bloccavano. Dovevo fare molte modifiche e presto ci trovammo d'accordo che la cosa logica da fare era che io mi prendessi a carico il programma. Senza che me ne redessi conto, il progetto si era ingigantito. Non dovevo pi� guardare piccoli aggiustamenti a un POP client esistente: dovevo mantenerne uno intero e mi ribollivano in testa idee che sapevo avrebbero condotto a grandi cambiamenti.
Nella cultura che incoraggia la condivisione del codice, questa � l'evoluzione naturale di un progetto. Stavo attuando questo principio:
4. Se hai l'atteggiamento giusto, i problemi interessanti ti troveranno.
Ma l'atteggiamento di Carl Harris � stato ancor pi� imortante. Lui ha capito che:
5. Quando perdi interesse in un programma, l'ultimo tuo dovere � metterlo in mano a un tuo successore competente.
Senza nemmeno averlo discusso, Carl e io sapevamo di avere lo scopo comune di trovare la soluzione migliore. Il solo problema per entrambi era se io potevo dimostrare di avere un paio di mani sicure. Una volta che l'ho dimostrato, lui si � comportato elegantemente e con distacco. Spero di comportarmi cos� quando sar� il mio turno.