1) O documento resume as principais lições aprendidas por Eric Raymond ao desenvolver o projeto de software livre Popclient utilizando o modelo de desenvolvimento "Bazar". 2) Raymond apresentou essas lições no documento "A Catedral e o Bazar" em 1997, comparando os modelos de desenvolvimento "Catedral" e "Bazar". 3) As lições enfatizam a importância da colaboração aberta, do feedback dos usuários, da distribuição frequente de versões e da liderança sem coerção no modelo de desenvolvimento "Bazar".

1. de Eric S. Raymond
André Luis Schwerz
André Luiz Satoshi Kawamoto
Rafael Liberato Roberto
Fevereiro / 2012
By André Luis Schwerz, André Luiz Kawamoto and Rafael Liberato
Roberto. Este trabalho foi licenciado com uma Licença Creative
Commons - Atribuição 3.0 Não Adaptada.

2. Roteiro
• Eric Steven Raymond.
• Contexto histórico.
• A catedral e o bazar.
• Lições do estilo bazar.
• Críticas ao documento.
• Influência exercida.
2

3. Eric Steven Raymond
• Nascido em Boston, Massachusetts
em 1957.
• Fez cursos de graduação e pós-
graduação em matemática e filosofia
na Universidade da Pennsylvania.
• Contribuiu com os projetos EMACS,
Linux, GNU entre outros.
• Autor de A Catedral e o Bazar em 1997.
• Co-fundador do Open Source Initiative em 1998.
3

4. Contexto Histórico
Eric Raymond
apresenta “A
Catedral e o
Bazar”
4

5. Contexto Histórico
Richard
Stallman lança
o projeto GNU
Eric Raymond
apresenta “A
Catedral e o
Bazar”
5

6. Contexto Histórico
Richard
Stallman lança
o projeto GNU
Linus Torvalds
propõe a Eric Raymond
criação do apresenta “A
Linux Catedral e o
Bazar”
6

7. Contexto Histórico
Richard
Stallman lança Explosão da
o projeto GNU Internet
Linus Torvalds
propõe a Eric Raymond
criação do apresenta “A
Linux Catedral e o
Bazar”
7

8. Contexto Histórico
Richard Netscape Eric Raymond e
Stallman lança Explosão da outros lançam o
libera o movimento de código
o projeto GNU Internet
código-fonte aberto
Linus Torvalds
propõe a Eric Raymond
criação do apresenta “A
Linux Catedral e o
Bazar”
8

9. Contexto Histórico
Richard Netscape Eric Raymond e
Stallman lança Explosão da outros lançam o
libera o movimento de código
o projeto GNU Internet
código-fonte aberto
Linus Torvalds Sourceforge Wikipedia é
Eric Raymond é lançado lançada
propõe a
criação do apresenta “A
Linux Catedral e o OpenOffice
Bazar” é lançado
9

10. A Catedral e o Bazar
• Linux Kongress (27 de maio de 1997, Alemanha).
• Parte do livro com o mesmo nome em 1999.
– Primeiro livro comercial sob a licença Open Publication
License (Creative Commons).
10

11. A Catedral e o Bazar
CATEDRAL BAZAR
Ambiente fechado e Ambiente aberto , onde todos
altamente hierarquizada podem participar
Pequeno grupo de líderes e Número indefinido de líderes
desenvolvedores e desenvolvedores
Desenvolvimento centralizado Desenvolvimento Cooperativo
Somente versões estáveis
Liberação de várias versões
e/ou beta
Modelo de desenvolvimento Sem metodologia definida
clássico
11

12. A Catedral e o Bazar
Richard
Stallman lança Explosão da
o projeto GNU Internet
Inspiração.
• Linux.
• Experiência no
desenvolvimento de um
software livre (1996)
Linus Torvalds
propõe a Eric Raymond
criação do apresenta “A
Linux Catedral e o
Bazar”
12

13. Necessidade de um
Mudança do
software para Encontrando uma Raymond as
FetchPop para o
gerenciamento de boa solução parcial projeto do P
PopMail
Popclient
e-mail
1 2 3 4
LIÇÕES
13

14. HISTÓRIA Necessidade de um Mudança do
Encontrando uma Ra
cliente de correio boa solução parcial
FetchPop para o
pro
eletrônico PopMail
Popclient
1 2 3
1 - Todo bom trabalho de software começa colocando
o dedo na ferida de um programador.
• Necessidade e vontade.
LIÇÕES
• Possível razão para a qualidade do software (Linux).
14

15. HISTÓRIA Necessidade de um
Mudança do
software para Encontrando uma Ra
FetchPop para o
gerenciamento de boa solução parcial pro
PopMail
Popclient
e-mail
1 2 3
2 - Bons programadores sabem o que escrever.
Grandes programadores sabem o que reescrever (e
reusar).
LIÇÕES
• Linus: Minix → Linux.
• Raymond: Fetchpop.
15

