Author: penyaskito
Date: Tue Oct 28 09:00:51 2008
New Revision: 1547
Log:
Converting file to UTF8
Modified:
trunk/it/ch02.xml
Modified: trunk/it/ch02.xml
==============================================================================
--- trunk/it/ch02.xml (original)
+++ trunk/it/ch02.xml Tue Oct 28 09:00:51 2008
@@ -1,4 +1,4 @@
-<chapter id="getting-started">
+<chapter id="getting-started">
<title>Partenza</title>
@@ -15,15 +15,15 @@
</blockquote>
<para>Da notare che Raymond non stava dicendo che l'open source si ha quando
qualche individuo ha prurito. Piuttosto stava dicendo che
-<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>
-<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.
</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. 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>
+<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.
</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. 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>
-<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>
+<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>
-<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>
+<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>
<para>The corollary to this is that <emphasis>appearances
matter</emphasis>. Programmers, in particular, often don't like to
_______________________________________________
Producingoss-translators mailing list
Producingoss-translators@red-bean.com
http://www.red-bean.com/mailman/listinfo/producingoss-translators
