Boa noite povo!
Seguimos com a tradução de “The Cathedral and the Bazaar”, hoje vemos a décima sétima parte. No versículo anterior, a 16ª.
Pré-condições Necessárias Para o Estilo Bazar
Os primeiros revisores e audiências de teste deste ensaio levantaram consistentemente questões sobre as condições prévias para o desenvolvimento bem-sucedido do estilo bazar, incluindo as qualificações do líder do projeto e o estado do código no momento em que se torna público e começa a tentar construir uma comunidade co-desenvolvedora.
É bastante claro que não se pode codificar a partir do zero no estilo bazar [IN]. Pode-se testar, depurar e melhorar no estilo bazar, mas seria muito difícil originar um projeto no modo bazar. Linus não tentou. Eu também não. Sua nascente comunidade de desenvolvedores precisa ter algo que possa ser executado e testado para ser usado.
[IN] Uma questão relacionada com a possibilidade de se iniciar projetos a partir do zero no estilo do bazar é se o estilo do bazar é capaz de apoiar um trabalho verdadeiramente inovador. Alguns afirmam que, sem uma liderança forte, o bazar só pode lidar com a clonagem e o aprimoramento de idéias já presentes no estado da engenharia, mas é incapaz de impulsionar o estado da arte. Este argumento foi talvez o mais infame feito pelos Documentos Halloween, dois memorandos internos embaraçosos da Microsoft escritos sobre o fenômeno do código aberto. Os autores compararam o desenvolvimento do Linux de um sistema operacional parecido com o Unix para “perseguir luzes traseiras” e opinaram “(uma vez que um projeto alcançou” paridade “com o estado da arte), o nível de gerenciamento necessário para avançar fronteiras torna-se massivo”.
Existem sérios erros de fato implicados neste argumento. Um é exposto quando os autores do Halloween observam mais tarde que “muitas vezes […] novas idéias de pesquisa são implementadas e disponibilizadas no Linux antes de serem disponibilizadas / incorporadas a outras plataformas”.
Se lermos “open source” para “Linux”, vemos que isso está longe de ser um fenômeno novo. Historicamente, a comunidade de código aberto não inventou o Emacs, nem a World Wide Web ou a própria Internet, perseguindo luzes traseiras ou sendo gerenciada maciçamente – e, no presente, há tanto trabalho inovador acontecendo em código aberto que a pessoa tem dificuldade de escolher. O projeto GNOME (para escolher um entre muitos) está empurrando o estado da arte em GUIs e tecnologia de objetos com a força suficiente para atrair uma considerável atenção na imprensa especializada em computadores, bem fora da comunidade Linux. Outros exemplos são numerosos, como uma visita a Freshmeat em qualquer dia irá provar rapidamente
Mas há um erro mais fundamental na suposição implícita de que o modelo catedral (ou o modelo de bazar, ou qualquer outro tipo de estrutura de gerenciamento) pode, de alguma forma, fazer com que a inovação aconteça de forma confiável. Isso não faz sentido. Equipes não têm insights inovadores – até mesmo grupos voluntários de anarquistas de bazar geralmente são incapazes de originalidade genuína, muito menos comitês corporativos de pessoas com uma participação de sobrevivência em algum status quo ante. O insight vem dos indivíduos. O máximo que a maquinaria social ao seu redor pode esperar fazer é ser receptivo a insights inovadores – nutrir, recompensar e testá-los rigorosamente, em vez de esmagá-los.
Alguns vão caracterizar isso como uma visão romântica, uma reversão para estereótipos de inventores solitários fora de moda. Nem tanto; Eu não estou afirmando que os grupos são incapazes de desenvolver idéias inovadoras depois de terem sido incubados; de fato, aprendemos com o processo de revisão por pares que esses grupos de desenvolvimento são essenciais para produzir um resultado de alta qualidade. Em vez disso, estou assinalando que todo desenvolvimento em grupo começa de – é necessariamente desencadeado por – uma boa ideia na cabeça de uma pessoa. Catedrais, bazares e outras estruturas sociais podem captar esse relâmpago e refiná-lo, mas não podem fazê-lo sob demanda.
Portanto, o problema básico da inovação (no software, ou em qualquer outro lugar) é, de fato, como não esmagá-lo – mas, ainda mais fundamentalmente, é como desenvolver muitas pessoas que podem ter insights em primeiro lugar.
Supor que o desenvolvimento ao estilo catedral pudesse administrar esse truque, mas as baixas barreiras de entrada e a fluidez do processo do bazar não, seria absurdo. Se o que é preciso é uma pessoa com uma boa ideia, então um meio social em que uma pessoa pode rapidamente atrair a cooperação de centenas ou milhares de pessoas com essa boa ideia inevitavelmente vai inovar mais do que em um em que a pessoa tenha que fazer um trabalho de “venda política” para uma hierarquia antes que ele possa trabalhar em sua ideia sem o risco de ser demitido.
E, de fato, se olharmos para a história da inovação de software pelas organizações que usam o modelo da catedral, descobrimos rapidamente que é bastante raro. Grandes corporações confiam na pesquisa universitária para novas idéias (daí a desconfiança dos autores do Halloween Documents sobre a facilidade do Linux em cooptar essa pesquisa mais rapidamente). Ou eles compram pequenas empresas construídas em torno do cérebro de alguns inovadores. Em nenhum dos casos a inovação é nativa da cultura da catedral; de fato, muitas inovações assim importadas acabam sendo silenciosamente sufocadas sob o “nível massivo de administração” que os autores do Halloween Documents tanto elogiam.
Fim da parte 17, amanhã a 18ª. Abraços!
