-
Notifications
You must be signed in to change notification settings - Fork 2
/
catb-ptbr.html
1593 lines (1280 loc) · 86.7 KB
/
catb-ptbr.html
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
913
914
915
916
917
918
919
920
921
922
923
924
925
926
927
928
929
930
931
932
933
934
935
936
937
938
939
940
941
942
943
944
945
946
947
948
949
950
951
952
953
954
955
956
957
958
959
960
961
962
963
964
965
966
967
968
969
970
971
972
973
974
975
976
977
978
979
980
981
982
983
984
985
986
987
988
989
990
991
992
993
994
995
996
997
998
999
1000
<!DOCTYPE html>
<html>
<head>
<meta charset="utf-8">
<title>A catedral e o Bazar</title>
</head>
<body>
<h1>A Catedral e o Bazar - Eric S. Raymond</h1> Autor: Fábio Rodrigues Ribeiro
<farribeiro at gmail.com> Data: 23/09/2017
<h1>Introdução</h1>
<p>Eu analiso um projeto bem-sucedido de código livre, o Fetchmail, que foi
executado como um teste deliberado de algumas teorias surpreendentes sobre a
tecnologia de programação sugerida pela história do <em>Linux</em>.</p>
<p>Discuto estas teorias nos termos de dois estilos fundamentais diferentes de
desenvolvimento, o modelo <em>catedral</em> da maior parte do mundo comercial
contra o modelo <em>bazar</em> do mundo do Linux. Mostro que estes modelos
derivam de suposições opostas sobre a natureza da tarefa de depurar o software.
</p>
<p>Faço então um argumento sustentado na experiência do Linux para a proposição
que <em>Dados bastante olhos, todos os erros são triviais</em>, sugiro analogias
produtivas com outros sistemas autocorrigíveis de agentes egoístas, e concluo
com alguma exploração das implicações desta introspecção para o futuro do
software.</p>
<p>Este artigo é uma tradução do clássico documento <em>A catedral e o
bazar</em>, que pode ser encontrado em sua forma original em: <a
href="http://catb.org/esr/writings/cathedral-bazaar/">
http://catb.org/esr/writings/cathedral-bazaar/</a></p>
<p>Traduzido para o português por Erik Kohler <ekohler at programmer.net>
em: <a
href="http://www.geocities.com/CollegePark/Union/3590/pt-cathedral-bazaar.html"
>http://www.geocities.com/CollegePark/Union/3590/pt-cathedral-bazaar.html</a>
</p>
<h1>A catedral e o bazar</h1>
<p><em>Linux</em> é subversivo. Quem pensaria mesmo há cinco anos que um sistema
operacional de classe mundial poderia surgir como que por mágica pelo tempo
livre de milhares de colaboradores espalhados por todo o planeta, conectado
somente pelos tênues cordões da Internet?</p>
<p>Certamente não eu. No tempo que o Linux apareceu em minha tela-radar no
início de 1993, eu já tinha me envolvido no desenvolvimento de Unix e de código
aberto por dez anos. Eu fui um dos primeiros contribuintes para o projeto GNU
nos meados de 1980. Eu tinha liberado bastante do software livre na rede,
desenvolvendo ou codesenvolvendo diversos programas (nethack, Emacs em modo VC e
GUD, xlife, e outros) que estão ainda em largo uso hoje. Eu pensei que eu sabia
como isso era feito.</p>
<p>Linux ultrapassou muito o que eu pensei que sabia. Eu estava pregando o modo
Unix de uso de pequenas ferramentas, de prototipagem rápida e de programação
evolucionária por anos. Mas eu acreditei também que havia alguma complexidade
crítica, acima da qual uma aproximação mais centralizada, mais a priori era
requerida. Eu acreditava que os softwares mais importantes (sistemas
operacionais e ferramentas realmente grandes como Emacs) necessitavam ser
construídos como as catedrais, habilmente criados com cuidado por mágicos ou
pequenos grupos de magos trabalhando em esplêndido isolamento, com nenhum beta
para ser liberado antes de seu tempo.</p>
<p>O estilo de Linus Torvalds de desenvolvimento – libere cedo e frequentemente,
delegue tudo que você possa, esteja aberto ao ponto da promiscuidade – veio como
uma surpresa. Nenhuma catedral calma e respeitosa aqui – ao invés, a comunidade
Linux pareceu assemelhar-se a um grande e barulhento bazar de diferentes agendas
e aproximações (adequadamente simbolizada pelos repositórios do Linux, que
aceitaria submissões de qualquer pessoa) de onde um sistema coerente e estável
poderia aparentemente emergir somente por uma sucessão de milagres. O fato de
que este estilo bazar pareceu funcionar, e funcionar bem, veio como um distinto
choque. Conforme eu aprendia ao meu redor, trabalhei duramente não apenas em
projetos individuais, mas também tentando compreender porque o mundo do Linux
não somente não se dividiu em confusão mas parecia aumentar a sua força a uma
velocidade quase inacreditável para os construtores de catedrais.</p>
<p>Em meados de 1996 eu pensei que eu estava começando a compreender. O acaso
deu-me uma maneira perfeita para testar minha teoria, na forma de um projeto de
código aberto que eu poderia conscientemente tentar executar no estilo bazar.
Assim eu fiz – e foi um sucesso significativo.</p>
<p>No resto deste artigo eu contarei a história desse projeto, e eu irei usá-la
para propor alguns aforismos sobre o desenvolvimento eficaz de código aberto.
Nem tudo eu aprendi primeiramente no mundo do Linux, mas nós veremos como o
mundo do Linux lhe dá um ponto particular. Se eu estiver correto, eles o
ajudarão a compreender exatamente o que é que faz a comunidade do Linux ser uma
fonte de software bom – e ajuda a você a se tornar mais produtivo.</p>
<h1>O correio deve ser entregue</h1>
<p>Desde 1993 eu venho cuidando da parte técnica de um pequeno Provedor de
Acesso Internet de acesso gratuito chamado Chester County InterLink (CCIL) em
West Chester, Pensilvânia (eu fui cofundador do CCIL e escrevi nosso software
multiusuário de BBS – você pode observá-lo executando um telnet para
locke.ccil.org. Hoje suporta quase três mil usuários em trinta linhas.) O
trabalho permitiu-me o acesso 24 horas por dia à rede através da linha de 56K do
CCIL – de fato, praticamente exigiu!</p>
<p>Conseqüentemente, eu fiquei acostumado a acesso instantâneo ao correio
Internet. Por razões complicadas, era difícil fazer o SLIP funcionar entre minha
máquina de casa (snark.thyrsus.com) e o CCIL. Quando eu finalmente consegui, eu
achei incômodo ter que executar telnet periodicamente para o locke para
verificar meu correio. O que eu queria era que ele fosse enviado para o snark de
modo que eu fosse notificado quando uma mensagem chegasse e pudesse manuseá-lo
usando todas as minhas ferramentas locais.</p>
<p>O simples reenvio do sendmail não funcionaria, porque minha máquina local não
está sempre na rede e não tem um IP estático. O que eu precisava era um programa
que pegasse meu correio através da conexão SLIP e o entregasse localmente. Eu
sabia que tais programas existiam, e que a maioria deles usava um protocolo de
aplicação simples chamado POP (Post Office Protocol). E, realmente, já havia um
servidor POP3 incluído com sistema operacional BSD/OS do locke.</p>
<p>Eu precisava de um cliente POP3. Então eu procurei na Internet e encontrei
um. Na verdade, eu encontrei três ou quatro. Eu usei o pop-perl por algum tempo,
mas faltava o que parecia uma característica óbvia, a habilidade de alterar os
endereços no correio recebido para que as respostas fossem enviadas
corretamente.</p>
<p>O problema era este: suponha que alguém chamado 'joe' no locke tenha me
enviado uma mensagem. Se eu capturasse o correio para o snark e tentasse então
lhe responder, meu programa de correio tentaria alegremente enviá-lo a um `joe'
inexistente no snark. Editar manualmente os endereços de resposta para adicionar
'@ccil.org' rapidamente tornou-se um tormento.</p>
<p>Isto era claramente algo que o computador teria que fazer para mim. Mas
nenhum dos clientes POP existentes sabiam como! E isto nos traz à primeira
lição:</p>
<aside>
<strong><em>1. Todo bom trabalho de software começa colocando o dedo na ferida
de um programador.</em></strong>
</aside>
<p>Talvez isto deveria ter sido óbvio (um antigo provérbio diz que <q>A
necessidade é a mãe da invenção</q>) mas muitas vezes os programadores gastam
seus dias buscando retorno em programas que eles não necessitam nem gostam. Mas
não no mundo do <em>Linux</em> - o que pode explicar porque a qualidade média do
software originada na comunidade de <a
href="//www.vivaolinux.com.br/linux/">Linux</a> é tão alta.</p>
<p>Assim, eu me lancei imediatamente com o ímpeto de codificar um novo cliente
POP3 para competir com os existentes? De maneira alguma! Eu olhei com cuidado os
utilitários POP que eu tinha à disposição, perguntando-me <em>qual deles é o
mais próximo do que eu quero? Porque…</em></p>
<aside>
<strong><em>2. Os programadores bons sabem o que escrever. Os grandes sabem o
que reescrever (e reusar).</em></strong>
</aside>
<p>Embora eu não me considere um grande programador, eu tento me passar por um.
Uma importante característica dos grandes é a preguiça construtiva. Eles sabem
que você ganha um 'A' não por esforço, mas por resultados, e é quase sempre mais
fácil partir de uma boa solução parcial do que do nada.</p>
<p>Linus Torvalds, por exemplo, não tentou realmente escrever Linux do nada. Ao
contrário, ele começou reusando código e ideias do Minix, um pequeno sistema
operacional Unix-like para máquinas 386. Eventualmente todo o código Minix se
foi ou foi completamente reescrito – mas quando estava lá, forneceu as bases
para o infante que se transformaria no Linux.</p>
<p>Com o mesmo pensamento, eu fui procurar um utilitário POP que fosse
razoavelmente bem codificado, para usar como uma base de desenvolvimento.</p>
<p>A tradição do mundo Unix de compartilhar o código fonte foi sempre amigável
para a reutilização de código (esta é a razão porque o projeto de GNU escolheu o
Unix como sistema operacional base, apesar das sérias reservas sobre o mesmo). O
mundo Linux tem levado esta tradição quase a seu limite tecnológico; tem
terabytes de códigos abertos amplamente disponíveis. Assim gastando tempo
procurando algum software quase-bom-o-bastante feito por alguém é mais provável
dar a você mais bons resultados no mundo Linux do que em qualquer outro
lugar.</p>
<p>E fez para mim. Com aqueles que eu achei antes, minha segunda busca compôs um
total de nove candidatos – fetchpop, PopTart, get-mail, gwpop, pimp, pop-perl,
popc, popmail e upop. O primeiro que eu trabalhei primeiramente era o 'fetchpop'
por Seung-Hong Oh. Eu pus o meu código de reescrita de cabeçalho nele, e fiz
várias outras melhorias que o autor aceitou em sua versão 1.9.</p>
<p>Algumas semanas mais tarde, entretanto, eu tropecei pelo código do
'popclient' desenvolvido por Carl Harris, e descobri que eu tinha um problema.
Embora o fetchpop tenha tido algumas idéias boas e originais (tal como o modo
daemon), podia somente trabalhar com POP3 e foi codificado de uma maneira um
tanto amadora (Seung-Hong era um programador brilhante porém inexperiente, e
ambas as características ficaram evidentes). O código de Carl era melhor,
bastante profissional e sólido, mas em seu programa faltou diversas
características importantes e complicadas de serem implementadas do fetchpop
(incluindo aquelas que eu implementei).</p>
<p>Ficar ou trocar? Se eu trocasse, eu jogaria fora o código que eu já havia
feito em troca de uma base melhor do desenvolvimento.</p>
<p>Um motivo prático para trocar era a presença de suporte para vários
protocolos. POP3 é o protocolo mais comumente utilizado de todos os protocolos
de correio dos servidores, mas não o único. Fetchpop e os outros concorrentes
não faziam POP2, RPOP ou APOP, e eu estava realmente tendo alguns pensamentos de
talvez adicionar IMAP (Internet Message Access Protocol ou Protocolo de Acesso a
Mensagem da Internet, o mais recente e poderoso protocolo de correio
desenvolvido) só para me divertir.</p>
<p>Mas eu tinha uma razão mais teórica para pensar que trocar seria uma boa
idéia, alguma coisa que eu aprendi muito antes do Linux.</p>
<aside>
<strong><em>3. <q>Planeje jogar algo fora; você irá, de qualquer maneira</q>.
(<cite>Fred Brooks, "The Mythical Man-Month", Capítulo 11</cite>)</em></strong>
</aside>
<p>Ou, colocando de outra forma, você frequentemente não entende realmente o
problema até depois da primeira vez que você implementa uma solução. Na segunda
vez, talvez você saiba o suficiente para fazer corretamente. Então se você quer
fazer algo certo, esteja preparado para começar tudo novamente pelo menos uma
vez.</p>
<p>Bem (eu disse para mim mesmo) as mudanças no fetchpop foram a minha primeira
tentativa. Então eu troquei.</p>
<p>Depois que eu mandei meu primeiro conjunto de alterações para Carl Harris em
25 de junho de 1996, eu percebi que na verdade ele perdera o interesse pelo
popclient há algum tempo até então. O código era um pouco empoeirado, com
pequenos erros. Eu tinha muitas mudanças para fazer, e nós rapidamente
concordamos que o lógico para eu fazer era tomar conta do programa.</p>
<p>Sem perceber, o projeto havia se intensificado. Eu não estava mais
contemplando somente pequenos consertos para um cliente POP existente. Eu estava
mantendo um cliente completo, e havia ideias borbulhando na minha cabeça que eu
sabia iriam provavelmente levar a importantes mudanças.</p>
<p>Em uma cultura de software que encoraja a troca de código, isto é um caminho
natural para um projeto evoluir. Eu estava representando isto:</p>
<aside>
<strong><em>4. Se você tem a atitude certa, problemas interessantes irão
encontrá-lo.</em></strong>
</aside>
<p>Mas a atitude do Carl Harris foi ainda mais importante. Ele entendeu que</p>
<aside>
<strong><em>5. Quando você perde interesse em um programa, sua última obrigação
a fazer com ele é entregá-lo a um sucessor competente.</em></strong>
</aside>
<p>Sem ao menos ter que discutir isso, Carl e eu sabíamos que nós tínhamos um
objetivo em comum de ter a melhor solução disponível. A única questão para nós
foi se eu poderia me estabelecer como um par de mãos seguras para isso. Uma vez
que eu tenha feito isso, ele agiu com cortesia e rapidez. Eu espero que eu aja
assim quando chegar a minha vez.</p>
<h1>A importância de ter usuários</h1>
<p>E então eu herdei o popclient. Tão importante quanto, eu herdei os usuários
do popclient. Usuários são ótimas coisas para se ter, e não somente porque eles
demonstram que você está satisfazendo uma necessidade, que você fez algo certo.
Cultivados de maneira adequada, eles podem se tornar codesenvolvedores.</p>
<p>Outra força da tradição do Unix, uma que o <em>Linux</em> tem levado a um
alegre extremo, é que muitos usuários são hackers também. E porque o código
fonte está disponível, eles podem ser hackers eficazes. Isto pode ser
tremendamente útil para reduzir o tempo de depuração. Com um pouco de estímulo,
seus usuários diagnosticarão problemas, sugerir correções e ajudar a melhorar o
código muito mais rapidamente do que você poderia fazer sem ajuda.</p>
<aside>
<strong><em>6. Tratar seus usuários como codesenvolvedores é seu caminho mais
fácil para uma melhora do código e depuração eficaz.</em></strong>
</aside>
<p>O poder deste efeito é fácil de se subestimar. De fato, todos nós do mundo do
código aberto subestimamos drasticamente como isto incrementaria o número de
usuários e diminuir a complexidade do sistema, até que Linus Torvalds nos
mostrou de outra forma.</p>
<p>De fato, eu penso que a engenhosidade do Linus e a maior parte do que
desenvolveu não foram a construção do kernel do Linux em si, mas sim a sua
invenção do modelo de desenvolvimento do Linux. Quando eu expressei esta opinião
na sua presença uma vez, ele sorriu e calmamente repetiu algo que frequentemente
diz: <q>Sou basicamente uma pessoa muito preguiçosa que gosta de ganhar crédito
por coisas que outras pessoas realmente fazem.</q> Preguiçoso como uma raposa.
Ou, como Robert Heinlein teria dito, muito preguiçoso para falhar.</p>
<p>Em retrospecto, um precedente para o sucesso e métodos do Linux pode ser
observado no desenvolvimento da biblioteca do GNU Emacs Lisp e os repositórios
de código Lisp. Em contraste com o estilo de desenvolvimento catedral do núcleo
do Emacs C e a maioria das outras ferramentas da FSF, a evolução do grupo de
código Lisp foi fluída e bastante dirigida ao usuário. Ideias e protótipos foram
frequentemente reescritos três ou quatro vezes antes de atingirem uma forma
estável final. E colaborações permitidas pela Internet, a la Linux, foram
freqüentes.</p>
<p>Realmente, minha mais bem-sucedida codificação anterior ao fetchmail foi
provavelmente o modo Emacs VC, uma colaboração do tipo do Linux por email com
três outras pessoas, somente uma das quais (Richard Stallman, o autor do EMACS e
fundador da FSF) eu conheci pessoalmente até hoje. Foi um front-end para SCCS,
RCS e posteriormente CVS pelo Emacs que oferecia operações de controle de versão
<em>um toque</em>. Evoluiu de um pequeno e grosseiro modo sccs.el que alguém
havia escrito. E o desenvolvimento do VC foi bem-sucedido porque, ao contrário
do próprio Emacs, o código do Emacs Lisp poderia ir por gerações de
lançamento/teste/aperfeiçoamento muito rapidamente.</p>
<h1>Libere cedo, libere frequentemente</h1>
<p>Liberações novas e frequentes são uma parte crítica do modelo de
desenvolvimento do <em>Linux</em>. A maioria dos desenvolvedores (incluindo eu)
costumava acreditar que esta era uma má política para projetos maiores que os
triviais, porque versões novas são quase por definição, cheias de erros e você
não quer acabar com a paciência dos seus usuários.</p>
<p>Esta crença reforçou o compromisso de todos com o estilo de desenvolvimento
catedral. Se o principal objetivo era o de usuários verem menos erros quanto
possível, por que então você iria somente lançar um em cada seis meses (ou
frequentemente menos), e trabalhar como um cachorro depurando entre as
liberações. O núcleo do Emacs C foi desenvolvido desta forma. A biblioteca Lisp,
de fato, não foi – porque havia repositórios Lisp ativos fora do controle da
FSF, aonde você poderia ir para achar versões novas e em desenvolvimento,
independentemente do ciclo de liberação do Emacs.</p>
<p>A mais importante destas, o repositório elisp do Estado de Ohio, antecipou o
espírito e muitas das características dos atuais grandes repositório de Linux.
Mas pouco de nós realmente pensou muito sobre o que estávamos fazendo, ou sobre
o que a existência deste repositório sugeriu sobre problemas no modelo de
desenvolvimento catedral da FSF. Eu fiz uma séria tentativa por volta de 1992
para ter bastante código de Ohio formalmente fundido na biblioteca oficial do
Emacs Lisp. Encontrei problemas políticos e fui muito malsucedido.</p>
<p>Mas um ano depois, visto que o Linux se tornou amplamente conhecido, ficou
claro que alguma coisa diferente e muito saudável estava acontecendo. A política
de desenvolvimento aberta do Linus era exatamente o oposto do modelo de
desenvolvimento catedral. Os repositórios sunsite e tsx-11 estavam germinando,
múltiplas distribuições estavam surgindo. E tudo isto foi guiado por uma
frequência desconhecida de liberações de núcleo de sistemas.</p>
<p>Linus estava tratando seus usuários como codesenvolvedores na maneira mais
eficaz possível:</p>
<aside>
<strong><em>7. Libere cedo. Libere frequentemente. E ouça seus
fregueses.</em></strong>
</aside>
<p>Isso não era muito a inovação do Linus (algo como isso estava sendo a
tradição do mundo Unix por um longo tempo), mas em elevar isto até um grau de
intensidade que alcançava a complexidade do que ele estava desenvolvendo. Nestes
primórdios tempos (por volta de 1991) não era estranho para ele liberar um novo
kernel mais de uma vez por dia! E, porque ele cultivava sua base de
codesenvolvedores e incitava fortemente a Internet por colaboração como nenhum
outro, isto funcionou.</p>
<p>Mas como isto funcionou? E era isto algo que eu poderia duplicar, ou era algo
que dependia da genialidade única de Linus Torvalds?</p>
<p>Eu não pensei assim. Reconhecidamente, Linus é um excelente hacker (quantos
de nós poderia planejar um kernel completo de um sistema operacional de
qualidade de produção?). Mas o Linux não representou nenhum salto conceitual
impressionante a frente. Linus não é (ou pelo menos, ainda não) um gênio
inovativo de projeto do estilo que, por exemplo, Richard Stallman ou James
Gosling (do NeWS e Java) são. Ao contrário, para mim Linus parece ser um gênio
da engenharia, com um sexto sentido em evitar erros e desenvolvimentos que levem
a um beco sem saída e uma verdadeira habilidade para achar o caminho do menor
esforço do ponto A ao ponto B. De fato, todo o projeto do Linux exala esta
qualidade e espelha a abordagem conservadora e simplificada de planejamento do
Linus.</p>
<p>Então, se liberações rápidas e influenciar a Internet a todo custo não foram
acidentes mas partes integrantes da perspicácia do gênio de engenharia do Linus
para o caminho do menor esforço, o que ele estava enfatizando? O que ele estava
maquinando?</p>
<p>Posto desta forma, a questão responde a si mesma. Linus estava mantendo seus
usuários/hackers constantemente estimulados e recompensados – estimulados pela
perspectiva de ter um pouco de ação satisfatória do ego, recompensados pela
visão do constante (até mesmo diário) melhoramento do seu trabalho.</p>
<p>Linus estava diretamente direcionado a maximizar o número de pessoas-hora
dedicadas a depuração e ao desenvolvimento, mesmo com o possível custo da
instabilidade no código e extinção da base de usuários se qualquer erro sério
provasse ser intratável. Linus estava se comportando como se acreditasse em algo
como isto:</p>
<aside>
<strong><em>8. Dada uma base grande o suficiente de betatesters e
codesenvolvedores, praticamente todo problema será caracterizado rapidamente e a
solução será óbvia para alguém.</em></strong>
</aside>
<p>Ou, menos formalmente, <q>Dados olhos suficientes, todos os erros são
triviais.</q> Eu chamo isso de: <em>Lei de Linus</em>.</p>
<p>Minha formulação original foi que todo problema <em>será transparente para
alguém</em>. Linus objetou que a pessoa que entende e conserta o problema não é
necessariamente ou mesmo frequentemente a pessoa que primeiro o caracterizou.
<em>Alguém acha o problema</em>, ele diz, <q>e uma outra pessoa o entende. E eu
deixo registrado que achar isto é o grande desafio.</q> Mas o ponto é que ambas
as coisas tendem a acontecer rapidamente.</p>
<p>Aqui, eu penso, é o centro da diferença fundamental entre os estilos bazar e
catedral. Na visão catedral de programação, erros e problemas de desenvolvimento
são difíceis, insidiosos, um fenômeno profundo. Leva meses de exame minucioso
por poucas pessoas dedicadas para desenvolver confiança de que você se livrou de
todos eles. Por conseguinte os longos intervalos de liberação, e o inevitável
desapontamento quando as liberações por tanto tempos esperados não são
perfeitas.</p>
<p>Na visão bazar, por outro lado, você assume que erros são geralmente um
fenômeno trivial – ou, pelo menos, eles se tornam triviais muito rapidamente
quando expostos para centenas de ávidos codesenvolvedores triturando cada nova
liberação. Consequentemente você libera frequentemente para ter mais correções,
e como um benéfico efeito colateral você tem menos a perder se um erro ocasional
aparece.</p>
<p>E é isto. É o suficiente. Se a <em>Lei de Linus</em> é falsa, então qualquer
sistema tão complexo como o kernel do Linux, sendo programado por tantas mãos
quantas programam o kernel do Linux, deveria a um certo ponto tido um colapso
sob o peso de interações imprevisíveis e erros <em>profundos</em> não
descobertos. Se isto é verdade, por outro lado, é suficiente para explicar a
relativa falta de erros do Linux.</p>
<p>E talvez isso não deveria ser uma surpresa, mesmo assim. Anos atrás,
sociologistas descobriram que a opinião média de uma massa de observadores
especialistas (ou igualmente ignorantes) é um indicador mais seguro que o de um
único observador escolhido aleatoriamente. Eles chamaram isso de o <em>efeito
Delphi</em>. Parece que o que o Linus tem mostrado é que isto se aplica até
mesmo para depurar um sistema operacional – que o efeito Delphi pode suavizar a
complexidade do desenvolvimento até mesmo em nível de complexidade do kernel de
um sistema operacional.</p>
<p>Eu sou grato a Jeff Dutky <[email protected]> por apontar que a lei de
Linus pode ser refeita como <em>Depurar é paralelizável</em>. Jeff observa que
embora depurar requer que depuradores se comuniquem com algum desenvolvedor
coordenador, não requer coordenação significante entre depuradores. Assim não
cai vítima para a mesma complexidade quadrática e custos de gerência que faz ser
problemático adicionar desenvolvedores.</p>
<p>Na prática, a perda teórica de eficiência devido a duplicação de trabalho por
depuradores quase nunca parece ser um problema no mundo do Linux. Um efeito da
<em>política libere cedo e frequentemente</em> é minimizar esta duplicação
propagando consertos rapidamente.</p>
<p>Brooks até mesmo fez uma observação improvisada relacionada à observação de
Jeff: <em>O custo total de manter um programa amplamente utilizado é tipicamente
40 por cento ou mais o custo de desenvolvê-lo. Surpreendentemente este custo é
muito afetado pelo número de usuários. Mais usuários acham mais erros.</em>
(minha ênfase).</p>
<p>Mais usuários acham mais erros porque adicionar mais usuários adiciona mais
maneiras diferentes de testar o programa. Este efeito é amplificado quando os
usuários são codesenvolvedores. Cada um aborda a tarefa de caracterização de
erro com um conjunto perceptivo ligeiramente diferente e ferramenta analítica,
um ângulo diferente do problema. O <em>efeito Delphi</em> parece funcionar
precisamente por causa desta variação. No contexto específico da depuração, a
variação também tende a reduzir o feito da duplicação.</p>
<p>Então adicionar mais betatesters pode não reduzir a complexidade de um erro
<em>profundo</em> corrente do ponto de vista do desenvolvedor, mas aumenta a
probabilidade que a ferramenta de alguém irá de encontro ao problema de uma
maneira tal que o problema será trivial para esta pessoa.</p>
<p>Linus cobre suas apostas. Caso haja erros sérios, as versões do kernel do
Linux são numeradas de forma que usuários em potencial podem fazer a escolha de
executar a última versão designada <em>estável</em> ou correr o risco de
encontrar erros para obter novas características. Esta técnica não é ainda
formalmente imitada pela maioria dos hackers usuários do Linux, mas talvez
devesse; o fato de que ambas as escolhas estejam disponíveis faz delas mais
atraentes.</p>
<h1>Quando uma rosa não é uma rosa?</h1>
<p>Tendo estudado o comportamento do Linus e formado uma teoria sobre como ele
foi bem-sucedido, eu fiz uma decisão consciente para testar esta teoria em meu
novo (reconhecidamente muito menos complexo e ambicioso) projeto.</p>
<p>Mas a primeira coisa que eu fiz foi reorganizar e simplificar bastante o
popclient. A implementação do Carl Harris era muito atrativa, mas exibia um tipo
de complexidade desnecessária comum a vários programadores em C. Ele tratou o
código como centro das atenções e as estruturas de dados como suporte para o
código. Como resultado, o código era muito bonito mas o projeto da estrutura de
dados era ad-hoc e um tanto feio (pelo menos pelos altos padrões deste velho
hacker de LISP).</p>
<p>Eu tinha outro propósito para reescrever além de aperfeiçoar o código e o
projeto da estrutura de dados, entretanto. Era evoluí-lo para algo que eu
entenderia completamente. Não é nada agradável ser responsável por consertar
erros em um programa que você não entende.</p>
<p>Mais ou menos durante o primeiro mês, então, eu estava simplesmente seguindo
as implicações do projeto básico do Carl. A primeira mudança séria que fiz foi
adicionar suporte ao IMAP. Eu fiz isso reorganizando as rotinas de protocolos em
um driver genérico e três tabelas de métodos (para POP2, POP3 e IMAP). Esta e as
mudanças anteriores ilustram o princípio geral que é bom para os programadores
manterem em mente, especialmente em linguagens como C que não implementam
naturalmente tipagem dinâmica:</p>
<aside>
<strong><em>9. Estrutura de dados inteligentes e código burro trabalham muito
melhor que ao contrário.</em></strong>
</aside>
<p>Brooks, Capítulo 11: <q>Mostre-me seu [código] e esconda suas [estruturas de
dados], e eu poderei continuar mistificado. Mostre-me suas [estruturas de
dados], e eu provavelmente não necessitarei do seu [código]; ele será óbvio.</q>
</p>
<p>De fato, ele disse <em>gráficos</em> e <em>tabelas</em>. Mas considerando
trinta anos de terminologias/mudanças culturais, é praticamente o mesmo
ponto.</p>
<p>Neste ponto (quase Setembro de 1996, mais ou menos seis semanas desde o
início) eu comecei a pensar que uma mudança de nome deveria ser adequada -
afinal de contas, não era mais somente um cliente POP. Mas eu hesitei, porque
ainda não havia ainda nada genuinamente novo ainda no projeto. Minha versão do
popclient ainda teria que desenvolver uma identidade própria.</p>
<p>Isto mudou, radicalmente, quando o fetchmail aprendeu como reenviar mensagens
recebidas para a porta SMTP. Eu irei a este ponto em um momento. Mas primeiro:
Eu disse acima que eu decidi usar este projeto para testar minha teoria sobre o
que Linus Torvalds fez corretamente. Como (você pode perguntar) eu fiz isto?
Desta forma:</p>
<ol>
<li>Eu liberei cedo e frequentemente (quase nunca menos que uma vez a
cada dez dias; durante períodos de desenvolvimento intenso, uma vez por
dia).</li>
<li>Eu aumentei minha lista de betatesters adicionando a ela todo mundo
que me contatava sobre o fetchmail.</li>
<li>Eu mandei extensos anúncios à lista de betatesters toda vez que eu
liberava, encorajando as pessoas a participar.</li>
<li>4. E eu ouvia meus betatesters, questionando-os sobre decisões de
desenvolvimento e incitando-os toda vez que eles mandavam consertos e
respostas. </li>
</ol>
<p>O retorno destas medidas simples foi imediato. Desde o início do projeto, eu
obtive relatórios sobre erros de uma qualidade que a maioria dos desenvolvedores
morreria para ter, muitas vezes com ótimos consertos incluídos. Eu obtive
críticas severas, obtive mensagens de fãs, obtive sugestões inteligentes de
características. O que leva a:</p>
<aside>
<strong><em>10. Se você tratar seus betatesters como seu recurso mais valioso,
eles responderão tornando-se seu mais valioso recurso.</em></strong>
</aside>
<p>Uma medida interessante do sucesso do fetchmail é o simples tamanho da lista
de betatesters, amigos do fetchmail. Ao escrever este texto ela possuía 249
membros e são adicionados dois ou três por semana.</p>
<p>De fato, conforme eu reviso ao final de Maio de 1997, a lista está começando
a perder membros depois do pico de aproximadamente 300 pessoas por uma razão
interessante. Muitas pessoas têm me pedido para excluí-las da lista porque o
fetchmail está trabalhando tão bem para elas que elas não precisam mais ver o
tráfego da lista! Talvez isto seja parte do ciclo de vida normal de um projeto
maduro do estilo bazar.</p>
<h1>Popclient transforma-se em Fetchmail</h1>
<p>O verdadeiro ponto de mudança no projeto foi quando Harry Hochheiser me
mandou o seu rascunho de código para reenviar mensagens para a porta SMTP da
máquina cliente. Eu percebi quase imediatamente que uma implementação segura
desta característica tornaria todos os outros modos de envio perto do obsoleto.
</p>
<p>Por muitas semanas eu fiquei customizando o fetchmail de maneira incremental
enquanto percebia como o projeto de interface estava aproveitável mas feio – não
estava elegante e com muitas pequenas opções por toda parte. As opções para
extrair mensagens coletadas para um arquivo de mensagens ou saída padrão
particularmente me aborreciam, mas eu não conseguia descobrir por que.</p>
<p>O que eu vi quando eu pensei sobre reenvio SMTP foi que o popclient estava
tentando fazer muitas coisas. Ele foi projetado para ser tanto um agente
transportador de correspondência (MTA) quanto um agente local de entrega (MDA).
Com reenvio SMTP, ele poderia retirar o MDA e ser somente um MTA, transferindo
as correspondências para outros programas para entrega local como o sendmail
faz.</p>
<p>Por que se envolver com toda a complexidade de configurar um agente de
entrega de correspondência ou configurar lock-e-append em um arquivo de correio
quando a porta 25 é quase garantida para estar lá em primeiro lugar em qualquer
plataforma com suporte para TCP/IP? Especialmente quando isso significa que o
correio coletado é garantido parecer como um correio SMTP iniciado pelo
remetente normalmente, o que, de qualquer maneira, é realmente o que queremos.</p>
<p>Há várias lições aqui. Primeira, esta ideia de reenvio por SMTP foi o
primeiro grande retorno que eu obtive por tentar conscientemente emular os
métodos do Linus. Um usuário me deu esta ideia brilhante – tudo que eu tive que
fazer foi entender as implicações.</p>
<aside>
<strong><em>11. A melhor coisa depois de ter boas ideias é reconhecer boas
ideias dos seus usuários. As vezes a última é melhor.</em></strong>
</aside>
<p>E o que é interessante, você irá rapidamente descobrir que se você está se
achando completamente desacreditado sobre o quanto você deve a outras pessoas, o
mundo inteiro irá tratá-lo como se você mesmo tivesse criado cada bit da
invenção e está somente sendo modesto sobre seu gênio inato. Nós todos podemos
ver o quanto isso funcionou para Linus!</p>
<p>(Quando eu mostrei este documento na conferência de Perl em Agosto de 1997,
Larry Wall estava na primeira fila. Quando eu li a última linha acima ele gritou
fervorosamente, em um estilo religioso nostálgico, <em>Diga, diga, irmão!</em>.
Toda a audiência riu, porque eles sabiam que isso também funcionou para o
criador do Perl.)</p>
<p>Após poucas semanas executando o projeto no mesmo espírito, eu comecei a
ganhar um louvor semelhante não apenas dos meus usuários mas de outras pessoas
que deixaram as palavras escaparem. Eu guardei algumas destas mensagens; irei
olhar para elas novamente algum dia se eu começar a questionar se a minha vida
valeu a pena :-).</p>
<p>Mas há duas lições mais fundamentais aqui, não políticas, que são gerais para
todos os tipos de projeto.</p>
<aside>
<strong><em>12. Frequentemente, as soluções mais impressionantes e inovadoras
surgem ao se perceber que o seu conceito do problema estava
errado.</em></strong>
</aside>
<p>Eu estava tentando resolver o problema errado ao desenvolver continuamente o
popclient como um MTA/MDA combinado com todos os tipos de modos de distribuição
local. O projeto do fetchmail precisava ser repensado do início como um puro
MTA, uma parte do caminho normal do correio da Internet que fala SMTP.</p>
<p>Quando você atinge uma parede ao desenvolver – quando você dificilmente se
encontra pensando em algo depois do próximo patch – é frequentemente tempo para
perguntar não se você tem a resposta certa, mas se você está perguntando a
pergunta correta. Talvez o problema precise ser reformulado.</p>
<p>Bem, eu reformulei meu problema. Claramente, a coisa certa a fazer era (1)
codificar o suporte para reenvio por SMTP no driver genérico, (2) tornar isto o
modo default, e (3) eventualmente desfazer todos os outros modos de envio,
especialmente as opções de enviar-para-arquivo e enviar-para-saída-padrão.</p>
<p>Eu hesitei sobre o passo 3 por algum tempo, temendo aborrecer os usuários de
longa data do popclient dependentes dos mecanismos alternativos de envio. Em
teoria, eles poderiam imediatamente passar a usar arquivos. forward ou seus
equivalentes não-sendmail para obter os mesmos efeitos. Na prática a transição
poderia ser confusa.</p>
<p>Mas quando eu a fiz, os benefícios provaram-se altos. As partes obscuras do
código do driver sumiram. A configuração ficou radicalmente mais simples – não
mais rastejar à volta atrás do MDA do sistema e da caixa de correio do usuário,
não mais preocupações sobre se o sistema operacional suportava locking de
arquivo.</p>
<p>Além disso, a única maneira de perder correio sumira. Se você especificava
envio para um arquivo e o disco estava cheio, seu correio estaria perdido. Isto
não pode acontecer com o reenvio por SMTP porque o receptor SMTP não retornará
OK a não ser que a mensagem possa ser enviada ou, pelo menos, reprogramada para
um envio mais tarde.</p>
<p>E também, a performance aumentou (embora você não perceberia isso somente com
uma execução). Outro benefício não insignificante foi que a página do manual
ficou muito mais simples.</p>
<p>Mais tarde, eu tive que recolocar envio por um MDA local especificado pelo
usuário para permitir o tratamento de algumas situações obscuras envolvendo SLIP
dinâmico. Mas eu encontrei uma maneira muito mais simples de fazer isto.</p>
<p>A moral? Não hesite em jogar fora características obsoletas quando você puder
fazer isso sem perda de efetividade. Antoine de Saint-Exupéry (que foi um
aviador e projetista de aviões quando ele não estava sendo o autor de livros
clássicos infantis) disse:</p>
<aside>
<strong><em>13. “A perfeição (em projetar) é alcançada não quando não há mais
nada a adicionar, mas quando não há nada para jogar fora.”</em></strong>
</aside>
<p>Quando o seu código está ficando tão bom quanto simples, é quando você sabe
que está correto. E no processo, o projeto do fetchmail adquiriu uma identidade
própria, diferente do ancestral popclient.</p>
<p>Era tempo para a mudança de nome. O novo projeto parecia muito mais como um
irmão do sendmail do que o velho popclient parecia; ambos eram MTAs, mas aonde o
sendmail passa e então envia, o novo popclient coleta e então envia. Então, após
2 meses, eu mudei o nome para fetchmail.</p>
<h1>Fetchmail cresce</h1>
<p> Lá estava eu com um projeto elegante e inovador, um código que eu sabia que
funcionava bem porque eu usava todos os dias, e uma crescente lista de
betatesters. E gradualmente eu percebia que eu não estava mais ocupado com uma
trivial codificação pessoal que porventura poderia se tornar útil para algumas
pessoas. Eu tinha em minhas mãos um programa que todos os usuários de um sistema
Unix com uma conexão de correio SLIP/PPP realmente precisavam.</p>
<p>Com a característica de reenvio por SMTP, ele passou muito à frente da
competição para potencialmente se tornar um <em>category killer</em>, um destes
programas clássicos que preenchem seu nicho tão completamente que as
alternativas não são somente descartadas como também esquecidas.</p>
<p>Eu penso que você não pode realmente almejar ou planejar um resultado como
este. Você tem que ser atraído para isso por ideias de projeto tão poderosas que
posteriormente os resultados parecem inevitáveis, naturais, mesmos predestinados.
A única maneira de tentar ideias como esta é tendo muitas ideias – ou tendo o
julgamento de engenharia para levar as boas ideias das outras pessoas além do
que estas que as tiveram pensariam que elas poderiam ir.</p>
<p>Andrew Tanenbaum teve a ideia original de construir um Unix nativo simples
para o 386, para uso como uma ferramenta de ensino. Linus Torvalds levou o
conceito do Minix para além do que Andrew provavelmente pensou que poderia ir -
e cresceu para algo maravilhoso. Da mesma forma (embora em uma menor escala), eu
peguei algumas idéias de Carl Harris e Harry Hochheiser e dei um empurrão.
Nenhum de nós foi ‘original’ no sentido romântico que as pessoas pensam é um
gênio. Mas a maioria do desenvolvimento de software científico e de engenharia
não é feita por um gênio original, a mitologia hacker ao contrário.</p>
<p>Os resultados foram todos sempre muito precipitados – de fato, o tipo de
sucesso que qualquer hacker está sempre procurando! E eles significaram que eu
teria que definir meus padrões ainda mais altos. Para fazer o fetchmail tão bom
como eu então achava que poderia se tornar, eu teria que escrever não somente
para minhas próprias necessidades, mas também incluir e suportar características
necessárias para outros fora do meu relacionamento. E fazer isto mantendo o
programa simples e robusto.</p>
<p>A primeira e mais importante esmagadora característica que eu escrevi depois
de perceber isto foi o suporte a multidrop -- a habilidade de capturar correio de
caixas de correio que acumularam todas as mensagens para um grupo de usuários, e
então destinar cada pedaço de correio para seus destinatários individuais.</p>
<p>Eu decidi adicionar o suporte ao multidrop em parte porque alguns usuários
estavam pedindo por isto, mas principalmente porque eu pensei que isto iria
retirar os erros do código para o envio simples me forçando a manipular o
endereçamento de um modo geral. E assim se provou ser. Fazer funcionar a análise
da RFC 822 me tomou um tempo consideravelmente longo, não porque qualquer pedaço
dele é difícil mas porque envolvia uma pilha de detalhes interdependentes e
elaborados.</p>
<p>Mas o endereçamento multidrop se tornou uma decisão de projeto excelente.
Aqui está como eu soube:</p>
<aside>
<strong><em>14. Qualquer ferramenta deve ser útil da maneira esperada, mas uma
ferramenta verdadeiramente <em>boa</em> leva ela própria a usos que você nunca
esperou.</em></strong>
</aside>
<p>O uso inesperado para o multidrop do fetchmail é executar mailing lists com a
lista mantida, e expansão de apelidos feita, no lado do cliente da conexão
SLIP/PPP. Isto significa que alguém executando uma máquina pessoal por uma conta
ISP pode administrar uma mailing list sem acesso contínuo aos arquivos de
apelidos do ISP.</p>
<p>Outra importante mudança solicitada pelos meus betatesters foi suporte para
operação MIME 8-bit. Isto foi muito fácil de fazer, porque eu estava sendo
cuidadoso mantendo o código pronto para 8-bit. Não porque eu antecipei a demanda
para esta característica, mas em obediência a outra regra:</p>
<aside>
<strong><em>15. Quando escrevendo um software gateway de qualquer tipo, faça
tudo para perturbar o conjunto de dados o menos possível – e <em>nunca</em>
jogue fora informação a não ser que o destinatário force você a
isto!</em></strong>
</aside>
<p>Se eu não tivesse obedecido esta regra, o suporte a MIME 8-bit teria sido
difícil e cheio de erros. Como estava, tudo o que tive que fazer foi ler a RFC
1652 e adicionar um pouco de lógica trivial para a geração de cabeçalho.</p>
<p>Alguns usuários europeus insistiram para que eu adicionasse uma opção para
limitar o número de mensagens recebidas por seção (de maneira que eles poderiam
controlar custos das suas caras redes de telefone). Eu resisti por um longo
tempo, e ainda não estou inteiramente alegre sobre isto. Mas se você está
escrevendo para o mundo, você tem que ouvir os seus clientes – isto não muda
somente porque eles não estão pagando dinheiro a você.</p>
<h1>Algumas lições a mais do Fetchmail</h1>
<p> Antes de voltarmos ao assunto de engenharia de software em geral, existem
algumas lições a mais da experiência do fetchmail para ponderar.</p>
<p>A sintaxe do arquivo rc inclui palavras-chaves <em>ruidosas</em> opcionais
que são inteiramente ignoradas pelo analisador. A sintaxe parecida com o Inglês
que elas permitem é consideravelmente mais inteligível que os concisos pares
tradicionais palavra-chave-valor que você obtém quando as retira.</p>
<p>Estas começaram como um experimento posterior quando eu percebi como as
declarações do arquivo rc estava começando a lembrar uma minilinguagem
imperativa. (É por isto também que eu mudei a palavra-chave original 'server' do
popclient para 'poll').</p>
<p>Parecia para mim que tentar fazer esta minilinguagem imperativa parecer mais
como o Inglês poderia torná-la mais fácil de ser usada. Agora, embora eu seja um
convencido adepto da escola de projeto <em>faça isso uma linguagem</em> como
exemplificado pelo Emacs e HTML e muitos sistemas de banco de dados, eu
normalmente não sou um grande fã das sintaxes <em>English-like</em>.</p>
<p>Programadores tradicionais tendem a serem a favor de sintaxes de controle que
são muito precisas e compactas e não contém redundância alguma. Isto é um legado
cultural de quando os recursos computacionais eram caros, então os estágios de
análise tinham que ser tão baratos e simples quanto possíveis. O Inglês, com
redundância de aproximadamente 50%, parecia ser um modelo muito impróprio.</p>
<p>Esta não é minha razão para normalmente evitar sintaxes no estilo do Inglês;
eu menciono isto aqui somente para arrasá-la. Com ciclos e núcleos baratos,
concisão não deve ser ela mesma um fim. Hoje em dia é mais importante para uma
linguagem ser conveniente para humanos do que ser barata para o computador.</p>
<p>Há, entretanto, boas razões para ser cauteloso. Uma é o custo da complexidade
do estágio de análise – você não quer aumentá-lo ao ponto onde é uma fonte
significativa de erros e confusão de usuários. Outra é que tentar fazer a
sintaxe de uma linguagem English-like frequentemente demanda que o
<em>Inglês</em> que é falado seja seriamente propenso a ser fora de forma, tanto
como a semelhança superficial com a linguagem natural é tão confusa como a
sintaxe tradicional seria. (Você vê isso em várias linguagens chamadas de
<em>quarta geração</em> e em linguagens de consulta de banco de dados
comerciais.)</p>
<p>A sintaxe de controle do fetchmail parece evitar estes problemas porque o
domínio da linguagem é extremamente restrito. Não é perto de uma linguagem de
uso geral; as coisas que ela diz simplesmente não são muito complicadas, então
há pouco potencial para confusão em mover mentalmente entre um pequeno conjunto
do Inglês e a real linguagem de controle. Eu acho que há uma lição mais
abrangente aqui:</p>
<aside>
<strong><em>16. Quando sua linguagem não está perto de um Turing completo,
açúcar sintático pode ser seu amigo.</em></strong>
</aside>
<p>Outra lição é sobre segurança por obscuridade. Alguns usuários do fetchmail
me pediram para mudar o software para guardar as senhas encriptadas no arquivo
rc, de maneira que bisbilhoteiros não poderiam casualmente vê-las.</p>
<p>Eu não fiz isso, porque isto não adiciona realmente proteção. Qualquer pessoa
que adquira permissões para ler seu arquivo rc poderá executar o fetchmail como
você de qualquer maneira – e se é a sua senha o que eles procuram, poderiam
retirar o decodificador do próprio fetchmail para consegui-la.</p>
<p>Tudo o que a encriptação de senha do arquivo fetchmailrc faria seria dar a
falsa impressão de segurança para pessoas que não pensaram bem sobre este
assunto. Aqui a regra geral é:</p>
<aside>
<strong><em>17. Um sistema de segurança é tão seguro quanto é secreto. Esteja
atento a pseudos-segredos.</em></strong>
</aside>
<h1>Pré-condições necessárias para o estilo bazar</h1>
<p>Os primeiros leitores e audiências para este documento seguidamente
levantaram questões sobre as pré-condições para o desenvolvimento bem-sucedido
do estilo bazar, incluindo as qualificações do líder do projeto e o estado do
código ao tempo em que se torna público e começa a tentar construir uma
comunidade de codesenvolvedores.</p>
<p>Está claro que ninguém pode codificar desde o início no estilo bazar. Alguém
pode testar, achar erros e aperfeiçoar no estilo bazar, mas seria muito difícil
originar um projeto no estilo bazar. Linus não tentou isto. Eu também não. A sua
comunidade nascente de desenvolvedores precisa ter algo executável e passível de
testes para utilizar.</p>
<p>Quando você começa a construção de uma comunidade, o que você precisa ter
capacidade de apresentar é uma promessa plausível. Seu programa não precisa
funcionar particularmente bem. Ele pode ser grosseiro, cheio de erros,
incompleto, e pobremente documentado. O que não pode deixar de fazer é convencer
codesenvolvedores em potencial de que ele pode evoluir para algo realmente
elegante em um futuro próximo.</p>
<p>Tanto o <em>Linux</em> quanto o fetchmail se tornaram públicos com projetos
básicos fortes e atraentes. Muitas pessoas pensando sobre o modelo bazar como eu
tenho apresentado têm corretamente considerado isto como crítico, então
concluíram a partir disso que um alto grau de intuição e inteligência no líder
do projeto é indispensável.</p>
<p>Mas Linus obteve seu plano do Unix. Eu obtive o meu inicialmente do ancestral
do popclient (embora iria posteriormente mudar bastante, muito mais
proporcionalmente falando do que mudou o Linux). Então é necessário realmente
para o líder/coordenador de um empenho no estilo bazar ter um talento
excepcional para planejamento, ou ele pode conseguir o mesmo efeito coordenando
o talento de planejamento de outras pessoas?</p>
<p>Eu penso que não é crítico que o coordenador seja capaz de originar projetos
de excepcional brilho, mas é absolutamente crítico que o coordenador seja capaz
de reconhecer boas ideias de projetos de outras pessoas.</p>
<p>Tanto os projetos do Linux quanto o do fetchmail mostram evidências disso.
Linus, não sendo (como previamente discutido) um planejador espetacularmente
original, mostrou uma habilidade poderosa de reconhecer um bom projeto e
integrá-lo no kernel do Linux. E eu já descrevi como a ideia de projeto mais
poderosa do fetchmail (reenvio por SMTP) veio de outra pessoa.</p>
<p>Os primeiros leitores deste documento me elogiaram sugerindo que eu sou
propenso a subestimar a originalidade do planejamento de projetos no estilo
bazar porque eu tenho muito disso em mim mesmo, e portanto suponho isto. Pode
haver alguma verdade nisto; projetar (como oposto a codificar ou depurar) é
certamente minha mais forte habilidade.</p>
<p>Mas o problema em ser inteligente e original no planejamento de software é
que isto se torna um hábito – você começa reflexivamente a fazer coisas
atraentes e complicadas quando você deveria mantê-las robustas e simples. Eu
tive projetos que falharam porque eu cometi este erro, mas eu administrei para
que não acontecesse o mesmo com o fetchmail.</p>
<p>Então eu acredito que o projeto do fetchmail foi um sucesso em parte porque
eu impedi a minha tendência a ser engenhoso; isto vai contra (pelo menos) com o
fato de a originalidade em projetar ser essencial para projetos bem-sucedidos no
estilo bazar. E considere o Linux. Suponha que Linus Torvalds estivesse tentando
levar a cabo inovações fundamentais no projeto de sistemas operacionais durante
o desenvolvimento; pareceria que o kernel resultante seria tão estável e
bem-sucedido como é?</p>
<p>Um certo nível básico de habilidade de projetar e codificar é requerido,
claro, mas eu suponho que praticamente qualquer um que pense seriamente em
lançar um esforço no estilo bazar estará acima do mínimo necessário. O mercado
interno da comunidade de software aberto, por reputação, exerce uma sutil
pressão nas pessoas para que não lancem esforço de desenvolvimento que não sejam
competentes para manter. Até agora isto parece ter funcionado muito bem.</p>
<p>Há outro tipo de habilidade que não é normalmente associada com o
desenvolvimento de software que eu penso é tão importante quanto a engenhosidade
em planejar projetos no estilo bazar – e isto pode ser mais importante. Um
coordenador ou líder de um projeto no estilo bazar deve ter boa habilidade de
comunicação e relacionamento.</p>
<p>Isto deve parecer óbvio. Para construir uma comunidade de desenvolvimento,
você precisa atrair pessoas, fazer com que se interessem no que você está
fazendo, e mantê-las alegres sobre a quantidade de trabalho que estão fazendo. O
entusiasmo técnico constitui uma boa parte para atingir isto, mas está longe de
ser toda história. A personalidade que você projeta também importa.</p>
<p>Não é uma coincidência que Linus é um rapaz gentil que faz com que as pessoas
gostem dele e que o ajudem. Não é uma coincidência que eu seja um enérgico
extrovertido que gosta de trabalhar com pessoas e tenha um pouco de porte e
instinto de um cômico. Para fazer o modelo bazar funcionar, isto ajuda
enormemente se você tem, pelo menos, um pouco de habilidade para encantar as
pessoas.</p>
<h1>O contexto social do código aberto</h1>
<p>Está escrito: os melhores hacks começam como soluções pessoais para os
problemas diários do autor, e se espalham porque o problema se torna típico para
uma grande classe de usuários. Isto nos traz novamente para a regra 1,
recolocada talvez de uma maneira mais útil:</p>
<aside>
<strong><em>18. Para resolver um problema interessante, comece achando um
problema que é interessante para você.</em></strong>
</aside>
<p>Isso foi o que aconteceu com Carl Harris e o ancestral popclient, e também
comigo e o fetchmail. Mas isso foi entendido por um longo tempo. O ponto
interessante, o ponto que as histórias do <em>Linux</em> e do fetchmail parecem
demandar o nosso foco, é o próximo estágio – a evolução do software na presença
de uma comunidade grande e ativa de codesenvolvedores.</p>
<p>Em “The Mythical Man-Month”, Fred Brooks observou que o tempo de um
programador não é acumulativo; adicionar desenvolvedores em um projeto atrasado
de software faz com que ele se torne mais atrasado. Ele expôs que a complexidade
e custos de comunicação de um projeto crescem com o quadrado do número de
desenvolvedores, enquanto o trabalho feito cresce somente linearmente. Esta
afirmação é desde então conhecida como <em>A Lei de Brooks</em> e é largamente
considerada como correta. Mas se a Lei de Brooks fosse tudo a ser levado em
consideração, o Linux seria impossível.</p>
<p>O clássico <q>The Psychology Of Computer Programming</q>, de Gerald Weinberg,