Carlos,
Este ficheiro não aparece como UTF-8. Já alterei.
Ari Constâncio
On 8/26/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> 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
>
>
_______________________________________________
Producingoss-translators mailing list
[email protected]
http://www.red-bean.com/mailman/listinfo/producingoss-translators
