É 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, i.e, gerenciar e manipular massas de pessoas para trabalhar como máquinas que estarão continuamente produzindo linhas de código. 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. Portanto, 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, e.g, 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.