Bom dia queridos!
No versículo anterior vimos a vigésima parte da tradução de “The Cathedral and the Bazaar”, hoje a parte 21.
O “esforço severo de muitas vontades convergentes” é precisamente o que um projeto como o Linux requer – e o “princípio de comando” é efetivamente impossível de ser aplicado entre voluntários no paraíso anarquista que chamamos de Internet. Para operar e competir efetivamente, os hackers que querem liderar projetos colaborativos têm que aprender como recrutar e energizar comunidades de interesse efetivas no modo vagamente sugerido pelo “princípio de compreensão” de Kropotkin. Eles devem aprender a usar a Lei de Linus. [SP]
Abra Sua Conta na BingX
Anteriormente eu me referi ao “efeito Delphi” como uma possível explicação para a Lei de Linus. Mas analogias mais poderosas aos sistemas adaptativos em biologia e em economia também se sugerem irresistivelmente. O mundo do Linux comporta-se em muitos aspectos como um mercado livre ou uma ecologia, uma coleção de agentes egoístas que tentam maximizar a utilidade que no processo produz uma ordem espontânea auto-corretiva mais elaborada e eficiente do que qualquer planejamento central poderia ter alcançado. Aqui, então, é o lugar para buscar o “princípio da compreensão”.
A “função de utilidade” que os hackers do Linux estão maximizando não é classicamente econômica, mas é o intangível de sua própria satisfação e reputação do ego entre outros hackers. (Pode-se chamar sua motivação de “altruísta”, mas isso ignora o fato de que o altruísmo é em si uma forma de satisfação do ego para o altruísta). Culturas voluntárias que funcionam dessa maneira não são incomuns; uma outra em que participei há muito tempo é o fandom de ficção científica, que, ao contrário do hackerdom, reconheceu explicitamente o “egoboo” (ego-boosting, ou a valorização da reputação entre outros fãs) como a motivação básica por trás da atividade voluntária.
Linus, posicionando-se com sucesso como o guardião de um projeto no qual o desenvolvimento é feito principalmente por outros, e estimulando o interesse pelo projeto até se tornar auto-sustentável, demonstrou uma compreensão aguda do “princípio da compreensão compartilhada” de Kropotkin. Essa visão quase econômica do mundo do Linux nos permite ver como esse entendimento é aplicado.
[SP] Naturalmente, a crítica de Kropotkin e a Lei de Linus levantam algumas questões mais amplas sobre a cibernética das organizações sociais. Outro teorema popular da engenharia de software sugere um deles; Lei de Conway – comumente declarada como “Se você tem quatro grupos trabalhando em um compilador, você obterá um compilador de 4 passos”. A afirmação original era mais geral: “Organizações que projetam sistemas são restringidas a produzir projetos que são cópias das estruturas de comunicação dessas organizações.” Podemos colocá-lo mais sucintamente como “Os meios determinam os fins”, ou até mesmo “O processo se torna produto”.
É digno de nota, portanto, que na comunidade de código aberto a forma e a função organizacional combina em muitos níveis. A rede está em tudo e em todos os lugares: não apenas a Internet, mas as pessoas que fazem o trabalho formam uma rede peer-to-peer distribuída, fracamente acoplada, que fornece redundância múltipla e degrada muito elegantemente. Em ambas as redes, cada nó é importante apenas na medida em que outros nós desejam cooperar com ele.
A parte peer-to-peer é essencial para a surpreendente produtividade da comunidade. O ponto que Kropotkin estava tentando fazer sobre as relações de poder é desenvolvido ainda mais pelo “Princípio SNAFU”: “A verdadeira comunicação é possível apenas entre iguais, porque os inferiores são mais consistentemente recompensados por dizer mentiras agradáveis a seus superiores do que por dizer a verdade”. O trabalho criativo em equipe depende totalmente da comunicação verdadeira e, portanto, está seriamente prejudicado pela presença de relações de poder. A comunidade de código aberto, efetivamente livre de tais relações de poder, está nos ensinando, em contraste, o quanto [as relações de poder] custam muito em bugs, em produtividade reduzida e em oportunidades perdidas.
Além disso, o princípio SNAFU prevê em organizações autoritárias uma desconexão progressiva entre os tomadores de decisão e a realidade, à medida que mais e mais dos insumos para aqueles que decidem tendem a se tornar mentiras agradáveis. A maneira como isso acontece no desenvolvimento de software convencional é fácil de ver; Há fortes incentivos para os inferiores esconderem, ignorarem e minimizarem os problemas. Quando esse processo se torna produto, o software é um desastre.
Fim da vigésima primeira, no versículo de amanhã a próxima. Grande abraço!
