É um artigo de engenharia de software de 1997 por Eric S. Raymond, autor e hacker oldschool, que analisa o método de desenvolvimento do Linux, uma nova maneira de desenvolver FOSS em massa por com relativamente pouco planejamento central, esse método é chamado de bazar, e é contrastado com o método Catedral, i.e, o desenvolvimento tradicional e centralizado de softwar, não necessariamente proprietário. Este ensaio foi posteriormente expandido, atualizado e transformado em um livro inteiro, a versão curta pode ser lida no site da ESR. Ele desempenhou um papel nas corporações que adotaram o código aberto. Raymond costumava ser um hacker oldschool que como muitos outros, se voltou para o lado maligno quando sentiu o cheiro de dinheiro e fama, ele basicamente se tornou um industrialista hardcore, promovendo código aberto, mercados livres e fazendo negócios. Isso pode ser visto muito bem no ensaio, não é sobre programação, é sobre engenharia de software, gerenciar e manipular massas de pessoas para trabalhar como máquinas que estarão continuamente produzindo LOC. Ele se concentrou em coisas como produtividade e como desenvolver bloat da maneira mais rápida e barata. Ele apoia a cultura de atualização, desenvolvimento rápido e projetos de software gigantescos. A filosofia SMR não vê utilidade nesse artigo, mas pode ser bom ler para ter uma visão geral. ESR acreditava que software além de algum limite de complexidade, como o kernel, tem que ser desenvolvido por uma equipe pequena que se comunica de perto, corrige cuidadosamente os bugs que os usuários relatam e lança versões estáveis uma vez em um tempo relativamente longo, mesmo se o software for FOSS e o desenvolvimento for transparente. Isso é chamado de método Catedral, pois o desenvolvimento é semelhante à construção cuidadosa e altamente centralizada de uma catedral, como o GCC e qualquer software proprietário, pois eles não têm outra opção. Depois de ver o Linux sendo desenvolvido por muitas pessoas de uma maneira descentralizada, com o coordenador central fazendo pouco trabalho e tendo ciclos de lançamento curtos, mesmo de versões instáveis e cheias de bugs, ele concluiu que pode ter uma forma diferente, e chamou de método bazar, que parece caótico no começo, mas que estatisticamente ainda converge para estabelecer um bom design final. Ele diz que a maior invenção de Linus não é o Linux, mas seu modelo de desenvolvimento. Que também está no seu projeto, o fetchmail.
Ele observa várias coisas. Como usuários sendo ao mesmo tempo programadores sendo é fundamental, porque programadores realmente se importam com o que escrevem e recebem bons relatórios de bugs. Dados olhos suficientes, todos os bugs são superficiais, conforme a lei de Linus, diz que com muitos usuários e programadores os bugs são detectados e corrigidos rapidamente, o que é ajudado pelos ciclos de lançamento rápidos, se alguém corrige rapidamente, outros veem que foi corrigido e param de trabalhar em suas correções mais complicadas. Isso paraleliza a depuração. Lançamentos rápidos recompensam contribuidores, ficando motivados. Trate seus testadores como recurso mais valioso e eles responderão se tornando seu recurso mais valioso, até mesmo o trabalho que ninguém quer fazer é feito. O projeto bazar precisa de várias coisas. Uma boa Internet, é por isso que o Linux coincidiu com o acesso barato à Internet. Não pode ser iniciado do zero, alguém tem que fazer o projeto basicamente sozinho, e deve ser um projeto realmente honesto, não algo que visa apenas o lucro, geralmente começando com um programador é o suficiente para fazer um projeto que pareça promissor para que as pessoas comecem a se envolver. O líder não precisa ser um gênio, mas ser capaz de reconhecer boas escolhas de design. Então ele passa a compará-lo ao mercado livre e outras merdas, coincidindo que gerentes são inúteis e eles fingem ser úteis.
Impulsionado por nada. Todo conteúdo é disponível sob CC0 1.0 domínio público. Envie comentários e correções para Mr. Unix em victor_hermian@disroot.org.