Author: giovannigiorgio
Date: Fri Nov 28 02:26:10 2008
New Revision: 1577
Log:
Almost all chapter 2 translated
Modified:
trunk/it/ch02.xml
Modified: trunk/it/ch02.xml
==============================================================================
--- trunk/it/ch02.xml (original)
+++ trunk/it/ch02.xml Fri Nov 28 02:26:10 2008
@@ -15,29 +15,20 @@
</blockquote>
<para>Da notare che Raymond non stava dicendo che l'open source si ha quando
qualche individuo ha prurito. Piuttosto stava dicendo che
-<<<<<<< .mine
-<emphasis>il buon</emphasis> software nasce quando i programmatore ha
interesse a vedere risolti i problemi. La rilevanza di ci� per il software
libero era che il prurito personale si rivelava essere la pi� frequente
motivazione nel far partire un progetto di software libero.</para>
-=======
-<emphasis>il buon</emphasis> software nasce quando i programmatore ha
interesse a vedere risolti i problemi. La rilevanza di ciò per il software
libero era che il prurito personale si rivelava essere la più frequente
motivazione nel far partire un progetto di software libero.</para>
->>>>>>> .r1573
-<<<<<<< .mine
+<emphasis>il buon</emphasis> software nasce quando il programmatore ha
interesse a vedere risolti i problemi. La rilevanza di ci� per il software
libero era che il prurito personale si rivelava essere la pi� frequente
motivazione nel far partire un progetto di software libero.</para>
+
+
+
<para>Questo � ancora oggi il modo in cui i progetti liberi partono, ma meno
oggi che nel 1997, quando Raymond scriveva queste parole. Oggi abbiamo il
fenomeno di organizzazioni, incluse quelle che lo fanno per profitto—che
danno il via a grossi progetti open source centralizzati organizzativamente.
Il programmatore solitario che batte del codice per risolvere un problema
locale e che poi si rende conto che il risultato ha una larga applicabilit� �
ancora la sorgente di molto nuovo software libero, ma non � la sola storia.
</para>
La condizione essenziale � che i produttori abbiano un interesse diretto al
suo successo perch� lo usano essi stessi. Se il software non fa quello che si
suppone faccia l'organizzazione o la persona che lo produce sentir� una
insoddisfazione nel suo lavoro giornaliero. Per esempio, il progetto OpenAdapte
(<ulink
url="http://www.openadapter.org/"/>), che fu avviato dalla banca di
investimenti Dresdner Kleinwort Wasserstein come base open source per integrare
disparati sistemi di informazione finanziaria, pu� a mala pena dirsi un
progetto che gratta il prurito di un programmatore solitario. Esso gratta un
prurito istituzionale. Ma quel prurito vien fuori dall'esperienza
dell'istituzione e dei suoi partners, e quindi se il progetto fallisce
nell'alleviare il loro prurito essi lo sapranno. Questo congegno produce buon
software perch� il giro di ritorno va nella giusta direzione. Il programma non
viene scritto per essere venduto a qualche altro in modo che questi possa
risolvere <emphasis>il suo</emphasis> problema. Esso viene scritto per
risolvere <emphasis>il proprio </emphasis> problema di qualcuno, quindi viene
condiviso con chiunque, pi� o meno come se il problema fosse una malattia e il
software una medicina la cui distribuzione intende sradicare completamente
l'epidemia.</para>
-=======
-<para>Questo è ancora oggi il modo in cui i progetti liberi partono, ma meno
oggi che nel 1997, quando Raymond scriveva queste parole. Oggi abbiamo il
fenomeno di organizzazioni, incluse quelle che lo fanno per profitto—che
danno il via a grossi progetto open source centralizzati organizzativamente.
Il programmatore solitario che batte del codice per risolvere un problema
locale e che poi si rende conto che il risultato ha una larga applicabilità è
ancora la sorgente di molto nuovo software libero, ma non è la sola storia.
-La condizione essenziale è che i produttori abbiano un interesse diretto al
suo successo perchè lo usano essi stessi. Se il software non fa quello che si
suppone faccia l'organizzazione o la persona che lo produce sentirà una
insoddisfazione nel suo lavoro giornaliero. Per esempio, il progetto OpenAdapte
(<ulink
-url="http://www.openadapter.org/"/>), che fu avviato dalla banca di
investimenti Dresdner Kleinwort Wasserstein come base open source per integrare
disparati sistemi di informazione finanziaria, può a mala pena dirsi un
progetto che gratta il prurito di un programmatore solitario. Esso gratta un
prurito istituzionale. Ma quel prurito vien fuori dall'esperienza
dell'istituzione e dei suoi partners, e quindi se il progetto fallisce
nell'alleviare il loro prurito essi lo sapranno. Questo congegno produce buon
software perchè il giro di ritorno va nella giusta direzione. Questo programma
non viene scritto per essere venduto a qualche altro in modo che questo possano
risolvere <emphasis>il suo</emphasis> problema. Esso viene scritto per
risolvere <emphasis>il loro proprio</emphasis> problema, quindi viene
condiviso con chiunque, più o meno come se il problema fosse una malattia e il
software una medicina la cui distribuzione intende sradicare completamente
l'epidemia.</para>
->>>>>>> .r1573
+
<para>Questo capitolo tratta di come mettere al mondo un nuovo software, ma
molte delle sue raccomandazioni suoneranno familiari a una organizzazione della
sanità distributrice di medicine. Gli obiettivi sono molto simili: voi volete
chiarire ciò che la medicina fa, la mettete nelle mani delle persone giuste e
vi assicurate che quelli che la ricevono sappiano usarla, ma col software voi
volete attirare alcuni dei destinatari a unirsi al tentativo di migliorare la
medicina.</para>
-<<<<<<< .mine
+
<para>Il software ha bisogno di acquisire utilizzatori e di acquisire
sviluppatori. Queste due necessit� non sono necessariamente in conflitto, ma
aggiungono complessit� alla presentazione iniziale del progetto. Qualche
informazione � utile per ambedue le categorie, qualcuna � utile solo per l'una
o solo per l'altra. Tutti e due i tipi di informazione dovrebbero dare un
contributo al principio di una informazione adattata. Cio� il grado di
dettaglio fornito ad ogni stadio dovrebbe corrispondere direttamente alla
quantit� di tempo e di sforzo immessovi dal lettore. Maggiore sforzo dovrebbe
essere sempre uguale a maggior ricompensa. Quando le due cose non sono
correlate fermamente la gente pu� velocemente perdere la fiducia e abbandonare
il tentativo.</para>
-=======
-<para>Il software ha bisogno di acquisire utenti e di acquisire sviluppatori.
Queste due necessità non sono necessariamente in conflitto, ma aggiungono
complessità alla presentazione iniziale del progetto. Qualche informazione è
utile per ambedue le categorie, qualcuna è utile solo per l'una o solo per
l'altra. Tutti e due i tipi di informazione dovrebbero dare un contributo al
principio di una informazione adattata. Cioè il grado di dettaglio fornito ad
ogni stadio dovrebbe corrispondere direttamente alla quantità di tempo e di
sforzo immessovi dal lettore. Maggiore sforzo dovrebbe essere sempre uguale a
maggior ricompensa. Quando le due cose non sono correlate fermamente la gente
può velocemente perdere la fiducia e abbandonare lo sforzo.</para>
->>>>>>> .r1573
<para>Il corollario a ci� � cos� <emphasis>la questione
dell'apparenza</emphasis>. Ai programmatore spesso non piace pensare a ci�. Il
loro amore per la sostanza pi� che per la forma � quasi un punto di vanto
professionale. Non � un caso che cos� tanti programmatori mostrino una
antipatia per il lavoro di marketing e di pubbliche relazioni n� che i creatori
di grafica professionale siano inorriditi di fronte a quello che i
programmatori fanno pensare per conto proprio. </para>
_______________________________________________
Producingoss-translators mailing list
[email protected]
http://www.red-bean.com/mailman/listinfo/producingoss-translators