16. HISTÓRIA Necessidade de um Mudança do
software para Encontrando uma Ra
gerenciamento de boa solução parcial
FetchPop para o pro
e-mail Popclient
1 2 3
3 - “Planeje jogar algo fora; você irá, de qualquer
maneira.” (Fred Brooks, “The Mythical Man-Month”, Capítulo 11).
• Popclient (Carl Harris)
LIÇÕES
• Compreensão do problema após a implementação da
primeira solução.
• Recomeçar pelo menos uma vez.
16

17. HISTÓRIA Raymond decide Alterou a estrutura Raym
Raymond assume o
testar o modelo de dados e adicionou p
projeto do Popclient Bazar o suporte ao IMAP c
4 5 6 7 8 9
4 - Se você tem a atitude certa, problemas
interessantes irão encontrá-lo.
• Raymond encontra um projeto abandonado.
LIÇÕES
• Consenso de que Raymond deveria assumir o projeto.
17

18. HISTÓRIA Raymond decide Alterou a estrutura Raym
Raymond assume o
testar o modelo de dados e adicionou p
projeto do Popclient Bazar o suporte ao IMAP c
4 5 6 7 8 9
5 - Quando você perde o interesse em um programa,
sua última obrigação é entregá-lo a um sucessor
competente.
LIÇÕES
• Atitude de Carl Harris.
• Encontrar outra pessoa competente para continuar o
desenvolvimento.
18

19. HISTÓRIA Raymond decide Alterou a estrutura Raym
Raymond assume o
projeto do Popclient testar o modelo de dados e adicionou p
Bazar o suporte ao IMAP c
4 5 6 7 8 9
6 - Tratar seus usuários como colaboradores é o
caminho mais fácil para uma melhora rápida do
código e uma depuração eficaz.
• Usuários irão diagnosticar problemas, sugerir
LIÇÕES
correções e ajudar com melhorias.
19

20. HISTÓRIA Raymond decide Alterou a estrutura Raym
Raymond assume o
projeto do Popclient testar o modelo de dados e adicionou p
Bazar o suporte ao IMAP c
4 5 6 7 8 9
7 - Distribua logo e com frequência. E ouça seus
clientes.
• Mantém os colaboradores estimulados e
LIÇÕES
recompensados.
20

21. HISTÓRIA Raymond decide Alterou a estrutura Raym
Raymond assume o
projeto do Popclient testar o modelo de dados e adicionou p
Bazar o suporte ao IMAP c
4 5 6 7 8 9
8 - Dada uma base grande o suficiente de beta-testers
e colaboradores, quase todo problema será
caracterizado rapidamente e a solução será óbvia
para alguém.
LIÇÕES
• “Havendo olhos suficientes, todos os erros são
óbvios.” (chamada de Lei de Linus por Raymond)
• Alguns encontram problemas, outros entendem e os
resolvem.
• Catedral ≠ Bazar.
21

22. HISTÓRIA Raymond decide Alterou a estrutura de Raym
Raymond assume o
projeto do Popclient
testar o modelo dados e adicionou o p
Bazar suporte ao IMAP c
4 5 6 7 8 9
9 - Estrutura de dados inteligente e código burro
trabalham muito melhor que o contrário.
• Dificuldade de entender código alheio.
LIÇÕES
• O entendimento da estrutura facilita a compreensão
do código.
22

23. HISTÓRIA Raymond divulga o Su
Troca de nome para
projeto para a Suporte ao SMTP
FetchMail
–
comunidade
10 11 12 13
10 - Se você tratar seus beta-testers como seu
recurso mais valioso, eles irão responder tornando-se
seu mais valioso recurso.
• Anunciar novas versões estimulando a participação
LIÇÕES
das pessoas.
• Tamanho da lista de colaboradores do Popclient.
• Ciclo de vida de um projeto maduro no estilo bazar.
23

24. HISTÓRIA Raymond divulga o Su
Troca de nome para
projeto para a Suporte ao SMTP FetchMail
–
comunidade
10 11 12 13
11 - A melhor coisa depois de ter boas ideias é
reconhecer boas ideias dos seus usuários.
• Entender as implicações de uma ideia brilhante de um
LIÇÕES
usuário (SMTP de Harry Hoschheiser).
• Levar os “créditos” pela invenção.
24

25. HISTÓRIA Raymond divulga o Su
Troca de nome para
projeto para a Suporte ao SMTP FetchMail
–
comunidade
10 11 12 13
12 - Frequentemente, as soluções mais
impressionantes e inovadoras surgem quando se
percebe que o conceito do problema estava errado.
LIÇÕES
• Você está tratando o problema corretamente?
• Não hesite em jogar fora características obsoletas.
25

26. HISTÓRIA Raymond divulga o Su
Troca de nome para
projeto para a Suporte ao SMTP –
comunidade FetchMail
10 11 12 13
13 - “A perfeição *em projetar+ não é alcançada
quando não há mais nada a adicionar, mas quando
não há nada para jogar fora.” (por Antoine de Saint-Exupéry)
LIÇÕES
• Amadurecimento do projeto.
• Hora de uma nova identidade.
26

