Catedral, Bazar e Software Livre
Filipe Ferraz Salgado, Rodolpho Iemini Atoji
MAC339 – Informação, Comunicação e a Sociedade do
Conhecimento
Sumário
Sumário
1
1 Catedral x bazar
1.1 Definição e caracterı́sticas . . . . . . . . . . . . . . . . . . . .
1.2 Ser ou não ser bazar . . . . . . . . . . . . . . . . . . . . . . .
2
2
4
2 Um
2.1
2.2
2.3
2.4
2.5
2.6
projeto no modelo bazar
Ter um projeto inicial executável e testável . . . . . . .
Lı́deres com boa comunicação e relacionamento . . . .
Liberar versões rápido e freqüentemente . . . . . . . .
Entrada permitida de novos participantes: quanto mais,
Considerar usuários como co-desenvolvedores . . . . . .
Linus Torvalds: inteligente, porém preguiçoso . . . . .
3 Linux como sistema complexo
3.1 Sistema complexo adaptativo . .
3.2 Linux como sistema complexo . .
3.3 Quando a Lei de Brooks não vale
3.4 Auto-organização . . . . . . . . .
3.5 Memética e evolução . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. . . .
. . . .
. . . .
melhor
. . . .
. . . .
6
7
7
8
9
10
10
.
.
.
.
.
11
11
12
13
14
14
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
4 Conclusão
15
Referências
16
1
1 CATEDRAL X BAZAR
2
Introdução
O software livre vem ganhando popularidade nos últimos anos. Grande parte
dessa popularidade se deve à internet, que permite uma distribuição em larga
escala dos softwares produzidos segundo esse modelo.
No entanto, a internet não apenas permitiu a popularização do software
livre como também forneceu ferramentas que permitiram um imenso avanço
do mesmo. A rede permite que qualquer interessado conectado à rede possa
se tornar um contribuinte para um projeto.
Levando-se em conta as enormes proporções da rede, fica claro que um
modelo de desenvolvimento de software tradicional poderia se tornar inviável.
Esse modelo tradicional, hierárquico e centralizado é o que foi chamado de
catedral por Eric Raymond. Já o modelo de desenvolvimento adotado pelos
projetos de software livre o autor denomina de bazar, onde qualquer um é
bem-vindo a qualquer momento e o projeto não se desenvolve em torno de
uma coordenação central.
Como grande representante do software livre está o Linux, cujo desenvolvimento foi impulsionado especialmente pela popularização da internet.
Serão então abordados aspectos de desenvolvimento do mesmo, apoiandose nas teorias de The Cathedral And The Bazaar de Eric Raymond, sistemas
complexos descritos por Ko Kuwabara em Linux: A Bazaar at the Edge of
the Chaos e a peer-production descrita por Yochai Benkler em The Wealth
of Networks.
1
Catedral x bazar
Software livre, atualmente, é um assunto conhecido ou do qual todos pelo
menos já ouviram falar a respeito.
De acordo com um estudo [Des08] feito nos EUA, o número de projetos
com código aberto dobra a cada ano. Isso reflete o amplo conhecimento e
aceitação da sociedade sobre o assunto, mesmo entre aqueles que não são desenvolvedores, já que, caso esses não aceitassem, não haveria tanto incentivo
para o contı́nuo crescimento.
A seguir, serão apresentadas as diferenças entre os sistemas de produção
do software proprietário e o livre.
1.1
Definição e caracterı́sticas
Para explicar a diferença entre eles, temos que analisar a metodologia de
desenvolvimento de cada modelo.
1 CATEDRAL X BAZAR
3
No caso do software proprietário, temos o que Raymond chamou de modelo catedral [Ray98] e que Kuwabara [Kuw00] resume como sendo um
estilo “caracterizado por um planejamento central orientado de cima para
baixo e implementado por equipes especializadas seguindo um cronograma
estruturado” 1 . Ou seja, o modo clássico de desenvolvimento da maioria
das empresas atuais, com hierarquia e metas bem-definidas, onde os gerentes determinam o que os programadores irão fazer. Nesse método apenas as
pessoas designadas àquele projeto podem alterar o programa.
Já o método utilizado no desenvolvimento do software livre, ficou conhecido como bazar, que nada mais é do que a produção distribuı́da (peer
production) discutida por Benkler [Ben06], na qual a produção depende da
ação individual espontânea e descentralizada. Esse método proporciona aos
seus colaboradores uma maior liberdade, uma vez que participam do projeto
porque querem, e maior prazer, já que acabam fazendo aquilo que têm mais
interesse dentro do projeto. Dentro dessa metodologia o código-fonte dos
programas é aberto para que os vários participantes possam ter acesso a ele
a fim de alterá-lo e corrigi-lo.
A tabela 1 mostra algumas caracterı́sticas dos modelos explicitando suas
diferenças:
Catedral
Centralizado
Hierárquico
Número restrito de pessoas
Desenvolvimento top-down
Código fechado
Bazar
Descentralizado
Não-hierárquico
Quanto mais pessoas, melhor
Desenvolvimento bottom-up
Código aberto
Tabela 1: Diferenças entre catedral e bazar
Observamos as diferenças expostas na tabela 1, pode-se exemplificar alguns casos reais de softwares produzidos por meio dessas metodologias de
desenvolvimento.
No caso catedral um exemplo tı́pico, comumente citado, é o Microsoft
Windows. Sistema operacional produzido dentro dos rigores do modelo catedral, seguindo uma estrutura hierárquica rı́gida e centralizada. O código
é subdividido entre os programadores de modo que cada grupo fique responsável por uma parte do sistema.
Por outro lado, temos o Linux, cujo kernel é principal exemplo do modelo
bazar. Suas caracterı́sticas serão abordadas durante o texto.
1
“[...] characterized by centralized planning enforced from the top and implemented by
specialized project teams around structured schedules”
1 CATEDRAL X BAZAR
4
Fora do escopo de softwares, tem-se os exemplos da Wikipedia e da Enciclopédia Britannica, que representam os modelos bazar e catedral, respectivamente.
A Wikipedia foi fundada em 2001 e é uma enciclopédia livre construı́da a
partir da colaboração espontânea de diversas pessoas ao redor do mundo. A
credibilidade dessa enciclopédia virtual tem aumentado com tempo e hoje já
pode ser comparada à Enciclopédia Britannica, que é referência para muitos
quando se trata enciclopédia acadêmica.
Exemplo de desenvolvimento no estilo catedral, a Enciclopédia Britannica
teve sua primeira impressão em 1768, quando foi publicada em três fascı́culos,
um a cada ano. Em 1790 sua impressão foi pirateada nos EUA, o que acabou
sendo benéfico, já que hoje em dia a produção é feita lá, apesar de manter
o inglês britânico. Mesmo tendo milhares de contribuintes para os verbetes e artigos, a enciclopédia possui uma estrutura hierárquica de produção
internamente [EBb]. Além disso, a sua edição não é aberta à sociedade, fatos fazem com que ela se encaixe no modelo catedral. Atualmente, além da
versão impressa, também possui uma versão digital [EBa].
1.2
Ser ou não ser bazar
Freqüentemente dúvidas em relação ao método bazar são levantadas, como
por exemplo quando a metodologia deve ser aplicada ou se softwares produzidos dessa maneira descentralizada são confiáveis ou não.
Se forem analisadas as possı́veis vantagens do modelo de código aberto em
relação ao de código fechado, veremos que no primeiro não é necessário ter
o controle dos recursos utilizados durante o processo de produção. Cada indivı́duo possui o seu próprio recurso e é responsável por ele. Sendo assim, não
há ninguém responsável pela organização dos desenvolvedores a não serem
os próprios programadores, que colaboram espontaneamente. Isso leva a crer
que há uma espécie de automotivação, já que sem precisar do incentivo de
qualquer pessoa, centenas ou milhares de indivı́duos começam a contribuir.
E são justamente esses voluntários que garantem a correção dos erros dos
projetos, por isso que quanto mais pessoas, melhor. Isso mantém o caráter
descentralizado dos projetos abertos [Ray98].
Entretanto, Kuwabara ressalta que várias caracterı́sticas atribuı́das por
Raymond ao bazar, tais como “flexibilidade, desenvolvimento em paralelo,
revisão distribuı́da, ciclos de retorno” 2 , não necessitam que o código seja
aberto. Mais do que isso, algumas empresas do tipo catedral possuem tais
caracterı́sticas.
2
“ flexibility, parallel development, peer review, feedback loops”
1 CATEDRAL X BAZAR
5
Contudo, não há como negar o crescimento do desenvolvimento e da utilização dos softwares livres. Além do estudo mostrado inicialmente, sobre a
evolução do desenvolvimento, existem também dados que evidenciam a utilização desses programas. Benkler diz que “cerca de 70% dos softwares de
webservers, em particular os essenciais para comércio eletrônico, executam
no servidor livre Apache” 3 . Comenta ainda que empresas como IBM, HP e
agências militares estão adotando o software livre para construı́rem melhores equipamentos, venderem melhores serviços ou porque permite que eles
desempenhem melhor o papel deles.
David A. Wheeler, em seu artigo Why Open Source Software / Free Software (OSS/FS, FLOSS, or FOSS)? Look at the Numbers! [Whe08], apresenta uma série de dados e referências que confirmam a predominância, ou
pelo menos o crescimento, da comunidade livre. Entre eles está o gráfico 1
que confirma o que foi dito por Benkler sobre o Apache Web server.
Figura 1: Market Share for Active Web Servers, June 2000 - April 2007
O gráfico mostra os sites ativos, ou seja, aqueles que realmente desenvolveram um site e não que simplesmente compraram o domı́nio, mas não
utilizam. O estudo foi feito pela Netcraft em abril de 2007 e mostra que a
3
“[...] about 70 percent of Web server software, in particular for critical e-commerce
sites, runs on the Apache Web server-free software”
2 UM PROJETO NO MODELO BAZAR
6
Apache tinha 58.50% do mercado de servidores web enquanto que a Microsoft, que aparece em segundo lugar, tinha 34.44%.
2
Um projeto no modelo bazar
“Linus Torvalds’s style of development release early and often, delegate everything you can, be open to the point of promiscuity came as a surprise. No quiet, reverent cathedral-building
here rather, the Linux community seemed to resemble a great babbling bazaar of differing agendas and approaches (aptly symbolized
by the Linux archive sites, who’d take submissions from anyone)
out of which a coherent and stable system could seemingly emerge
only by a succession of miracles.”
Raymond, Eric – The Cathedral and the Bazaar [Ray98]
Benkler define o modelo como “baseado em contribuições voluntárias e
ubı́quas de compartilhamento recursivo, com melhorias incrementais de pessoas amplamente dispersadas para um projeto onde alguns contribuem bastante, enquanto outras o fazem pouco” 4 .
O autor completa ainda mostrando que o senso comum nos diz que tal
modelo dificilmente daria certo: “baseado em nossas suposições usuais em
relação a projetos voluntários e processos produtivos descentralizados que não
possuem coordenadores, este era pra ser um modelo que não teria sucesso.
Mas teve.” 5 .
Raymond enumera algumas caracterı́sticas do modelo bazar de desenvolvimento:
• Ter um projeto inicial executável e testável;
• Lı́deres com boa comunicação e relacionamento;
• Liberar versões rápido e freqüentemente;
• Entrada permitida de novos participantes: quanto mais melhor;
• Considerar usuários como co-desenvolvedores.
4
“based on voluntary contributions and ubiquitous, recursive sharing; on small incremental improvements to a project by widely dispersed people, some of whom contributed a
lot, others a little.”
5
“Based on our usual assumptions about volunteer projects and decentralized production
processes that have no managers, this was a model that could not succeed. But it did.”
2 UM PROJETO NO MODELO BAZAR
2.1
7
Ter um projeto inicial executável e testável
O ponto de partida da maioria dos projetos de software livre provêm de
necessidades pessoais dos programadores.
Apesar de projetos do modelo bazar não seguirem uma hierarquia rı́gida
e um planejamento bem-definido, Raymond afirma que antes de o projeto
efetivamente começar da maneira distribuı́da, é necessário ter um protótipo
do mesmo, minimamente usável.
Este paradigma de desenvolvimento em geral não se restringe ao inı́cio
do projeto, sendo aplicado ao longo do mesmo, sempre quando se deseja
adicionar um novo recurso, por exemplo.
Em se tratando software livre, o kernel do Linux aparece como um dos
exemplos que mais desafiou os engenheiros e estudiosos da computação devido
a sua complexidade, sua grandiosidade e seu método inovador de desenvolvimento.
Inicialmente, Linus Torvalds estava interessado apenas em uma propriedade do Unix, a task-switching. Ela permite que o sistema operacional
alterne entre tarefas simultâneas, caracterı́stica básica para sistemas multitarefa. Então, utilizando o Minix, um clone do Unix, ele começou a desenvolver as primeiras versões daquilo que seria o Linux. De tempos em tempos,
ele colocava na lista de discussão do Minix as alterações que havia realizado,
pedindo retorno das pessoas com sugestões daquilo que elas gostariam de ter
no sistema operacional. Mais do que isso, chamava as pessoas para ajudá-lo
a desenvolver o novo projeto [Kuw00].
Em pouco tempo surgiram interessados em contribuir e estender o novo
projeto, o que foi feito a partir dessa versão inicial, praticamente sem recursos. Atualmente há inclusive a colaboração de empresas como a Red Hat,
Novell, IBM e Intel.
2.2
Lı́deres com boa comunicação e relacionamento
Ter boa comunicação e relacionamento é o que Raymond chama de caracterı́stica óbvia em se tratando de liderança de projetos de software livre.
Esse tipo de caracterı́stica é o que atrai pessoas, desperta o interesse das
mesmas pelo que se está fazendo e por conseqüência as satisfaz.
Segundo Raymond, não é mera coincidência que Linus seja “um cara legal
que acabe conquistando as pessoas e fazendo-as querer ajudá-lo” 6 .
Linus não tinha real noção do projeto que iria desenvolver. Mesmo assim, acabou inventando um modelo de desenvolvimento que surpreendeu o
6
“It is not a coincidence that Linus is a nice guy who makes people like him and want
to help him”.
2 UM PROJETO NO MODELO BAZAR
Empresa
Red Hat
Novell
IBM
Intel
Linux Foundation
SGI
MIPS Technology
Oracle
Montavista
Linutronix
8
Contribuição
11,2%
8,9%
8,3%
4,1%
3,5%
2,0%
1,6%
1,3%
1,2%
1,0%
Tabela 2: Porcentagem de contribuições no kernel do Linux, feitas por empresas [GKH08]
mundo e que Raymond acredita ser ainda mais inteligente do que a própria
construção do Linux.
2.3
Liberar versões rápido e freqüentemente
Bugs em quaisquer projetos de software são algo recorrente.
Em projetos desenvolvidos pelo modelo catedral, é normal que ao ser
detectado um bug, haja um grande intervalo até a divulgação de uma nova
versão que corrija o mesmo. Este é um dos fatores causadores de frustração
entre os usuários, que se vêem obrigados a usar um programa defeituoso até
que uma nova versão seja lançada, e muitas vezes não correspondem às suas
expectativas.
No modelo bazar, novas versões tornam-se disponı́veis o quanto antes,
ficando suscetı́veis ao retorno imediato dos usuários em relação à correção
esperada ou mesmo em relação a novos problemas gerados pela correção
lançada.
O kernel do Linux chega a ter atualizações diárias, principalmente em
relação a falhas de segurança. Uma vez que se descobre uma vulnerabilidade
no kernel, a base do sistema operacional, a mesma é corrigida o quanto antes
e disponibilizada, evitando assim que toda a base de usuários seja afetada
pela falha.
2 UM PROJETO NO MODELO BAZAR
9
Versão do kernel Lançamento Dias de desenvolvimento
2.6.11
02/03/2005
69
2.6.12
15/07/2005
108
2.6.13
28/08/2005
73
2.6.14
27/10/2005
61
2.6.15
02/01/2006
68
2.6.16
19/03/2006
77
2.6.17
17/06/2006
91
2.6.18
19/09/2006
95
2.6.19
29/11/2006
72
2.6.20
04/02/2007
68
2.6.21
21/04/2007
81
2.6.22
08/07/2007
75
2.6.23
09/10/2007
94
2.6.24
24/01/2008
108
Tabela 3: Freqüência de liberação de versões do kernel 2.6 do Linux [GKH08]
2.4
Entrada permitida de novos participantes: quanto
mais, melhor
Em projetos do tipo catedral, cada participante costuma ser alocado a uma
função especı́fica, sendo responsável por um limitado número de tarefas.
O problema que afeta esse tipo de organização é enunciado pela Lei de
Brooks: “Incluir mais programadores a um projeto atrasado, torna-o mais
atrasado” 7 .
A razão para isso é que a comunicação entre os componentes do grupo
nesse tipo de organização acaba sendo do tipo onde todo mundo deve falar
com todo mundo. Já no caso de projetos do tipo bazar, é mais comum
que hajam pequenos grupos focados em determinadas tarefas, sendo que os
grupos entre si interagem muito pouco.
Isso permite que novos participantes sejam bem-vindos a todo momento,
uma vez que adicionar um participante a um determinado grupo não tem um
impacto significativo no andamento de todo o projeto.
O kernel do Linux é construı́do por meio de tarefas altamente especı́ficas.
Alguns grupos ficam responsáveis pelo sistema de arquivos, outros por gerenciamento de processos, rede e etc. Inicialmente o kernel era o que se chamava
“monolı́tico”, ou seja, composto de uma única peça. As versões mais recentes, no entanto, são “modularizadas”, o que significa que o kernel é composto
7
“Adding more programmers to a late project make it later”
2 UM PROJETO NO MODELO BAZAR
10
por diversas componentes de software.
Ao contrário do que se poderia supor, esta alteração não foi feita por
uma opção de engenharia de software, mas sim de modo a fazer com que o
trabalho em grupo fluı́sse ainda melhor. Com o kernel separado em módulos,
as contribuições individuais afetam ainda menos o funcionamento de todo o
kernel.
2.5
Considerar usuários como co-desenvolvedores
A participação dos usuários no processo de desenvolvimento de software no
modelo bazar é fundamental para garantir a qualidade do mesmo. Raymond
diz que “dados observadores o suficiente, todos os bugs são superficiais” 8 . É
o que o autor denomina de “Lei de Linus”.
Usuários são parte fundamental do processo de desenvolvimento na medida em que encontram bugs e os relatam. Não necessariamente são capazes
de os resolver, mas os relatando, alguém da equipe de desenvolvedores pode
ser capaz de os compreender e assim providenciar a resolução.
2.6
Linus Torvalds: inteligente, porém preguiçoso
Linus nunca quis escrever um kernel. Provavelmente nem mesmo inventar
uma nova maneira de se desenvolver software, mas segundo ele mesmo: “Sou
basicamente uma pessoa muito preguiçosa que gosta de ser creditado por
coisas que outras pessoas fazem” 9 [Ray98].
E foi assim que ele conseguiu estimular tantas pessoas a contribuı́rem
com seu projeto: liberou o código para que as elas pudessem usar, alterar
e distribuir a vontade. Dessa maneira, elas não se viam obrigadas a fazer
alguma coisa. Faziam por vários motivos, entre eles por vontade de ver
aquela funcionalidade na próxima versão.
Com isso, os erros eram corrigidos rapidamente, pois se Torvalds liberasse
uma versão com algum bug, alguém dentre as centenas de co-desenvolvedores
acharia aquela parte do kernel interessante e acabaria corrigindo. Ou seja,
utilizando a técnica de liberar cedo e sempre, ele aproveitava o interesse dos
outros para corrigir e melhor implementar algumas áreas.
Por meio de publicações sobre as alterações e novas versões nas listas
de discussões, ele consegue motivar novos colaboradores a participarem do
projeto. Essa participação cresceu a tal ponto que hoje em dia os patches
8
9
do”
“[...] given enough eyeballs, all bugs are shallow”
“I’m basically a very lazy person who likes to get credit for things other people actually
3 LINUX COMO SISTEMA COMPLEXO
11
Figura 2: Padrão de motivação para contribuir [Kuw00]
enviados pela comunidade são tantos que ele pode se dar ao luxo de escolher
qual a implementação que mais lhe agrada para colocar na próxima versão.
A figura 2 mostra o padrão de motivação para participação no desenvolvimento do kernel, segundo Kuwabara. Segundo o autor, “a eficiência
do grupo significa que o sucesso do projeto atrai novos desenvolvedores ao
projeto ao passo que membros antigos continuam a contribuir. Os novos
desenvolvedores contribuem por estarem interessados no sistema operacional
em si, mas também para afirmar os valores do compartilhamento e liberdade
intelectual, que são confirmados em cada desenvolvedor por sua reputação.
A comunidade então entra num ciclo de retorno positivo” 10 .
3
Linux como sistema complexo
Nesta seção serão abordadas as caracterı́sticas de desenvolvimento no sistema
bazar, sob o ponto de vista de sistemas complexos.
3.1
Sistema complexo adaptativo
Essa nova ciência procura revelar alguns aspectos dos sistemas complexos.
Tais sistemas nada mais são que diversos agentes interagindo entre si e fazendo com que o ambiente sofra mudanças. Dentro da complexidade, esse
processo que começa com interações locais e se expande para todo o sistema
é conhecido como bottom-up.
10
“Group efficacy means that the success of the project signals new hackers to join the
project and old members to continue contributing. The hackers contribute because they are
interested in the operating system for what it is, but they continue to contribute because
the Linux project also affirms the value of intellectual freedom and the norm of sharing,
which are reinforced in each individual by peer reputation. The community is gradually
locked into a recycling pattern of positive feedback”.
3 LINUX COMO SISTEMA COMPLEXO
12
O caráter adaptativo vem do fato de que, após ter sofrido modificações,
o ambiente acaba influenciando as próximas decisões de alguns agentes, que
se baseiam nas novas informações locais para realizarem suas novas ações, já
que não possuem informação global do sistema.
Duas caracterı́sticas principais desses sistemas são a capacidade de pequenas alterações locais interferirem no sistema como um todo e a possibilidade
de, através do processo bottom up descrito acima, se produzir algo novo que
nenhum dos agentes possui individualmente.
3.2
Linux como sistema complexo
No Linux podem-se observar ao menos dois nı́veis de interação local: nı́vel
de código-fonte do kernel e nı́vel de usuários ou usuário/desenvolvedores.
No nı́vel do kernel é onde melhor pode-se observar a caracterı́stica da
propagação de efeito das alterações locais. O kernel é a principal parte do
sistema operacional, e dele dependem todos os softwares sob os quais são
executados, seja direta ou indiretamente.
O código do kernel trata de procedimentos bastante especı́ficos, que variam desde aceitar entrada de dados pelo teclado, gerenciar o compartilhamento de tempo de uso do processador pelos programas e outras tarefas
especı́ficas de controle de hardware da máquina.
Uma alteração no kernel, portanto, tem um impacto global no sistema,
e costuma ser mais significativo se este impacto for negativo. Uma falha
de programação, por exemplo, pode impedir que o processo de compilação
do kernel não seja concluı́do. Esta falha pode ser causada pela inserção de
código de apenas uma pessoa. Em se tratando de um sistema cuja construção
é feita por milhares de contribuintes ao redor do mundo, pode-se perceber o
poder de propagação de uma alteração local.
Porém, este é um problema facilmente detectável e de fácil resolução. Os
piores problemas são aqueles ocultos, que só são revelados em uma execução
particular do software. Uma falha que fizesse o sistema de arquivos ser corrompido, por exemplo, atingiria não só os desenvolvedores do kernel como
qualquer usuário do sistema.
O outro nı́vel de interação local é o dos usuários. A comunidade de
usuários Linux é bastante superior, numericamente, ao número de desenvolvedores do sistema. Entre os usuários uma parte importante da interação
está no que se refere ao suporte do software. A comunidade Linux é conhecida pela grande troca de informações, em especial em fóruns e listas de
discussão na internet. Quando um usuário surge com um problema, há grandes chances de um usuário na comunidade conseguir solucionar, o que faz
com que isso deixe de ser um problema para toda a comunidade.
3 LINUX COMO SISTEMA COMPLEXO
13
Figura 3: Mudanças por hora no kernel do Linux [GKH08]
3.3
Quando a Lei de Brooks não vale
Na seção 2.4 foi citada a Lei de Brooks, segundo Raymond [Ray98], sendo
ela a razão pela qual muitos projetos regidos pelo sistema catedral acabam
tendo problemas no decorrer do desenvolvimento, especialmente quando o
sistema torna-se maior e mais complexo.
No caso do kernel do Linux, a interação entre o nı́vel de desenvolvimento
e o nı́vel de usuário ocorre numa magnitude menor, que é o que evita o
colapso do sistema, pois não há uma necessidade de comunicação entre todos
os envolvidos. Até mesmo no desenvolvimento interno do kernel, conforme
descrito na seção 2.4, não há essa necessidade, facilitado ainda mais pela
caracterı́stica de modularização do software.
A interação entre esses dois nı́veis costuma ocorrer na solução de problemas que realmente exigem intervenção na programação do kernel. Um
usuário ao perceber um problema o mesmo à comunidade. Um usuário mais
experiente, provavelmente com o perfil de desenvolvedor, saberá formular este
problema de uma forma mais técnica, de modo que a solução do problema
para os desenvolvedores do kernel torne-se mais evidente.
Desta maneira é que ocorrem as interações entre os nı́veis e usuário
e desenvolvimento, não ocorrendo necessária e diretamente entre qualquer
3 LINUX COMO SISTEMA COMPLEXO
14
usuário e todos os desenvolvedores. Muitas vezes, um usuário sequer tem
a consciência sobre a presença do kernel no sistema, ficando a detecção do
problema a cargo de alguma pessoa mais especializada da comunidade, o que
evidentemente minimiza a comunicação desnecessária estre esses dois nı́veis.
3.4
Auto-organização
Outro aspecto dos sistemas complexos é a auto-organização.
No sistema bazar de desenvolvimento, e no Linux não é diferente, os participantes escolhem aquilo com o que desejam contribuir, sem serem designados
para isso por uma coordenação central.
Esse tipo de caracterı́stica, segundo Kuwabara, é o que permite a alocação
eficiente de recursos: “no projeto Linux, cada desenvolvedor é livre para para
trabalhar em qualquer projeto de sua escolha de acordo com suas habilidades,
experiência e interesse” 11 .
3.5
Memética e evolução
Um meme consiste de uma idéia ou comportamento que pode passar de uma
pessoa a outra por meio de aprendizagem ou imitação. Richard Dawkins,
criador do termo em seu livro The Selfish Gene, utiliza a teoria evolucionista
para explicar a propagação de idéias e o fenômeno cultural. 12 .
O processo de desenvolvimento do kernel do Linux pode ser visto sob um
ponto de vista memético, segundo Kuwabara. Apesar de o kernel ter sido
escrito a partir do zero, muitas de suas idéias foram inspiradas em sistemas
Unix da época.
Outras caracterı́sticas que justificam esse ponto de vista seriam por exemplo as inúmeras contribuições na forma de patches (“remendos”) ao kernel. É
pressuposto que as submissões de patches devam ser corretas, livres de bugs
e que devem funcionar bem para o propósito o qual foram designados.
Outros patches, seguindo os que já foram submetidos procuram seguir
essas mesmas idéias, e também apoiam-se nos resultados de outros patches
fazendo-se assim a evolução no kernel do Linux. Segundo Kuwabara, o kernel
pode ser considerado um memeplex (complexo de memes).
11
“In comparison, in the Linux project, each developer is free to work on any particular
project of his choice as his skills, experience, and interest best dictate.”
12
http://en.wikipedia.org/wiki/Meme
4 CONCLUSÃO
4
15
Conclusão
A peer-production não chega a ser novidade, uma vez que ela sempre existiu,
porém em menor escala. Com as facilidades providas pela internet, este tipo
de produção foi amplamente impulsionado.
Se não fosse o avanço e a popularização das redes, muito provavelmente
projetos como o Linux não teriam passado de um projeto amador, desenvolvido a poucas mãos. É até improvável que o desenvolvimento do mesmo
tivesse tido a caracterı́stica do bazar, o que certamente não lhe traria o grau
de desenvolvimento que possui hoje.
A peer-production, impulsionada pelo poder das redes de comunicação,
portanto, cada vez mais deixa de ser vista como atividade amadora. Como
justificativa, tem-se a crescente aceitação desse tipo de produção, inclusive
mercadológica, que faz pleno uso dos resultados da mesma, bem como tem
feito também suas contribuições.
REFERÊNCIAS
16
Referências
[Ben06]
Yochai Benkler. The wealth of networks: How social production
transforms markets and freedom.
http://www.benkler.org/, 2006.
[Des08]
Amit Deshpande. Open source projects double every 14 months!
http://www.amit-deshpande.com/2008/04/
open-source-projects-double-every-14.html, April 2008.
[EBa]
Inc. Encyclopedia Britannica. Encyclopedia - britannica online
encyclopedia.
http://www.britannica.com/.
[EBb]
Inc. Encyclopedia Britannica. History of encyclopedia britannica
and britannica online.
http://corporate.britannica.com/company_info.html.
[GKH08] Amanda McPherson Greg Kroah-Hartman, Jonathan Corbet.
How fast it is going, who is doing it, what they are doing, and
who is sponsoring it.
http://www.linuxfoundation.org/publications/
linuxkerneldevelopment.php, April 2008.
[Kuw00] Ko Kuwabara. Linux: A bazaar at the edge of chaos.
http://www.firstmonday.org/issues/issue5_3/kuwabara/
index.html, 2000.
[Ray98]
Eric. S. Raymond. The cathedral and the bazaar.
http://www.catb.org/~esr/writings/cathedral-bazaar/,
August 1998.
[Whe08] David A. Wheeler. Why open source software / free software
(oss/fs, floss, or foss)? look at the numbers!
http://www.dwheeler.com/oss_fs_why.html, April 2008.