Author: cafonso
Date: Fri Aug 17 12:39:00 2007
New Revision: 1013
Log:
Traduzido até à linha 100
Modified:
trunk/pt-pt/ch01.xml
Modified: trunk/pt-pt/ch01.xml
==============================================================================
--- trunk/pt-pt/ch01.xml (original)
+++ trunk/pt-pt/ch01.xml Fri Aug 17 12:39:00 2007
@@ -56,42 +56,42 @@
<simplesect>
-<para>It would be tempting to say that free software projects fail for
-the same sorts of reasons proprietary software projects do.
-Certainly, free software has no monopoly on unrealistic requirements,
-vague specifications, poor resource management, insufficient design
-phases, or any of the other hobgoblins already well known to the
-software industry. There is a huge body of writing on these topics,
-and I will try not to duplicate it in this book. Instead, I will
-attempt to describe the problems peculiar to free software. When a
-free software project runs aground, it is often because the developers
-(or the managers) did not appreciate the unique problems of open
-source software development, even though they might have been quite
-prepared for the better-known difficulties of closed-source
-development.</para>
-
-<para>One of the most common mistakes is unrealistic expectations
-about the benefits of open source itself. An open license does not
-guarantee that hordes of active developers will suddenly volunteer
-their time to your project, nor does open-sourcing a troubled project
-automatically cure its ills. In fact, quite the opposite: opening up
-a project can add whole new sets of complexities, and cost
-<emphasis>more</emphasis> in the short term than simply keeping it
-in-house. Opening up means arranging the code to be comprehensible to
-complete strangers, setting up a development web site and email lists,
-and often writing documentation for the first time. All this is a lot
-of work. And of course, if any interested developers
-<emphasis>do</emphasis> show up, there is the added burden of
-answering their questions for a while before seeing any benefit from
-their presence. As developer Jamie Zawinski said about the troubled
-early days of the Mozilla project:</para>
+<para>Seria tentador dizer que os projectos de software livre falham pelas
+mesmas ordens de razões que os projectos de software proprietários.
+Certamente, que o software livre não tem o monopólio de requisitos
+irrealistas, especificações vagas, má gestão recursos, fases de concepção
+insuficientes ou qualquer dos outros bichos maus que já tão bem conhecemos.
+Há um enorme corpo de documentação escrito sobre estes tópicos e não
+os irei aqui duplicar. Em vez disso irei tentar descrever os problemas
+específicos do software livre. Quando um projecto de software livre
+aterra é frequente que tal se deva a que programadores (ou gestores)
+não tenham gostado dos problemas únicos do desenvolvimento de
+software «opem source» mesmo que tenham estado bem preparados para
+as dificuldades mais conhecidas do desenvolvimento de código fechado.</para>
+
+<para>Um dos erros mais comuns são expectativas irrealistas sobre as
+vantagens do próprio «open source». Uma licença «open source» não é
+garantia de que ordas de programadores activos voluntariem o seu tempo
+para o vosso projecto, nem efectuar «open-sourcing» cura automaticamente
+as mágoas de um projecto em problemas. De facto, normalmente o oposto:
+abrir um projecto pode adicionar um novo conjunto de complexidades, e
+custar a <emphasis>mais</emphasis> no curto prazo do que mantê-lo em casa.
+Abrir o código significa tornar o código compreensível a completos estranhos,
+criar um sítio na rede para o seu desenvolvimento e listas de correio, e
+frequentemente escrever documentação pela primeira vez. Tudo isto representa
+muito trabalho. E, claro está, se qualquer programador interessado
+<emphasis>aparecer</emphasis> há o peso adicional de lhes responder durante
+pelo menos algum tempo antes de começar a ver qualquer vantagem da sua
+presença. Como o programador Jamie Zawinski disse dos dias complicados iniciais
+do projecto Mozilla:</para>
<blockquote>
- <para><emphasis>Open source does work, but it is most definitely
- not a panacea. If there's a cautionary tale here, it is that
- you can't take a dying project, sprinkle it with the magic pixie
- dust of "open source," and have everything magically work
- out. Software is hard. The issues aren't that simple.</emphasis></para>
+ <para><emphasis>O «Open source» funciona mesmo, mas não é uma
+ panaceia, de todo. Se há uma uma verdade a extrair daqui é que
+ não pode tomar um projecto a morrer, deitar uns pós de perlim-pim-
+ -pim do «open source», e tudo funcionar como que por magia. O
+ software (moleware) é duro. Os problemas não são assim tão somples.
+ </emphasis></para>
<para>(from <emphasis role="bold"><ulink
url="http://www.jwz.org/gruntle/nomo.html"/></emphasis>)</para>
_______________________________________________
Producingoss-translators mailing list
[email protected]
http://www.red-bean.com/mailman/listinfo/producingoss-translators
