Author: cafonso
Date: Sun Aug 26 06:18:48 2007
New Revision: 1105
Log:
Chap 05 first 100 lines, 1st section
Modified:
trunk/pt-pt/ch05.xml
Modified: trunk/pt-pt/ch05.xml
==============================================================================
--- trunk/pt-pt/ch05.xml (original)
+++ trunk/pt-pt/ch05.xml Sun Aug 26 06:18:48 2007
@@ -3,98 +3,101 @@
<title>Dinheiro</title>
<simplesect>
-
-<para>This chapter examines how to bring funding into a free software
-environment. It is aimed not only at developers who are paid to work
-on free software projects, but also at their managers, who need to
-understand the social dynamics of the development environment. In the
-sections that follow, the addressee ("you") is presumed to be either a
-paid developer, or one who manages such developers. The advice will
-often be the same for both; when it's not, the intended audience will
-be made clear from context.</para>
-
-<para>Corporate funding of free software development is not a new
-phenomenon. A lot of development has always been informally
-subsidized. When a system administrator writes a network analysis
-tool to help her do her job, then posts it online and gets bug fixes
-and feature contributions from other system administrators, what's
-happened is that an unofficial consortium has been formed. The
-consortium's funding comes from the sysadmins' salaries, and its
-office space and network bandwidth are donated, albeit unknowingly, by
-the organizations they work for. Those organizations benefit from the
-investment, of course, although they may not be institutionally aware
-of it at first.</para>
-
-<para>The difference today is that many of these efforts are being
-formalized. Corporations have become conscious of the benefits of
-open source software, and started involving themselves more directly
-in its development. Developers too have come to expect that really
-important projects will attract at least donations, and possibly even
-long-term sponsors. While the presence of money has not changed the
-basic dynamics of free software development, it has greatly changed
-the scale at which things happen, both in terms of the number of
-developers and time-per-developer. It has also had effects on how
-projects are organized, and on how the parties involved in them
-interact. The issues are not merely about how the money is spent, or
-how return on investment is measured. They are also about management
-and process: how can the hierarchical command structures of
-corporations and the semi-decentralized volunteer communities of free
-software projects work productively with each other? Will they even
-agree on what "productively" means?</para>
-
-<para>Financial backing is, in general, welcomed by open source
-development communities. It can reduce a project's vulnerability to the
-Forces of Chaos, which sweep away so many projects before they really
-get off the ground, and therefore it can make people more willing to
-give the software a chance—they feel they're investing their
-time into something that will still be around six months from now.
-After all, credibility is contagious, to a point. When, say, IBM
-backs an open source project, people pretty much assume the project
-won't be allowed to fail, and their resultant willingness to devote
-effort to it can make that a self-fulfilling prophecy.</para>
-
-<para>However, funding also brings a perception of control. If not
-handled carefully, money can divide a project into in-group and
-out-group developers. If the unpaid volunteers get the feeling that
-design decisions or feature additions are simply available to the
-highest bidder, they'll head off to a project that seems more like a
-meritocracy and less like unpaid labor for someone else's benefit.
-They may never complain overtly on the mailing lists. Instead, there
-will simply be less and less noise from external sources, as the
-volunteers gradually stop trying to be taken seriously. The buzz of
-small-scale activity will continue, in the form of bug reports and
-occasional small fixes. But there won't be any large code
-contributions or outside participation in design discussions. People
-sense what's expected of them, and live up (or down) to those
-expectations.</para>
-
-<para>Although money needs to be used carefully, that doesn't mean it
-can't buy influence. It most certainly can. The trick is that it
-can't buy influence directly. In a straightforward commercial
-transaction, you trade money for what you want. If you need a feature
-added, you sign a contract, pay for it, and it gets done. In an open
-source project, it's not so simple. You may sign a contract with some
-developers, but they'd be fooling themselves—and you—if
-they guaranteed that the work you paid for would be accepted by the
-development community simply because you paid for it. The work can
-only be accepted on its own merits and on how it fits into the
-community's vision for the software. You may have some say in that
-vision, but you won't be the only voice.</para>
-
-<para>So money can't purchase influence, but it can purchase things
-that <emphasis>lead to</emphasis> influence. The most obvious example
-is programmers. If good programmers are hired, and they stick around
-long enough to get experience with the software and credibility in the
-community, then they can influence the project by the same means as
-any other member. They will have a vote, or if there are many of
-them, they will have a voting bloc. If they are respected in the
-project, they will have influence beyond just their votes. There is
-no need for paid developers to disguise their motives, either. After
-all, everyone who wants a change made to the software wants it for a
-reason. Your company's reasons are no less legitimate than anyone
-else's. It's just that the weight given to your company's goals will
-be determined by its representatives' status in the project, not by
-the company's size, budget, or business plan.</para>
+<para>Este cap�tulo examina como trazer fundos para o ambiente do
+software livre. Destina-se n�o s� aos programadores quer s�o pagos
+para trabalhar em projectos de software livre, mas tamb�m os seus
+gestores, que necessitam de compreender as din�micas sociais do
+ambiente de desenvolvimento. Nas sec��es seguintes, o destinat�rio
+("voc�") presume-se ser ou um programador pago ou algu�m que gere
+tais programadores. O conselho ser� frequentemente o mesmo para
+ambos; quando n�o, a audi�ncia destinat�ria ser� tornada clara pelo
+contexto.</para>
+
+<para>O custeio por parte de empresas de desenvolvimento de software
+livre n�o � um fen�meno novo. Muito do desenvolvimento foi sempre
+informalmente subsidiado. Quando um administrador de sistemas escreve
+uma ferramenta de an�lise de rede para o ajudar nas suas tarefas e que
+depois a coloca em linha e obt�m correc��es de erros e contribui��es
+com novas caracter�sticas de outros administradores de sistemas, o
+que sucedeu foi ter-se formado um cons�rcio n�o formal. Os fundos do
+cons�rcio prov�m dos sal�rios dos administradores de sistemas e do
+seu espa�o de escrit�rio e largura de banda doados, mesmo que
+ignorado, pelas organiza��es onde trabalham. Estas organiza��es
+tiram benef�cios do investimento, claro, embora possam n�o estar
+institucionalmente conscientes de tal facto.</para>
+
+<para>A diferen�a actualmente � que muitos destes esfor�os est�o a ser
+formalizados. As empresas ficaram conscientes das vantagens do software
+open source, e come�aram-se a envolver elas pr�prias mais directamente
+no seu desenvolvimento. Os programadores tamb�m come�aram a ter
+expectativas que os projectos importantes atra�ssem doa��es sen�o mesmo
+apoios de longo prazo. Enquanto a presen�a do dinheiro n�o alterou a
+din�mica fundamental do desenvolvimento do software livre, mudou
+grandemente a escala de como as coisas sucedem, tanto em termos de
+n�mero de programadores como de n�mero de horas por programador. Tamb�m
+teve efeitos em como os projectos s�o organizados e como � que as
+v�rias entidades envolvidas interagem. Os assuntos n�o s�o de mera
+atribui��o de despesas ou como � que o retorno do investimento � medido.
+Trata-se tamb�m de gest�o e processo: como � que estruturas hier�rquicas
+de comando das empresas e de comunidades de volunt�rios
+semi-descentralizadas de projectos de software livre trabalham
+produtivamente umas com as outras? Ser� que conseguem acordar sobre o
+que significa "produtividade"?</para>
+
+<para>O suporte financeiro, em geral, � bem vindo pelas comunidades
+de open source. Pode reduzir a vulnerabilidade do projecto �s For�as
+do Caos, que deitam abaixo muitos projectos mesmo antes de eles
+come�arem, e assim pode tornar as pessoas mais dispostas a dar uma
+oportunidade ao software — As pessoas sentem estar a investir
+o seu tempo em algo que ainda andar� por c� nos pr�ximos seis meses.
+Quando, digamos, a IBM suporta um projecto de open source, as pessoas
+presumem que o projecto n�o ser� deixado falhar e ficam com mais
+disposi��o para envidarem esfor�os para tornar tal um profecia
+auto-induzida.</para>
+
+<para>Contudo, o suporte financeiro tr�s uma percep��o de controlo.
+Se n�o for cuidadosamente tratado, o dinheiro pode dividir um projecto
+em programadores do cerne e programadores externos. Se os volunt�rios
+n�o pagos ficam a sentir que as decis�es de concep��o ou as introdu��es
+de caracter�sticas est�o simplesmente dispon�veis para quem paga mais,
+saiam do projecto para se integrarem num que se assemelhe mais a uma
+meritocracia e menos como trabalho subordinado para proveito de outrem.
+Podem nunca reclamar abertamente nas listas de distribui��o de correio.
+Em vez disso, haver� simplesmente menos e menos ru�do de fontes externas,
+� medida que os volunt�rios gradualmente deixarem de tentar ser levados
+a s�rio. O ru�do da actividade de pequena escala ir� continuar, na forma
+de relat�rios de erros e correc��es pequenas ocasionais. Mas n�o haver�
+contribui��es significativas de c�digo ou participa��o externa em
+discuss�es sobre concep��o. As pessoas sentem o que se espera delas,
+e vivem (ou n�o) de acordo com essas expectativas.</para>
+
+<para>Embora o dinheiro necessite ser usado com cuidado, isso n�o significa
+que n�o possa comprar influ�ncia. Claro que pode. O truque � que n�o pode
+comprar influ�ncia de modo directo. Numa transac��o comercial directa,
+troca dinheiro por aquilo que deseja. Se necessita de ver introduzir uma
+caracter�stica, assina um contrato, paga-o e isso � feito. Num projecto
+open source, tal n�o � assim t�o simples. Pode assinar um contrato com
+alguns programadores, mas eles estar�o a enganar-se a si pr�prios —
+e a si — se lhe garantirem que o trabalho que pagou ser� aceite
+pela comunidade de desenvolvimento simplesmente porque pagou por ele. O
+trabalho s� poder� ser aceite se tiver m�rito pr�prio e se se enquadrar
+na vis�o da comunidade para o software. Poder� ter algo a dizer nessa
+vis�o, mas n�o vai ser a �nica voz.</para>
+
+<para>Assim o dinheiro n�o pode comprar influ�ncia mas pode comprar coisas
+que <emphasis>conduzam �</emphasis> influ�ncia. A coisa mais �bvia s�o
+programadores. Se os bons programadores forem empregues e se se mantiverem
+durante tempo suficiente, ent�o eles podem influenciar o projecto da mesma
+forma que qualquer outro membro. Eles ir�o ter um voto, ou se forem
+v�rios um bloco de vota��o. Se forem respeitados no projecto, ir�o
+influenciar para al�m dos seus pr�prios votos. N�o � necess�rio aos
+programadores mascararem os seus motivos. Independentemente de qualquer
+outra coisa, todos os que desejem que uma mudan�a seja feita ao software
+desejam-na por alguma raz�o. As raz�es da sua empresa n�o s�o menos
+leg�timas do que as raz�es de qualquer outra pessoa. S� que o peso
+dado aos objectivos da sua empresa ser�o determinados pelo estatuto
+dos seus representantes no projecto e n�o pelo tamanho, or�amento ou plano
+de neg�cios da empresa.</para>
</simplesect>
_______________________________________________
Producingoss-translators mailing list
[email protected]
http://www.red-bean.com/mailman/listinfo/producingoss-translators
