Boa tarde povo!
Seguimos a tradução de “The Cathedral and the Bazaar”. Vimos no versículo último a parte 22. Hoje vemos a vigésima terceira.
Sobre Gestão e a Linha Maginot
O artigo original Cathedral and Bazaar de 1997 terminou com a visão acima – de felizes hordas em rede de programadores/anarquistas competindo com o mundo hierárquico do software fechado convencional.
Muitos céticos não estavam convencidos, no entanto; e as perguntas que eles levantam merecem um engajamento justo. A maioria das objeções ao argumento do bazar se resume à alegação de que seus proponentes subestimaram o efeito multiplicador de produtividade da administração convencional.
Os gerentes de desenvolvimento de software com mentalidade tradicional frequentemente objetam que a casualidade com que os grupos de projetos se formam, mudam e se dissolvem no mundo do código aberto nega uma parte significativa da aparente vantagem dos números que a comunidade de código aberto tem sobre qualquer desenvolvedor de código fechado sozinho. Eles observariam que no desenvolvimento de software é realmente o esforço sustentado ao longo do tempo e o grau em que os clientes podem esperar investimento contínuo no produto que importa, não apenas quantas pessoas jogaram um osso na panela e o deixaram ferver.
Há algo nesse argumento, com certeza; De fato, desenvolvi a idéia de que o valor esperado do serviço futuro é a chave para a economia da produção de software no ensaio The Magic Cauldron.
Mas esse argumento também tem um grande problema oculto; sua suposição implícita de que o desenvolvimento de código aberto não pode fornecer tal esforço sustentado. De fato, tem havido projetos de código aberto que mantiveram uma direção coerente e uma comunidade de mantenedores eficaz por longos períodos de tempo, sem os tipos de estruturas de incentivo ou controles institucionais que a gerência convencional considera essenciais. O desenvolvimento do editor GNU Emacs é um exemplo extremo e instrutivo; Ele absorveu os esforços de centenas de colaboradores ao longo de 15 anos em uma visão arquitetônica unificada, apesar da alta rotatividade e do fato de que apenas uma pessoa (seu autor) esteve continuamente ativa durante todo esse tempo. Nenhum editor de código fechado já correspondeu a esse registro de longevidade.
Isso sugere uma razão para questionar as vantagens do desenvolvimento de software gerenciado convencionalmente que é independente do restante dos argumentos sobre o modo catedral versus modo o bazar. Se é possível para o GNU Emacs expressar uma visão arquitetural consistente ao longo de 15 anos, ou para um sistema operacional como o Linux fazer o mesmo ao longo de 8 anos de tecnologia de hardware e plataforma que muda rapidamente; e se (como é de fato o caso) tem havido muitos projetos de código aberto bem arquitetados de mais de 5 anos de duração – então temos o direito de nos perguntar o que é, na verdade, que o enorme overhead [sobrecarga] do desenvolvimento gerenciado convencionalmente está nos fornecendo.
O que quer que seja, certamente, não inclui execução confiável por prazo, ou dentro do orçamento, ou para todos os recursos da especificação; é um projeto raro ‘gerenciado’ que atende a um desses objetivos, sem falar nos três. Também não parece ser a capacidade de se adaptar às mudanças na tecnologia e no contexto econômico durante a vida do projeto; a comunidade de código aberto provou ser muito mais eficaz nesse aspecto (como se pode verificar prontamente, por exemplo, comparando a história de 30 anos da Internet com as meias-vidas curtas das tecnologias proprietárias de rede – ou o custo da transição de 16-bit para 32-bit no Microsoft Windows com a migração quase sem esforço do Linux durante o mesmo período, não apenas ao longo da linha de desenvolvimento da Intel, mas para mais de uma dúzia de outras plataformas de hardware, incluindo o Alpha de 64 bits também).
Uma coisa que muitas pessoas pensam que o modo tradicional lhe compra é alguém para responsabilizar legalmente e potencialmente recuperar a compensação se o projeto der errado. Mas isso é uma ilusão; a maioria das licenças de software são escritas para negar até mesmo garantias de comercialização, e muito menos de desempenho – e casos de recuperação bem-sucedida de falta de desempenho de software são extremamente raros. Mesmo que fossem comuns, sentir-se confortado por ter alguém para processar estaria perdendo o ponto. Você não queria estar em uma ação judicial; você queria software funcionando.
Terminada a parte 23. No versículo próximo a 24. Abraços, até amanhã!
