Author: cafonso Date: Sat Aug 18 06:00:44 2007 New Revision: 1016 Log: Finished first section of chapter 04
Modified: trunk/pt-pt/ch04.xml Modified: trunk/pt-pt/ch04.xml ============================================================================== --- trunk/pt-pt/ch04.xml (original) +++ trunk/pt-pt/ch04.xml Sat Aug 18 06:00:44 2007 @@ -1,97 +1,96 @@ <chapter id="social-infrastructure"> -<title>Social and Political Infrastructure</title> +<title>Infraestrutura Social e Pol�tica</title> <simplesect> -<para>The first questions people usually ask about free software are -"How does it work? What keeps a project running? Who makes the -decisions?" I'm always dissatisfied with bland responses about -meritocracy, the spirit of cooperation, code speaking for itself, etc. -The fact is, the question is not easy to answer. Meritocracy, -cooperation, and running code are all part of it, but they do little -to explain how projects actually run on a day-to-day basis, and say -nothing about how conflicts are resolved.</para> - -<para>This chapter tries to show the structural underpinnings -successful projects have in common. I mean "successful" not just in -terms of technical quality, but also operational health and -survivability. Operational health is the project's ongoing ability to -incorporate new code contributions and new developers, and to be -responsive to incoming bug reports. Survivability is the project's -ability to exist independently of any individual participant or -sponsor—think of it as the likelihood that the project would -continue even if all of its founding members were to move on to other -things. Technical success is not hard to achieve, but without a -robust developer base and social foundation, a project may be unable -to handle the growth that initial success brings, or the departure of -charismatic individuals.</para> - -<para>There are various ways to achieve this kind of success. Some -involve a formal governance structure, by which debates are resolved, -new developers are invited in (and sometimes out), new features -planned, and so on. Others involve less formal structure, but more -conscious self-restraint, to produce an atmosphere of fairness that -people can rely on as a <foreignphrase>de facto</foreignphrase> form -of governance. Both ways lead to the same result: a sense of -institutional permanence, supported by habits and procedures that are -well understood by everyone who participates. These features are even -more important in self-organizing systems than in centrally-controlled -ones, because in self-organizing systems, everyone is conscious that a -few bad apples can spoil the whole barrel, at least for a while.</para> +<para>A primeira pergunta que as pessoas fazem sobre o software livre � +"Como funciona? O que � que move um projecto? Quem toma decis�es?" +Fico sempre insatizfeito com respostas prontas sobre meritocracia, o +esp�rito de coopera��o, o c�digo falar por si mesmo, etc. +O facto � que a quest�o n�o tem resposta f�cil. A meritocracia, a +coopera��o e a execu��o de c�digo fazem parte da resposta, mas n�o +explicam como � que os projectos s�o geridos no dia-a-dia e nada dizem +sobre como s�o resolvidos os conflitos.</para> + +<para>Este cap�tulo tenta mostrar as funda��es estruturais que os projectos +bem sucedidos t�m em comum. Digo "bem sucedidos" n�o s� em termos de +qualidade t�cnica, mas tamb�m sa�de operacional e sobreviv�ncia. +Sa�de operacional � a capacidade sustendada de um projecto incorporar novas +contribui��es de c�digo e novos programadores e ter capacidade de resposta +aos relat�rios de erros que entrem. Capacidade de sobreviv�ncia � a capacidade +de um projecto existir independentemente de qualquer participante individual ou +sponsor; pense nisto como a probabilidade do projecto continuar mesmo que todos +os seus membros fundadores se mudarem para outras coisas. O sucesso t�cnico n�o +� dif�cil de alcan�ar, mas sem uma base de programadores e uma funda��o +social robustas, um projecto pode ser incapaz de tratar o crescimento que esse +sucesso inicial tr�s ou a partida de indiv�duos carism�ticos.</para> + +<para>H� v�rias maneiras de alcan�ar este tipo de sucesso. Algumas envolvem uma +estrutura de governo formal, pela qual os debates s�o resolvidos, os novos +programadores s�o admitidos (e por vezes exclu�dos), novas caracter�sticas +s�o planeadas e assim sucessivamente. Outras envolvem uma estrutura menos +formal, mas maior auto-controlo, para produzir uma atmosfera de justi�a em +que as pessoas possam confiar como uma forma de governa��o <foreignphrase>de +facto</foreignphrase>. Ambos os caminhos levam ao mesmo resultado, perenidade +institucional, suportada por h�bitos e procedimentos bem compreendidos por +todos os participantes. Estas caracter�sticas s�o ainda mais importantes +em sistemas auto-organizados do que em sistemas controlados centralmente, +porque em sistemas auto-organizados todos t�m consci�ncia que algumas ma�as +podres podem estragar toda a caixa, pelo menos durante algum tempo.</para> <sect1 id="forkability"> -<title>Forkability</title> +<title>Ramificabilidade</title> -<para>The indispensable ingredient that binds developers together on a -free software project, and makes them willing to compromise when -necessary, is the code's <firstterm>forkability</firstterm>: the -ability of anyone to take a copy of the source code and use it to -start a competing project, known as a <firstterm>fork</firstterm>. -The paradoxical thing is that the <emphasis>possibility</emphasis> of -forks is usually a much greater force in free software projects than -actual forks, which are very rare. Because a fork is bad for everyone -(for reasons examined in detail in -<xref linkend="forks"/><phrase output="printed"> in -<xref linkend="managing-volunteers"/></phrase>), the more serious -the threat of a fork becomes, the more willing people are to -compromise to avoid it.</para> - -<para>Forks, or rather the potential for forks, are the reason there -are no true dictators in free software projects. This may seem like a -surprising claim, considering how common it is to hear someone called -the "dictator" or "tyrant" in a given open source project. But this -kind of tyranny is special, quite different from the conventional -understanding of the word. Imagine a king whose subjects could copy -his entire kingdom at any time and move to the copy to rule as they -see fit. Would not such a king govern very differently from one whose -subjects were bound to stay under his rule no matter what he -did?</para> - -<para>This is why even projects that are not formally organized as -democracies are, in practice, democracies when it comes to important -decisions. Replicability implies forkability; forkability implies -consensus. It may well be that everyone is willing to defer to one -leader (the most famous example being Linus Torvalds in Linux kernel -development), but this is because they <emphasis>choose</emphasis> to -do so, in an entirely non-cynical and non-sinister way. The dictator -has no magical hold over the project. A key property of all open -source licenses is that they do not give one party more power than any -other in deciding how the code can be changed or used. If the dictator -were to suddenly start making bad decisions, there would be -restlessness, followed eventually by revolt and a fork. Except, of -course, things rarely get that far, because the dictator compromises -first.</para> - -<para>But just because forkability puts an upper limit on how much -power anyone can exert in a project doesn't mean there aren't -important differences in how projects are governed. You don't want -every decision to come down to the last-resort question of who is -considering a fork. That would get tiresome very quickly, and sap -energy away from real work. The next two sections examine different -ways to organize projects such that most decisions go smoothly. These -two examples are somewhat idealized extremes; many projects fall -somewhere along a continuum between them.</para> +<para>O ingrediente indispens�vel que serve de argamassa a que os programadores +se mantenham unidos num projecto de software livre e os leva a estarem dispon�veis +para o compromisso quando necess�rio � a <firstterm>ramificabilidade</firstterm>: a +capacidade de qualquer pessoa a partir de uma c�pia do c�digo fonte e usando-o como +base come�ar um projecto concorrente, conhecido como <firstterm>ramo (fork)</firstterm>. +A coisa paradoxal � que � esta <emphasis>possibilidade </emphasis> de ramos � +normalmente uma for�a muito maior nos projectos de software livre que os +ramos reais, os quais s�o muito raros. Porque um ramo � mau para toda a gente +(por raz�es explicadas em detalhe em +<xref linkend="forks"/><phrase output="printed"> em +<xref linkend="managing-volunteers"/></phrase>), quanto mais +s�ria uma amea�a de ramifica��o fica, mais as pessoas est�o dispostas a +efectuar um compromisso para a evitar.</para> + +<para>Os ramos, ou o potencial para o seu surgimento melhor dizendo, � +a raz�i pela qual nos projectos de software livre n�o h� verdadeiros +ditadores. Pode parecer uma afirma��o surpreendente, tendo em conta a +frequ�ncia com que se ouve falar de "ditador" ou de "tirano" num dado +projecto de �open source�. Mas este tipo de tirania � especial, muito +diferente do significado convencional da palavra. Imagine um rei cujos +subditos possam copiar o seu reino completo a qualquer momento e possam +mudar para a c�pia para governarem como acharem mais apropriado. Esse +rei n�o governaria de modo completamente diferente daquele ao qual os subditos +est�o sob tutela independentemente do que ele fa�a?</para> + +<para>� por esta raz�o que projectos que n�o t�m uma organiza��o formal +como democracias s�o, na pr�tica, democracias quando se chega ao momento +de tomar decis�es importantes. A replicabilidade implica a ramificabilidade; +a ramificabilidade implica o concenso. � perfeitamente poss�vel que se +deseje atribuir a um l�der (o exemplo mais famoso � o de Linus Torvalds no +desenvolvimento do cerne do Linux), mas isso foi porque assim o +<emphasis>escolheram</emphasis>, de uma maneira n�o c�nica e n�o sinistra. +O ditador n�o tem uma m�o m�gica sobre o projecto. A propriedade chave de +todas as licen�as de �open source� � n�o darem a ningu�m mais poder do que a +qualquer outra entidade na decis�o de como o c�digo pode ser alterado ou +usado. Se o ditador come�ar de repente a tomar decis�es m�s, haver� uma paragem +de actividade, seguida eventualmente de uma revolta e uma ramifica��o. Claro +que isto normalmente n�o chega t�o longe porque o ditador faz um compromisso +antes.</para> + +<para>Mas s� porque a ramificabilidade coloca um limite m�ximo no poder que +uma pessoa pode exercer num projecto n�o quer com isto dizer que n�o haja +importantes diferen�as em como os projectos sejam governados. N�o quer que +cada decis�o venha at� � pergunta extrema de quem est� a pensar num ramo. +Isso seria cansativo muito rapidamente, retirando energia do trabalho +propriamente dito. As duas sec��es seguintes examinam maneiras diferentes de +organizar projectos de tal modo que a maior parte das decis�es sejam +adoptadam sem guerra. Estes dois exemplos s�o de algum modo extremos ideais; +v�rios projectos caiem no continuo entre ambos.</para> </sect1> @@ -101,7 +100,7 @@ <simplesect id="benevolent-dictator"></simplesect> <!-- ======================== SECTION ============================== --> <sect1 id="benevolent-dictator"> -<title>Benevolent Dictators</title> +<title>Ditador Benevolente</title> <para>The <firstterm>benevolent dictator</firstterm> model is exactly what it sounds like: final decision-making authority rests with one
_______________________________________________ Producingoss-translators mailing list [email protected] http://www.red-bean.com/mailman/listinfo/producingoss-translators
