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