Author: giovannigiorgio
Date: Mon Oct 27 04:52:57 2008
New Revision: 1539
Log:
part of chapter 2
Modified:
trunk/it/ch02.xml
Modified: trunk/it/ch02.xml
==============================================================================
--- trunk/it/ch02.xml (original)
+++ trunk/it/ch02.xml Mon Oct 27 04:52:57 2008
@@ -1,80 +1,29 @@
<chapter id="getting-started">
-<title>Getting Started</title>
+<title>Partenza</title>
<simplesect>
-<para>The classic model of how free software projects get started was
-supplied by Eric Raymond, in a now-famous paper on open source
-processes entitled <citetitle>The Cathedral and the
-Bazaar</citetitle>. He wrote:</para>
+<para>Il modello classico di avvio di un progetto di software libero fu
fornito da Eric Raymond su un saggio oggi famoso sui metodi dell'open source
intitolato <citetitle>La Cattedrale e il Bazaar</citetitle>. Egli
scriveva:</para>
<blockquote>
- <para><emphasis>Every good work of software starts by scratching
- a developer's personal itch.</emphasis></para>
+ <para><emphasis>Ogni buon lavoro di software nasce dal atto dello
sviluppatore di grattarsi un prurito personale.</emphasis></para>
<para>(from <emphasis role="bold"><ulink
url="http://www.catb.org/~esr/writings/cathedral-bazaar/"/>
</emphasis>)</para>
</blockquote>
-<para>Note that Raymond wasn't saying that open source projects happen
-only when some individual gets an itch. Rather, he was saying that
-<emphasis>good</emphasis> software results when the programmer has a
-personal interest in seeing the problem solved; the relevance of this
-to free software was that a personal itch happened to be the most
-frequent motivation for starting a free software project.</para>
-
-<para>This is still how most free projects are started, but less so
-now than in 1997, when Raymond wrote those words. Today, we have the
-phenomenon of organizations—including for-profit
-corporations—starting large, centrally-managed open source
-projects from scratch. The lone programmer, banging out some code to
-solve a local problem and then realizing the result has wider
-applicability, is still the source of much new free software, but is
-not the only story.</para>
-
-<para>Raymond's point is still insightful, however. The essential
-condition is that the producers of the software have a direct interest
-in its success, because they use it themselves. If the software
-doesn't do what it's supposed to do, the person or organization
-producing it will feel the dissatisfaction in their daily work. For
-example, the OpenAdapter project (<ulink
-url="http://www.openadapter.org/"/>), which was started by investment
-bank Dresdner Kleinwort Wasserstein as an open source framework for
-integrating disparate financial information systems, can hardly be
-said to scratch any individual programmer's personal itch. It
-scratches an institutional itch. But that itch arises directly from
-the experiences of the institution and its partners, and therefore if
-the project fails to relieve them, they will know. This arrangement
-produces good software because the feedback loop flows in the right
-direction. The program isn't being written to be sold to someone else
-so they can solve <emphasis>their</emphasis> problem. It's being
-written to solve one's <emphasis>own</emphasis> problem, and then
-shared with everyone, much as though the problem were a disease and
-the software were medicine whose distribution is meant to completely
-eradicate the epidemic.</para>
-
-<para>This chapter is about how to introduce a new free software
-project to the world, but many of its recommendations would sound
-familiar to a health organization distributing medicine. The goals
-are very similar: you want to make it clear what the medicine does,
-get it into the hands of the right people, and make sure that those
-who receive it know how to use it. But with software, you also want
-to entice some of the recipients into joining the ongoing research
-effort to improve the medicine.</para>
-
-<para>Free software distribution is a twofold task. The software
-needs to acquire users, and to acquire developers. These two needs
-are not necessarily in conflict, but they do add some complexity to a
-project's initial presentation. Some information is useful for both
-audiences, some is useful only for one or the other. Both kinds of
-information should subscribe to the principle of scaled presentation;
-that is, the degree of detail presented at each stage should
-correspond directly to the amount of time and effort put in by the
-reader. More effort should always equal more reward. When the two do
-not correlate tightly, people may quickly lose faith and stop
-investing effort.</para>
+<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>
+
+<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>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