27. HISTÓRIA Suporte a multidrop –
Suporte a MIME
necessidade de outros 8 Bits
Lições adicionais
usuários
14 15 16 17 18 19
14 - Qualquer ferramenta deve ser útil da maneira
esperada, mas uma grande ferramenta conduz a usos
inesperados.
• Considerar necessidades dos usuários.
LIÇÕES
• Suporte ao multidrop.
• FetchMail pode administrar uma lista de e-mails.
27

28. HISTÓRIA Suporte a multidrop
Suporte a MIME
– necessidade de Lições adicionais
outros usuários 8 Bits
14 15 16 17 18 19
15 - Faça de tudo para não alterar o fluxo de dados –
e nunca jogue fora informação.
• Ser cuidadoso quanto a estrutura de dados.
LIÇÕES
– O código estava pronto para 8 bits.
28

29. HISTÓRIA Suporte a multidrop
Suporte a MIME
– necessidade de
8 Bits
Lições adicionais
outros usuários
14 15 16 17 18 19
16 - Quando sua linguagem não está perto de um
Turing completo, “açúcar sintático” pode ser seu
amigo.
• É mais importante para uma linguagem ser
LIÇÕES
conveniente para humanos do que ser barata para o
computador.
29

30. HISTÓRIA Suporte a multidrop
Suporte a MIME
– necessidade de
8 Bits
Lições adicionais
outros usuários
14 15 16 17 18 19
17 - Um sistema de segurança é tão seguro quanto
seus segredos. Esteja atento a pseudo-segredos.
• Evite segurança por obscuridade.
LIÇÕES
30

31. HISTÓRIA Suporte a multidrop
Suporte a MIME
– necessidade de
8 Bits
Lições adicionais
outros usuários
14 15 16 17 18 19
18 - Para resolver um problema interessante, comece
achando um problema que é interessante para você.
• Necessidades pessoais do autor podem ser
LIÇÕES
necessidades de muitas pessoas.
• Reafirmação da lição 1.
31

32. HISTÓRIA Suporte a multidrop
Suporte a MIME
– necessidade de
8 Bits
Lições adicionais
outros usuários
14 15 16 17 18 19
19 - Desde que o coordenador de desenvolvimento
tenha um meio pelo menos tão bom quanto a
Internet e saiba liderar sem coerção, muitas cabeças
são inevitavelmente melhores que uma.
LIÇÕES
• Lei de Brooks.
• Programação “sem ego”.
• Importância da Internet como meio de comunicação.
• Liderança.
32

33. Críticas
• Nikolai Bezroukov (1998):
– Lei de Brooks não se aplica ao desenvolvimento
distribuído.
– “Havendo olhos suficientes, todos os erros são
óbvios” (Lei de Linus).
– Linux: Bazar ou Catedral?
• Bazar não tão democrático.
• Núcleo utilizou o modelo catedral?
– O modelo de código aberto automaticamente leva
aos melhores resultados?
33

34. Críticas
• Jonathan Eunice (1998):
– Crítica a taxonomia de Raymond.
• Como comparar uma cidade com um prédio?
– Uso da comunidade não é exclusividade do bazar.
– Adotar modelos e padrões de sucesso de ambas
as comunidades.
34

35. Influência
• Netscape:
– 22 de janeiro de 1998.
– Netscape disponibilizou o código-fonte do Netscape
Communicator 4.0.
– Teste real em larga escala do modelo bazar.
• Wikipedia:
– Colaboração em larga escala.
– “opened my eyes to the possibility of mass collaboration”
(Jimmy Wales).
• Manifesto do movimento de código aberto.
35

36. Referências
• Eric S. Raymond, “The Cathedral and Bazaar”,1997.
http://www.catb.org/~esr/writings/cathedral-bazaar/
• Nikolai Bezroukov, “A Second Look to the Cathedral and the Bazaar”, 1999.
http://www.softpanorama.org/Articles/a_second_look_at_the_cathedral_
and_the_bazaar.shtml
• Jonathan Eunice, “Beyond the Cathedral, beyond the Bazaar”, 1998.
http://www.illuminata.com/public/content/cathedral/intro.htm
36

37. de Eric S. Raymond
André Luis Schwerz
André Luiz Satoshi Kawamoto
Rafael Liberato Roberto
{andreluis, kawamoto, liberato}@utfpr.edu.br
UTFPR Câmpus Campo Mourão
Doutorado em Ciência da Computação
DINTER IME/USP-UTFPR
Fevereiro / 2012
By André Luis Schwerz, André Luiz Kawamoto and Rafael Liberato
Roberto. Este trabalho foi licenciado com uma Licença Creative
Commons - Atribuição 3.0 Não Adaptada.