La cattedrale e il bazaar/La posta deve passare: differenze tra le versioni
Contenuto cancellato Contenuto aggiunto
m Conversione intestazione / correzione capitolo by Alebot |
Correzione pagina via bot |
||
Riga 1:
{{Qualità|avz=100%|data=20 luglio 2008|arg=Open Source}}{{IncludiIntestazione|sottotitolo=La posta deve passare|prec=../La cattedrale e il bazaar|succ=../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
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
Mi serviva un client POP3. Ne ho localizzato subito uno online. Anzi, ne ho trovati tre o quattro. Per un
Questo il problema: supponiamo di ricevere un messaggio da qualcuno di nome
Chiaramente questa era
'''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
Mi sono forse lanciato in
'''2. I bravi programmatori sanno cosa scrivere. I migliori sanno cosa riscrivere (e riusare).'''
Line 29 ⟶ 24:
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
Con lo stesso spirito, mi sono messo a cercare una utility POP basata su codici ragionevolmente ben fatti, da utilizzare come base di sviluppo.
Line 35 ⟶ 30:
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
Alcune settimane dopo, però, mi sono imbattuto nel codice di
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
Avevo però altri motivi teorici per ritenere una buona idea il fatto di cambiare, qualcosa che avevo imparato molto tempo prima di Linux.
Line 49 ⟶ 44:
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.
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
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
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
Ma
'''5. Quando hai perso interesse in un programma,
▲Ma l'atteggiamento di Carl Harris risultò perfino più importante. Fu lui a comprendere che:
Senza neppure parlarne, io e Carl sapevamo di perseguire il comune obiettivo di voler raggiungere la soluzione migliore.
▲'''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.
[[pt:A Catedral e o Bazar/II]]
|