Aspectos do Trabalho Cooperativo no

Desenvolvimento de Software Livre

Marcelo Svio
IT Architect
http://www.linkedin.com/in/msavio
http://msavio.myplaxo.com/

Rio de Janeiro - Janeiro de 2007

Resumo. Software livre todo software cujo cdigo fonte est disponibilizado publicamente, e
seu contedo pode ser livremente modificado e redistribudo (e no sendo permitida a
apropriao desse cdigo). Uma conseqncia indireta desta liberdade o aparecimento de
comunidades de desenvolvimento que trabalham de forma descentralizada, atravs da Internet,

desenvolvendo e mantendo os diferentes projetos de software livre. Essas comunidades,

que a primeira vista parecem estar desorganizadas, produzem software de qualidade, com
alta produtividade e satisfao entre os seus desenvolvedores e usurios. O objetivo deste
artigo verificar os aspectos do Trabalho Cooperativo Suportado por Computador, CSCW
(Computer Supported Cooperative Work), que suportam o desenvolvimento
descentralizado de software livre, atravs do estudo de caso do desenvolvimento do sistema
operacional Linux.

1 Introduo
Apesar da definio apresentada acima, ainda existem controvrsias em relao ao que seja
precisamente considerado software livre. Isso se d pelo fato de que se trata de um assunto
multifacetado, que contm questes relacionadas a assuntos como engenharia de software,
propriedade intelectual, modelo econmico, poltica tecnolgica, cooperao1, liderana e
motivao. Uma olhada mais de perto em alguns projetos de software livre revela, ainda, uma
grande diversidade de objetivos, formas de participao e tcnicas de implementao.
Ao analisar as atividades que suportam o desenvolvimento de software livre, do ponto de
vista do trabalho cooperativo suportado por computador, possvel identificar um desafio
comum a todos os projetos: a necessidade da criao e manuteno de um ambiente
sociotcnico onde os participantes possam, de forma cooperativa, construir solues para os
problemas de interesse mtuo.
As prticas do desenvolvimento de software livre so importantes para a pesquisa em CSCW
por dois motivos principais. Primeiro porque o desenvolvimento de software tradicionalmente
um processo de coordenao intensiva que tem atrado pesquisadores de CSCW (KRAUT,
1995; BUTTON, 1996) e segundo porque o processo de desenvolvimento de software livre
efetuado por participantes geograficamente dispersos, com a ajuda de tecnologias colaborativas
como o email, conversao on-line, World Wide Web e sistemas de controle de verso e de
gerenciamento de configurao, tecnologias que, por sua vez, tm sido um aspecto central nas
pesquisas de CSCW.

O conceito de cooperao mais complexo que o de interao e de colaborao, pois alm de pressupor ambos
requer relaes de respeito mtuo e no hierrquicas entre os envolvidos, uma postura de tolerncia e convivncia
com as diferenas e um processo de negociao constante. Percebemos que a diferena fundamental entre os
conceitos de colaborao e cooperao reside no fato de que para haver colaborao o indivduo deve interagir com
o outro existindo ajuda - mtua ou unilateral. Para existir cooperao deve haver interao, colaborao, mas
tambm objetivos comuns, atividades e aes conjuntas e coordenadas. (MAADA; TIJIBOY, 1998).

1.1 Histrico Resumido do Software Livre (e do Linux)

Software Livre um conceito antigo, embora ainda no tivesse este nome especfico desde o
incio. At a dcada de 70, o valor de um computador estava contido essencialmente no
hardware, que tinha um custo muito alto. A maioria dos fabricantes fornecia, junto com o
hardware vendido, o cdigo fonte de seus sistemas operacionais e aplicativos. Embora as
licenas no explicitassem claramente a liberdade, a redistribuio do software era vista como
positiva, e quase todo o software era fornecido com o seu cdigo fonte (STALLMAN, 1999).
Os fabricantes at estimulavam, como forma de diminuir os custos de suporte, o
compartilhamento de informaes e melhorias de software produzidas entre seus usurios2.
Assim o software era, em geral, desenvolvido de forma cooperativa e aberta em diversas
universidades e empresas. O sistema operacional UNIX, nos seus anos iniciais, foi um exemplo
desta poca (MCKUSICK, 1999), assim como o desenvolvimento da Internet foi inteiramente
baseado no uso e compartilhamento de programas de cdigo fonte aberto em escala mundial.
No incio da dcada de 80 o cenrio mudou, quando ganhou fora o licenciamento restritivo,
que no permitia a redistribuio do software fornecido e este passou a significar basicamente o
mdulo executvel, suprimindo o acesso maioria dos cdigos-fonte. Esta mudana de cenrio
fez com que, em 1984, (STALLMAN, 1999) criasse a Free Software Foundation (FSF3). A
filosofia do software livre se baseia em uma definio de liberdade. Por causa da ambigidade
em ingls da palavra "free", tornou-se necessrio esclarecer que free software no se refere ao
preo, mas liberdade dos usurios de executar, copiar, distribuir, estudar, modificar e melhorar
o software. Mais precisamente, referem-se a quatro tipos de liberdades:
1. A liberdade de executar programas para qualquer propsito.
2. A liberdade de estudar como o programa funciona e adapt-lo s suas necessidades (o acesso ao
cdigo fonte essencial para isso).
3. A liberdade para redistribuir cpias do programa de modo que outros se beneficiem.
4. A liberdade de melhorar o programa e distribuir o seu aperfeioamento para o pblico, de modo que
toda a comunidade se beneficie (novamente o cdigo fonte necessrio).

O primeiro projeto da FSF foi o de promover o desenvolvimento de um novo sistema

operacional, completamente livre. Para garantir esta liberdade, criou em 1989 um novo modelo
de licenciamento de software, a General Public License (GPL), descrita no Anexo 1.
O novo sistema operacional que seria desenvolvido, e que teria o objetivo de ser compatvel
com UNIX, foi chamado de GNU4 (um acrnimo recursivo que significa GNU is Not UNIX). O
desafio no se restringia apenas criao do ncleo do sistema em si (chamado HURD e que
ainda no est pronto at hoje), mas tambm de uma coleo de aplicativos, ferramentas e
bibliotecas que permitissem sua plena utilizao, sem perder a compatibilidade com o UNIX
original.
A cultura em torno do movimento de software livre, de certa forma, est ligada cultura em
torno do UNIX, j que os principais representantes do movimento foram usurios desse sistema,
que tinha uma natureza aberta e uma filosofia prpria, sumarizada por Gancarz (1995) como
sendo composta dos seguintes pontos:
1.
2.
3.
4.
5.
6.
7.
8.
9.

Pequeno belo;
Faa cada programa perfazer bem apenas uma tarefa apenas;
Construa um prottipo assim que possvel;
Escolha portabilidade sobre eficincia;
Armazene dados numricos em arquivos texto;
Faa reuso do software para sua vantagem;
Use scripts shell para aumentar portabilidade e reuso;
Evite interfaces restritivas com o usurio;
Faa cada programa ser um filtro de dados para que possa ser usado em conjunto com outros.

2 Havia um grande compartilhamento de software entre os participantes dos grupos de usurios, como o SHARE
(para usurios de sistemas IBM) e o DECUS (para usurios de sistemas DEC).
3 http://www.fsf.org/
4 http://www.gnu.org/

Em 1991, Torvalds (1999) ento estudante da Universidade de Helsinki (Finlndia), iniciou o

desenvolvimento do Linux, um ncleo de sistema operacional compatvel com o UNIX, a partir
do reuso de cdigos e idias do Minix, um pequeno sistema operacional de uso acadmico
criado por Tanenbaum (1987). A partir da primeira verso, Torvalds convidou, via newsgroups
da Internet, outros desenvolvedores a contriburem nessa empreitada. Houve bastante adeso e,
de forma surpreendentemente rpida, a codificao e a manuteno constantes neste ncleo, o
fizeram evoluir para se tornar um software com funcionalidades similares s dos ncleos dos
sistemas UNIX do mercado (SCHENK, 2001). O Linux, ao longo do seu desenvolvimento,
utilizou (e ainda utiliza) muitas ferramentas do Projeto GNU da FSF e por esta razo o sistema
hoje tambm chamado de GNU/Linux.
O licenciamento atravs da GPL e a utilizao da Internet como o canal principal de
comunicao e desenvolvimento transformaram o Linux no mais importante exemplo de
software livre desenvolvido de forma aberta e descentralizada.
Raymond (1999) rotulou os modelos de desenvolvimento de software e chamou de Bazar
esse modelo descentralizado e cooperativo, em contraposio ao Catedral, modelo tradicional
no qual o desenvolvimento realizado de forma fechada e pouco cooperativa. Ele reforou esta
perspectiva atravs da afirmao de que o Linux um contra-exemplo da Lei de Brooks, uma
lei clssica da Engenharia de Software, que diz o seguinte:
...o tempo de um programador no acumulativo, pois ao adicionar desenvolvedores em um projeto
atrasado de software faz com que ele se torne mais atrasado ainda e que a complexidade e os custos
de comunicao de um projeto crescem com o quadrado do nmero de desenvolvedores, enquanto o
trabalho feito cresce somente linearmente (BROOKS, 1995).

Outra caracterstica do modelo Bazar, importante para a qualidade do objeto produzido, ter
uma grande base de usurios com acesso ao cdigo fonte, pois segundo Raymond (1999) Se
exposto a um nmero suficiente de olhos, todos os bugs so superficiais, pois a depurao de
erros uma atividade paralelizvel e ser resolvida mais rapidamente quanto maior for a base de
usurios participantes.
O tamanho e a agilidade de um projeto de software livre, no so as nicas qualidades que o
distinguem de um modelo Catedral. Outra importante diferena est em sua organizao
interna, particularmente na ausncia de uma coordenao global sob uma autoridade central e
pela inexistncia de um planejamento de projeto do tipo Top-Down. Alis, em software livre
normalmente a estratgia vem depois do desenvolvimento e a ao antes do planejamento
(TAURION, 2004).
A partir de 1988 o software livre se tornou notcia cada vez mais freqente na imprensa,
quando a Netscape abriu o cdigo do seu principal produto, o Communicator e tambm quando
empresas de grande porte como IBM e Oracle comearam dar suporte ao Linux e ao Apache.
Esse ano tambm ficou marcado como o ano que a Microsoft reconheceu, pela primeira vez, o
Linux como competidor importante (OSI, 1988).
Muitas vezes o termo software livre (free software) se confunde com software aberto (open
source). Isso passou a acontecer principalmente aps a criao da Open Source Initiative (OSI5),
em 1988. Diferentemente da FSF, que suporta somente o uso de suas prprias licenas, a OSI
no tem licenas prprias, mas certifica todas as dezenas licenas existentes no mercado
(inclusive as da FSF) dentro de seus prprios parmetros de software aberto. A OSI uma
entidade conciliadora, que garante s empresas que praticam o modelo comercial de
desenvolvimento de software, uma porta de entrada no movimento de software aberto sem
necessariamente adotar as licenas da FSF, representando assim uma espcie de alternativa
intermediria. Desta forma, todo software livre , por definio, aberto, porm nem todo
software aberto livre.

http://www.opensource.org/

1.2 Os Projetos de Software Livre

Embora no exista uma definio precisa do que seja um projeto de software livre, existe um
consenso informal de que o software em conjunto com seus desenvolvedores, usurios e
repositrios de cdigo e documentos constitui um projeto, que desta forma abrange:
Cdigo fonte, que o software propriamente dito, mas que existe em forma de inmeras
cpias entre todos seus usurios e repositrios de dados. Software livre, em geral, tem uma
verso bem definida e distribuda a partir de um ponto central conhecido para o Projeto.
Um grupo de desenvolvedores, que trabalha para codificar e corrigir o software. Os
desenvolvedores, em todos os casos e sem exceo, trabalham cooperativamente atravs da
Internet e podem ter status diferenciados dentro do projeto (FIELDING, 1999).
Os usurios do software. Apesar de todo software ter usurios, sua participao em
projetos de software livre essencial, pois discutem inovaes e apresentam erros
encontrados com freqncia, incentivando os desenvolvedores a trabalhar por um produto
melhor (RAYMOND, 1999).
Os repositrios de documentos e cdigos. Normalmente todo projeto tem algum site
central que uma referncia para desenvolvedores e usurios buscarem cdigos e
informaes atualizadas.
interessante perceber que todo o processo de desenvolvimento e distribuio depende
essencialmente do uso da Internet, e que esta um pr-requisito para a existncia de um projeto
de software livre.
Segundo o Sourceforge6, website do Open Source Technology Group (OSTG7), que o maior
repositrio de software livre e de cdigo aberto disponvel na Internet, existem em seus registros
mais de 130 mil projetos, em diferentes estgios de desenvolvimento, classificados da seguinte
forma:
Planejamento: Nenhum cdigo foi escrito ainda e o escopo do projeto ainda est sendo
definido, Logo que algum resultado tangvel em forma de cdigo aparea, o projeto entra
no prximo estgio;
Pr-Alfa: Cdigo muito preliminar produzido. No esperado, entretanto que este cdigo
seja capaz de compilar ou ser executado. Observadores externos ao projeto podero ter
dificuldade em entender o significado do cdigo. Assim que uma inteno coerente que
indique uma direo seja percebida no cdigo, o projeto passa para o estgio seguinte;
Alfa: O cdigo produzido funciona pelo menos de forma parcial e o projeto comea a
tomar forma e absorver novas caractersticas. medida que o nmero de sugestes e
modificaes comea a diminuir, o projeto entra no estgio seguinte;
Beta: O cdigo est, de uma forma geral, completo em relao s caractersticas propostas
no projeto original, mas requer testes de depurao. Quando o nmero de erros estiver
reduzido o suficiente para entrar em produo, o projeto passa para o estgio seguinte;
Estvel: O software utilizvel e confivel o suficiente. As mudanas sero aplicadas
cuidadosamente e com o objetivo de aumentar a estabilidade, nunca de adicionar
funcionalidades. Se nenhuma mudana significante acontecer em um perodo longo, o
projeto entra no ltimo estgio, mesmo se problemas menores ainda possam existir;

6
7

http://sourceforge.net/
http://www.ostg.com/

 Maduro: H muito pouco ou nenhum desenvolvimento no cdigo, uma vez que o software
preenche todos os seus objetivos corretamente. Mudanas sero aplicadas com extremo
cuidado. Pode permanecer nesta fase por vrios anos, at que se torne obsoleto ou
substitudo por outro melhor. Ainda assim o cdigo permanecer indefinidamente
disponvel para servir a objetivos educacionais;
Inativo: Projeto interrompido por falta de manuteno, movimentao de arquivos ou
abandono por parte de seus lderes (projeto rfo).

2 O Modelo de Desenvolvimento do Software Livre

Quando o desenvolvimento feito por uma equipe pequena e local, ou por uma comunidade
de prtica, onde os participantes esto fortemente ligados uns aos outros, o trabalho cooperativo
certamente mais fcil, pois, nessas comunidades de prtica, os membros podem aprender as
novidades de forma mais eficiente, resolver seus problemas de maneira mais tranqila, e ainda
tm mais possibilidades de encontrar novas oportunidades de inovao (BROWN, 1991). Em
contraste, a coordenao de uma equipe numerosa e remota precisa ser inevitavelmente formal e
o gerenciamento das contingncias sempre uma tarefa muito mais difcil de gerenciar
(KRAUT, 1995).
Os projetos de desenvolvimento distribudo de software livre apresentam caractersticas
comuns, quando analisados do ponto de vista de construo cooperativa. Segundo Scharff
(2002), essas caractersticas comuns podem ser mapeadas em um framework que as organiza de
forma descritiva em um modelo que enfatiza a construo cooperativa.
A figura abaixo representa graficamente este framework conceitual, ilustrando os quatro
componentes principais de um projeto de software livre: As pessoas (participantes), o que eles
esto criando (objeto produzido), os processos empregados (processos colaborativos) e os meios
usados para comunicao e coordenao do projeto (tecnologias colaborativas).

Fig. 1. Framework conceitual do desenvolvimento do software livre

2.1 Os Participantes
So os componentes principais de um projeto de software livre. Sem um grupo de
participantes ativos no haver software produzido ou este ser apenas um pedao de software
sem mudanas. A participao em um projeto de software livre abrange, alm da produo do
cdigo fonte em si, a contribuio em forma de idias, feedbacks, correes e demonstraes.
Assim, os participantes podem ser simpatizantes, usurios, desenvolvedores, testadores,
documentadores ou evangelistas. Geralmente so ativamente envolvidos em todas as fases de
um projeto e trabalham de forma voluntria, motivados por uma mentalidade altrusta
(RAYMOND, 1999).

Um estudo demogrfico realizado por Boston (2002) com uma populao de lderes e
desenvolvedores principais de projetos registrados no Sourceforge, revelou que entre os
entrevistados:

72,6% disseram que, quando esto programando, perdem a noo do tempo por estarem
motivados, sendo o tempo de sono considerado a principal contrapartida resultante da
participao em um projeto de software livre seguida de perto pela vida social;
44,9% so motivados a trabalhar no projeto pelo desafio intelectual que representa;
Apenas 11,1% revelaram como motivao principal desbancar o software proprietrio;
70% dos participantes so voluntrios e no so financeiramente recompensados (direta
ou indiretamente) pelo seu trabalho no projeto;
O tempo mdio de trabalho gasto nos projetos foi de 14,9 horas por semana;
48,1% revelou que o maior benefcio pessoal o aumento do conhecimento;.
83% se identificaram com a comunidade hacker;
70,2 % dos participantes esto entre 22 e 38 anos, com a mdia em torno de 30 anos;
A populao provm de dezenas de pases, e a maior parte vem EUA, Alemanha e
Reino Unido;
45,4 % dos participantes so programadores profissionais e a mdia de experincia de
11 anos;
A maioria afirmou esperar do lder do projeto no s a realizao de tarefas prticas
(criao da base de cdigo original e contribuies constantes), mas uma boa viso de
longo prazo, iniciativa para dilogo, e disposio para integrar contribuies.

2.2 O Objeto Produzido

o resultado da criao e dos refinamentos sucessivos. Ainda que a produo de cdigo
fonte seja atividade central de um projeto de software livre, este no o nico produto final,
pois tambm figuram neste componente toda a documentao, os relatrios de defeitos, as
ferramentas de instalao e outros materiais de suporte. A verso do software recomendada para
uso em produo chamada de distribuio padro.
2.3 Os Processos Colaborativos
So convenes, procedimentos, prticas, papis e responsabilidades que regem as interaes
entre os membros de um projeto de software livre. Geralmente so difceis de definir, pois so
conhecimentos tcitos, que a comunidade pode nem perceber que adota, ainda que certamente
estejam presentes e desempenhem um papel importante. Diferentes comunidades podem ter
diferentes perspectivas em relao construo cooperativa, seja enfatizando a correo de
erros, promovendo novas funcionalidades ou criando referncias de implantao.
Essas diferentes perspectivas afetam a natureza dos processos colaborativos (NAKAKOJI et
al., 2002), e normalmente aparecem quando so endereadas as questes dos participantes e as
respectivas respostas da comunidade. So situaes que invariavelmente remetem a novas
situaes de colaboraes, como por exemplo:
Quando uma comunidade intolerante com perguntas simples ou assume uma postura
defensiva perante uma sugesto, pode inibir os participantes;
Se algum participante quer contribuir com uma correo ou melhoria, a comunidade deve
ter processos para absorver e encaminhar estas questes;
necessrio que a comunidade esteja preparada para atender s mltiplas contribuies
em paralelo para vrios pedaos ou mdulo do software em questo;
Finalmente preciso ter um processo de adoo de mudanas na distribuio padro, pois
se nenhuma contribuio for incorporada, os participantes podem se sentir discriminados
no projeto.

Em um projeto de software livre, este ciclo de discusso, mudana e incorporao de

mudanas, por definio no termina nunca, pelo menos enquanto houver o projeto.
A tcnica mais adotada nos projetos de software livre a utilizao de alguma forma de
liderana. Normalmente um lder de projetos uma pessoa (ou um pequeno grupo de pessoas)
que participou da concepo da idia ou de sua implementao inicial e que, principalmente,
goza de respeito e reconhecimento por parte dos outros membros da comunidade. O papel
desempenhado por um lder em um projeto de software livre pode variar muito porque depende
fortemente da pessoa que exerce esta liderana, a comear pela prpria definio desta funo,
referenciada por diversos nomes como chefe, arquiteto-chefe, mantenedor,
coordenador, etc. Em linhas gerais o lder prov direo e coerncia para o projeto, resolve
eventuais disputas e mantm o controle da distribuio padro, diferenciando-se assim de um
ambiente corporativo tradicional, cuja liderana normalmente est inserida em um contexto
hierrquico de uma cadeia de comando.
Outra tcnica muito disseminada na organizao de processos colaborativos de software livre
diz respeito ao framework do projeto em si, que paraleliza a organizao da comunidade e a
arquitetura do software que est sendo desenvolvido. Entre as estruturas organizacionais tpicas
temos as decomposies funcionais hierrquicas em mdulos fracamente acoplados e um ncleo
central com mdulos encaixveis. Um importante objetivo do framework deste tipo a
capacidade que oferece de, dado um problema especfico, saber quais as mudanas que sero
necessrias e onde precisam ser feitas.
A diviso de tarefas, diferente do modelo tradicional, feita de forma democrtica e baseada
no interesse pessoal dos participantes, ainda que, quando muitas pessoas estejam trabalhando no
desenvolvimento de uma mesma parte do sistema, possa haver uma delegao de tarefas
visando evitar conflitos e que normalmente explicitada atravs de uma lista de participantes e
de subprojetos ativos, criando uma percepo informal de quem est trabalhando no qu.
importante frisar que cada participante contribui com o software livre por motivos pessoais e,
normalmente, poucos se dedicam a fazer tarefas consideradas chatas (como documentao ou
interfaces), ainda que sejam importantes.
Um conceito implcito do software livre que tem profundas implicaes no processo
colaborativo o compartilhamento de informaes. Qualquer um pode ter acesso, ler ou
modificar qualquer cdigo fonte no sistema. Este carter pblico do cdigo cria uma espcie de
presso social que motiva a produo de cdigo de qualidade, pois todos os participantes
querem que suas contribuies sejam reconhecidamente positivas para a comunidade (AOKI et
al., 2001).
Mudanas em um projeto de software livre acontecem o tempo todo e o desafio manter um
software de qualidade sem ofender os membros da comunidade, pois crticas ou mudanas em
um pedao de cdigo podem ser interpretadas como uma crtica pessoal. A submisso no s de
erros e crticas, mas de correes e sugestes importante para o desenvolvimento de uma
comunidade (PAVLICEK, 2000).
2.4 As Tecnologias Colaborativas
As tecnologias colaborativas desempenham duas atividades essenciais ao processo de
construo cooperativa. A primeira dar aos participantes um canal de comunicao entre si e a
segunda fornece mecanismos de armazenamento, distribuio e acompanhamento de verses de
objetos produzidos pela comunidade. Ambas as atividades podem se basear em ferramentas
sncronas ou assncronas e de forma independente da sofisticao tcnica e das questes
temporais, ou seja, podem ser realizadas por contato fsico face-a-face, videoconferncia, batepapo eletrnico, cartas postais, etc..

2.4.1 Comunicao
A maioria dos projetos de software livre virtual, com participantes espalhados ao redor do
mundo e, mesmo quando a maioria das pessoas de um projeto est em um nico pas, as
dificuldades de agendar reunies com presena fsica so considerveis, porm quando os
participantes se encontram fisicamente, estas reunies so to importantes quanto qualquer
outra tecnologia colaborativa (LANCASHIRE, 2001).
A Internet um elemento indispensvel na criao e desenvolvimento de projetos de software
livre. Como os projetos de software livre tiveram sua origem e disseminao em paralelo com
origem e disseminao da prpria Internet, as principais tecnologias colaborativas utilizadas
passam pelas ferramentas disponveis nessa rede. Sobre esse aspecto Yamauchi (2000) oferece
uma viso geral dos mecanismos de comunicao usados em projetos de software livre e afirma
que, apesar da tendncia acadmica da pesquisa em CSCW apontar para a produo de
ferramentas complexas para suportar trabalho cooperativo desta natureza, os projetos de
software livre sobrevivem e comprovam a eficcia do uso de ferramentas e meios de
comunicao simples e disponveis h muito tempo na Internet, como o email, as listas de
distribuio, os newsgroups, os chats e os sites repositrios de contedo.
Os canais de comunicao baseados na Internet so relativamente baratos (quando
comparadas s ligaes telefnicas internacionais, reunies com presena fsica e
videoconferncia por satlites) e aqueles com caractersticas assncronas so importantes para
minimizar o problema das fronteiras geogrficas e dos fusos horrios, especialmente na
coordenao de projetos de maior porte, que aliados capacidade de alcance mundial da
Internet faz com que os projetos de software livre atraiam muito mais participantes do que
conseguiriam se fossem grupos locais ou geograficamente limitados.

2.4.2 Armazenamento e controle de verses e erros

Os mecanismos de armazenamento, distribuio e acompanhamento de objetos produzidos
pela comunidade tambm utilizam ferramentas disponveis na Internet. A distribuio padro
normalmente disponibilizada em website conhecido, que funciona como repositrio daquela
verso (esttica) at que seja substituda por outra mais nova.
Cada vez mais projetos de software livre esto adotando ferramentas de controle de verso
para gerenciamento do contedo do objeto produzido. Essas ferramentas so vistas como uma
extenso natural do processo de desenvolvimento, permitindo que se possam realizar
modificaes paralelas de forma coerente e padronizada, atravs de um mecanismo
automatizado para identificar e controlar as modificaes realizadas nos arquivos de um projeto
ao longo do tempo, garantindo a integridade e a rastreabilidade das modificaes.
Para enviar as modificaes feitas em um objeto, um participante no precisa enviar todo o
conjunto de arquivos, pois as ferramentas especficas normalmente extraem a diferena do
conjunto original para o modificado e somente o delta precisa ser enviado. Um componente da
mesma ferramenta, do outro lado, se encarrega de aplicar as modificaes e gerar a nova verso.
Esse recurso importante na economia do uso da rede, pois os arquivos com as diferenas
normalmente so substancialmente menores do que as verses completas dos arquivos.
Existem diversas ferramentas em uso nos projetos de software livre, como BitKeeper8,
Subversion9 e Revision Control System (RCS10), porm a mais utilizada atualmente a
Concurrent Versions System (CVS11), um software (livre) relativamente simples, que foi

http://www.bitkeeper.com/
http://subversion.tigris.org/
10 http://www.cs.purdue.edu/homes/trinkle/RCS/
11 http://ximbiot.com/cvs/wiki/
9

desenvolvido suportar grupos de trabalho voltados para o desenvolvimento de projetos de

construo cooperativa, seja de cdigos fonte, documentao, arquivos de configurao, etc.
O CVS surgiu em 1986 como uma coleo de scripts para melhorar o RCS e depois se
transformou em uma ferramenta prpria, que funciona segundo o modelo copy-modify-merge
(copia-modifica-integra) que, baseado no trabalho off-line, permite que mltiplos participantes
efetuem, de forma independente, alteraes em suas cpias locais do objeto, uma vez que no
utiliza mecanismos de excluso mtua. A seguir esto apresentados os principais aspectos do
fluxo de trabalho do CVS, extrado de Reis (2001):

Fig. 2. Diagrama de fluxo de trabalho com o uso do CVS (REIS, 2001).

Repositrio: Consiste em um conjunto de arquivos mantido em um local central
(normalmente um servidor conectado Internet, que permita acesso annimo). Opera,
principalmente, segundo um modelo de incrementos, ou seja, armazena as cpias mais atuais
dos arquivos do projeto, e as diferenas entre esta e as verses anteriores.
Cpia Local: Qualquer participante interessado solicita ao servidor, atravs de uma
ferramenta front-end, uma cpia do objeto em uma determinada verso desejada. Uma vez
criada esta cpia local, tambm chamada de sandbox, o participante tem acesso total aos
arquivos que deseja trabalhar e pode aplicar suas modificaes. O participante pode sempre
solicitar ao servidor uma atualizao de sua base de objeto local, recebendo as alteraes que
foram integradas ao repositrio principal aps a criao da sua cpia local.
Integrao: Ao alterar o cdigo, o participante est livre de qualquer interao com o
repositrio e quando julgar que sua verso alterada est pronta para ser integrada base
principal, usa a ferramenta front-end para submeter o objeto de volta ao repositrio central. A
esta ao de integrao dado o nome de checkin ou merge.
Resoluo de conflitos: Se mltiplos participantes alteram o mesmo trecho de um objeto,
conceitualmente ocorre um conflito. O processo de resoluo de conflitos feito da seguinte
forma: O primeiro participante a integrar um objeto ignora, a princpio, o fato de que outros
estejam trabalhando no mesmo trecho. Cada participante subseqente que iniciar uma ao de
merge receber do repositrio a mensagem de que precisa atualizar a sua verso local (j que

uma integrao no mesmo arquivo foi feita pelo primeiro participante). Neste momento, ao
atualizar a cpia local a ferramenta ir informar que houve alteraes provindas do
repositrio no mesmo trecho de cdigo alterado localmente. Estes trechos do cdigo so
marcados com indicadores que diferenciam a verso do repositrio da verso local. O
participante precisa analisar com cuidado as alteraes e decidir de que forma o cdigo deve
ficar; ele pode resolver o conflito removendo uma das verses, mas freqentemente a opo
correta integrar mudanas de ambas as verses num novo trecho nico.
Verses: Cada arquivo modificado no repositrio recebe uma verso numrica. possvel
criar aliases (apelidos) que abstraiam as verses de um conjunto de arquivos em um
determinado instante do tempo. Com isso, possvel reverter alteraes de arquivos
individuais para verses anteriores, e tambm regenerar uma verso completa do repositrio
em um determinado momento. Do ponto de vista do participante, o CVS permite que se
comparem facilmente as alteraes feitas na sua cpia local com qualquer verso integrada
no repositrio, e torna possvel reverter alteraes integradas no repositrio central para
verses anteriores. Este ltimo recurso normalmente utilizado para remover alteraes
problemticas que tenham causado algum um defeito ou regresso funcional no objeto
produzido.
Branches: Alm das verses alternativas da base de objeto principal, o CVS permite que se
crie uma linha de verses paralelas principal. Resumidamente, estabelecido um branch
(bifurcao) a partir do cdigo principal, chamado trunk (tronco). Alteraes integradas sobre
este branch so isoladas, no refletindo no tronco. possvel criar um nmero arbitrrio de
branches e cada um deles ter um nome simblico, que o participante especifica ao usar a
ferramenta. Eventualmente alteraes de um branch podem ser aplicadas no trunk
principal. Esta operao tem o nome de merge (incorporao). prtica comum, entre os
projetos de software livre, manter branches estveis conforme apresentado a seguir:

Fig. 3 No exemplo acima, o branch estvel foi criado logo aps o lanamento da verso 0.9, e
mantido separado da verso principal (head), recebendo apenas reparos de bugs. Duas novas
verses estveis foram lanadas (1.0.1 e 1.0.2). O desenvolvimento e a adio de
funcionalidades continuam normalmente na verso principal. (REIS, 2001).

Branch Estvel: Onde tendem a ser integradas apenas correes de erros, ainda que esta
regra no seja explcita. Esta verso tratada de forma especial, e usurios tm
expectativas de que entre uma verso e outra do branch estvel no ocorram regresses.
Branch Instvel: Onde so aceitos tanto reparos de erros quanto adies de funcionalidade.
No h uma garantia de que as verses funcionem de forma confivel, especialmente nas
primeiras verses lanadas neste ciclo. Com o passar do tempo, declarada uma
moratria adio de funcionalidades (o chamado feature freeze), e a verso instvel
passa por um perodo de estabilizao. Ao final deste perodo, uma verso considerada
estvel o suficiente batizada de nova verso estvel, e um novo ciclo se inicia.

Alm de manter verses estveis, branches so utilizados para implementar mudanas que
tenham grande impacto sobre a base do objeto. Como visto anteriormente, cada participante
trabalha em relativo isolamento, com sua cpia local. Se no existissem branches, a integrao
de mudanas extensas seria bem difcil, j que por grandes perodos de tempo corre-se o risco
de outro participante ter alterado o mesmo trecho. Utilizando um branch, possvel desenvolver
a alterao paralelamente, e integrar mudanas no trunk principal de forma incremental.
As ferramentas que documentam e controlam os erros encontrados (e suas correes) so
muito importantes para qualidade e a produtividade dos projetos de desenvolvimento distribudo
de software. Cada erro, informado por um usurio participante, registrado em um informe
individual e cada informe possui um ciclo de vida que vai desde a sua criao, no momento em
que informado, at seu fechamento, quando o erro reparado no objeto produzido. Essas
ferramentas, que normalmente tm interface Web ou via email permitem, em geral, um bom
gerenciamento dos erros, com capacidade de localizao, confirmao e deteco de erros
duplicados ou que no se apliquem verso atual do objeto.
A ferramentas de controle de erros mais usada em projetos de software livre atualmente o
Bugzilla12, que nasceu como ferramenta de controle de alteraes do projeto do browser
Mozilla13, no qual usada em todas as etapas do processo de desenvolvimento, desde a
definio de funcionalidades at o projeto, implementao e reviso de alteraes. O Bugzilla
possui, alm do registro de informes de erros, funcionalidades de priorizao de atendimento,
assinalamento de erros aos participantes apropriados, configurao de dependncias entre os
erros, organizao de erros por produto ou componentes e, principalmente, a capacidade de
reviso de cdigo, na qual cada informe pode ser vinculado a uma alterao de cdigo
provisria, que deve ser revisada e aprovada para integrao na base de cdigo principal. Outra
ferramenta comumente utilizada o GNATS14.
2.5 As Inter-relaes
Nenhum dos componentes deste framework conceitual existe de forma isolada e assim como
cada aspecto muda com o tempo, o mesmo acontece com as relaes. A seguir esto listadas as
inter-relaes mais encontradas entre os componentes:
2.5.1 O Uso
O objeto produzido em um projeto de software livre um pedao de software de computador,
que as pessoas iro baixar e usar em um contexto especfico. O uso um tipo de atividade
reflexiva, na qual o usurio cria um modelo de percepo das limitaes e pontos fortes do
software em uso e identifica mudanas e caractersticas que acreditam que o software deveria
ter para atender suas necessidades e preferncias. Quando mais o software estiver relacionado
com cotidiano do usurio, principalmente relacionado ao seu trabalho, mais chances existem
desse usurio querer contribuir com crticas e sugestes para o desenvolvimento do software.
2.5.2 A Facilitao Social
O processo colaborativo emerge dos participantes ao mesmo tempo em que influencia suas
aes. A facilitao social a maneira com que os processos colaborativos encorajam as
pessoas a se envolverem no desenvolvimento e evoluo do projeto. Por exemplo, o processo
colaborativo pode requerer que as pessoas que corrijam erros anexem seus nomes s correes.
Em alguns grupos isso pode ser um grande incentivo correo de erros porque o
reconhecimento pessoal e os elogios motivam as pessoas a contribuir cada vez mais. Em outro
exemplo, se um lder que precisa aprovar todas as mudanas nunca aceita as sugestes da
12

http://www.bugzilla.org
http://www.mozilla.org
14 http://www.gnu.org/software/gnats/gnats.html
13

comunidade, seus participantes percebero que suas contribuies no esto recebendo o devido
reconhecimento e podero abandonar o projeto. Em suma, a facilitao social se refere s
reaes dos participantes ao contexto social do projeto.
2.5.3 A Facilitao Tcnica
O processo colaborativo est intimamente relacionado com as tecnologias colaborativas
empregadas. Algumas vezes as limitaes da tecnologia influenciam no processo colaborativo
em si. Por exemplo, as equipes que dependem da comunicao por email, muitas vezes tm
dificuldade de encontrar mensagens importantes devido ao volume e a inerente falta de estrutura
dos sistemas de correio eletrnico. Para compensar essa deficincia, o processo colaborativo
pode especificar que quando a palavra ANNOUNCE aparece entre colchetes no incio do
assunto da mensagem, significa que se trata de um anncio importante e que todos devem ler.
Em alguns grupos so criados filtros automticos que varrem as mensagens em busca dos
identificadores de anncios importantes que, uma vez identificados, so imediatamente postados
em uma pgina de anncios no website do grupo. Neste caso uma tecnologia colaborativa foi
adaptada para reforar um processo colaborativo de divulgao de anncios importantes. A
facilitao tcnica se refere s conexes entre os processos colaborativos e as tecnologias que
suportam esses processos.
2.5.4 Gerenciamento das Mudanas
O gerenciamento das mudanas est relacionado ao uso das tecnologias de comunicao,
armazenamento e controle de verses e de erros da distribuio padro. Como os objetos
produzidos devem estar publicamente disponveis e fceis de serem acessados, a tecnologia
colaborativa deve prover uma maneira confivel de se armazenar e disponibilizar esses objetos.
A estrutura dos repositrios da distribuio padro geralmente reflete as mudanas que
ocorreram ao longo do tempo que, junto com os padres de nomenclatura (numerao de
verses) e com as tecnologias de controle de verso e de erros, ajudam no rastreamento das
mudanas no objeto produzido, facilitando a volta para uma verso anterior caso problemas
sejam encontrados aps uma mudana na distribuio padro.
2.5.5 As Contribuies
Contribuio so os processos nos quais os indivduos propem melhorias ou extenses no
projeto atravs de mudanas relacionadas distribuio padro do objeto produzido. A forma
como uma contribuio acontece varia de projeto para projeto, mas certamente envolve todos os
aspectos e componentes do framework. Participantes criam mudanas, que passam por alguns
processos colaborativos onde o grupo decide aceitar, refinar ou rejeitar as contribuies.
Durante esses processos, a tecnologia colaborativa coordena a comunicao e prov o suporte
tcnico para rastrear as mltiplas verses de uma mudana. Se uma contribuio aceita, passa
ento a ser incorporada ao objeto produzido e atualizam-se todas as referncias. Assim, apesar
das contribuies serem atividades desempenhadas por participantes, so fortemente
influenciadas pelo objeto, pela tecnologia e pelo contexto social dos processos colaborativos.

3 O projeto de desenvolvimento do Linux

3.1 O Cerne da Questo
O Linux um kernel (cerne ou ncleo) de sistema operacional multitarefa preemptivo
baseado na Application Program Interface (API) definida pelo padro Portable Operating

Systems Interface (POSIX15). um sistema multiplataforma que suporta mais de dez

arquiteturas de hardware diferentes (DEURZEN, 2004), sendo a mais importante, do ponto de
vista do desenvolvimento e uso, a arquitetura da Intel, utilizada na maioria dos computadores
pessoais.
Moon (2000) faz uma anlise histrica do desenvolvimento do kernel e coloca claramente a
importncia do desenvolvimento em comunidade, fornecendo estatsticas histricas da
participao de desenvolvedores externos:
...em duas semanas do anncio de Torvalds em Outubro de 1991, 30 pessoas tinham contribudo
com cerca de 200 informes de erros, contribuies de utilitrios, drivers e melhorias para serem
adicionadas ao kernel [...] em Julho de 1995, mais de 15.000 pessoas de 90 pases em 5 continentes
tinham contribudo com comentrios, informes de erro, correes, alteraes, reparos e melhorias.
(MOON, 2000)

O primeiro release da primeira verso do kernel possua um pouco mais de trs mil linhas de
cdigo, distribudas em 88 arquivos escritos em linguagens C e Assembly. Atualmente o kernel
est no release 6 da verso 2, cujo tamanho ultrapassa a quantidade de dois milhes e meio de
linhas de cdigo, distribudos entre milhares de arquivos. O kernel fica disponvel na Internet16 e
uma viso da sua estrutura atual pode ser vista em um mapa disponvel no website do projeto
Kernel Mapper17
O desenvolvimento do kernel costuma ocorrer em duas sries separadas: uma delas a de
produo, ou estvel, cujo segundo nmero (de release) sempre par: 2.0.x, 2.2.x, 2.4.x, 2.6.x,
etc. A outra srie a de desenvolvimento, que no garantida para ser utilizada em sistemas em
produo, e tem o nmero de release sempre mpar: 2.1.x, 2.3.x, 2.5.x etc. Quando a srie de
desenvolvimento atinge a maturidade, ela muda de numerao e se transforma na nova srie de
produo (feature freeze), e uma nova srie de desenvolvimento tem incio. O terceiro nmero
(x) refere-se ao patch (remendo) de correo em uso na verso.
O desenvolvimento do Linux segue a filosofia preconizada por Raymonds (1999) de Faa
releases o quanto antes e libere-os com freqncia. E oua o que os seus usurios tm a dizer.
O kernel ainda hoje tem em Torvalds seu expoente mximo, que toma as principais decises
e define a filosofia geral do projeto. Entretanto, cada release tem sempre um mantenedor
responsvel, que aprova cada aperfeioamento e garante que no haja verses conflitantes. O
primeiro mantenedor do kernel estvel foi prprio Linus Torvalds, seguido pelo ingls Alan
Cox (verses 2.0 e 2.2), depois pelo brasileiro Marcelo Tosatti (verso 2.4) e hoje pelo ingls
Andrew Morton (na atual verso 2.6). Torvalds e Cox continuam responsveis por supervisionar
as verses do kernel que ainda esto em desenvolvimento.
Em julho de 2003, Torvalds passou, pela primeira vez na vida a trabalhar oficialmente e
integralmente dedicado ao projeto do Linux, como contratado da Open Source Development
Laboratories (OSDL18), uma entidade voltada para a disseminao internacional do Linux. A
OSDL foi fundada no ano 2000, com sedes nos Estados Unidos e Japo, e mantida por
investimentos de cerca de 50 empresas como Cisco, HP, IBM, Intel e Sun. Posteriormente Cox
e Morton tambm passaram a fazer parte do OSDL.
3.2 Comunicao e Percepo
O projeto do desenvolvimento do Linux sempre foi, levando-se em conta o tamanho do
objeto produzido e do nmero de participantes envolvidos, um dos projetos mais minimalistas
em relao infra-estrutura de desenvolvimento.
A lista de distribuio de emails linux-kernel mailing list (LKML) o frum central de
discusso entre os participantes do projeto de desenvolvimento do Linux, incluindo o prprio
15
16
17
18

http://www.pasc.org/
http://www.kernel.org/
http://kernelmapper.osdn.com/
http://www.osdl.org/

Torvalds, que sozinho recebe cerca mais de 200 emails diretos por dia, somente dos
participantes do projeto. A intensidade dessa lista d uma boa idia do que seja o
desenvolvimento no modelo Bazar, pois apenas em uma semana comum de trabalho normal
alcanar um volume superior a 5 MB de mensagens, sejam relacionadas aos diversos
subprojetos em andamento ou a um conjunto de novas idias ou mesmo s velhas questes
recorrentes e suas discusses persistentes, todas pertinentes ao assunto do desenvolvimento do
kernel (KUWABARA, 2000).
O conhecimento, por parte da comunidade, do trabalho produzido pelos participantes fica
registrado no arquivo de crditos que sempre acompanha o kernel. Trata-se de um arquivo de
texto simples onde o participante inclui suas informaes pessoais e principais reas de
contribuio, segundo o seguinte modelo:

Fig. 4 A estrutura do arquivo de crditos do Linux.

As informaes so colocadas pelos prprios participantes, mas precisam
ser aceitas pelos mantenedores do kernel (TUOMI, 2004).
Ainda que no haja uma hierarquia definida e que todos trabalham de acordo com interesses e
aptides pessoais, sabe-se que entre Torvalds e a comunidade de participantes existe um grupo
de consultores tcnicos, informalmente chamados de lieutenants (tenentes), que so
participantes que ganharam o status de programadores competentes e com expertise de
comprovada importncia para o projeto atravs de anos de participao. Apesar desse grupo no
existir de maneira formal, sua composio aceita pela comunidade como uma espcie de
seleo natural, ainda que as informaes e opinies sobre quem faz (ou deveria fazer) parte
do grupo divergem entre os participantes do projeto (KUWABARA, 2000).

Fig. 5 A estrutura do Linux mostrada atravs do fluxo de informaes.

Esta estrutura mostra que os lieutenants" representam uma espcie de suporte da cadeia de valor e no uma camada,
pois os participantes podem interagir diretamente com Torvalds. Trata-se de uma estrutura em rede, na qual todos os
participantes tm acesso a todos os ns do sistema. O fluxo da informao tambm abrange toda a rede, uma vez que
toda a comunicao se da atravs da lista de distribuio linux-kernel mailing list (DAFERMOS, 2001).

Quando um novo participante entra na lista LKML, assim como acontece em outras listas na
Internet, sempre convidado a ler a documentao de perguntas e respostas mais freqentes
(LKML FAQ19), que nesse caso, entre suas questes principais, esclarece algumas regras
implcitas que regem o bom funcionamento da lista, a saber:

Mantenha-se no assunto. uma lista sobre o kernel do Linux, para programadores;

Use somente o idioma ingls!;
No coloque mensagens em formato HTML, apenas em modo texto;
Se voc usa outro sistema operacional, esteja seguro de que seu programa de email no
usa Charset="Windows*" ou suas mensagens sero bloqueadas;
Se for fazer uma pergunta, antes procure ver se j no h uma resposta na documentao
ou no arquivo da lista. Lembre-se que 99% das perguntas desta lista j foram respondidas
pelo menos uma vez. Normalmente a primeira resposta a mais completa, desta forma a
resposta armazenada ser sempre melhor do que qualquer outra que receba de algum
que j respondeu a mesma pergunta uma dzia de vezes.
Seja preciso, claro e conciso ao fazer uma pergunta, comentrio, anncio de bug,
sugesto de correo ou qualquer outra coisa. Coloque fatos, evite opinies.
Seja gentil, no h necessidade em ser rude. Evite expresses que possam ser
interpretadas como agressivas em relao aos outros participantes da lista, mesmo que o
assunto tratado seja controverso ou particularmente relevante para voc;
No se arraste em controvrsias. No tente impor a ltima palavra. Voc at poder ter a
ltima palavra, mas certamente ter perdido toda sua simpatia;
Uma linha de cdigo vale mais do que mil palavras. Se est pensando em uma nova
funcionalidade, implemente-a primeiro e s depois coloque-a na lista para comentrios;
fcil criticar o cdigo dos outros, mas quando se escreve cdigo pela primeira vez no
fcil. Se voc encontrar um erro ou alguma coisa que possa ser melhorada, no coloque
imediatamente uma mensagem do tipo Este pedao de cdigo um lixo, como foi parar
dentro do kernel? Ao invs disso, entre em contato com o autor do cdigo, explique a
questo e faa o entender de uma maneira simples e humilde. Faa isso algumas vezes e
ser reconhecido como um bom depurador de cdigos. E quando escrever o seu pedao
de cdigo, os outros iro prestar ateno no que fez;
No se aborrea e responda com veemncia os iniciantes que fazem perguntas erradas.
Isso aumenta o rudo na lista. Envie-os um email privado apontando a fonte da
informao que procuram (por exemplo, esta FAQ);
No coloque nenhuma mensagem religiosa ou poltica, inclusive em sua assinatura de
email. Ao fazer isso no corpo da mensagem as pessoas iro se aborrecer, pois um
assunto fora do objetivo da lista, alm do desperdcio de uso da banda de rede (lembre-se
que apesar de estarmos no sculo XXI, muitas pessoas ainda pagam pelo tempo de uso na
Internet); Se o fizer em sua assinatura de email, apesar de ser menos irritante, certamente
far a maioria das pessoas ignorarem a sua mensagem. Deixe o palanque em casa. E se
quiser ser levado a srio, limite-se aos assuntos tcnicos.

Apesar de ser um projeto virtual, com participantes espalhados ao redor do mundo, a

comunidade de desenvolvimento do Linux se rene pessoalmente em eventos anuais informais
como o Kernel Summit20 para trocar experincias, combinar as agendas e prximos passos.

19
20

http://www.tux.org/lkml/
http://lwn.net/Articles/KernelSummit2006/

3.3 Controle de Verses e Erros

O projeto do desenvolvimento do Linux sempre foi, levando-se em conta o tamanho do
objeto produzido e do nmero de participantes envolvidos, um dos projetos mais minimalistas
em relao infra-estrutura de desenvolvimento. At a verso 2.4, incrivelmente, apenas listas
de discusso e emails eram utilizadas por sua comunidade de desenvolvimento.
No de final de 2002, no entanto, foi lanado o Kernel Bug Tracker21 sistema para controle de
erros, baseado na ferramenta Bugzilla. Este sistema est hospedado em um website no OSDL,
com a administrao do banco de dados de erros sendo realizada pela IBM.
Outro recente projeto importante na manuteno da qualidade o Kernel Janitor22, que
objetiva limpar constantemente o cdigo-fonte do kernel atravs da busca e eliminao de
erros em trechos antigos atravs do reaproveitamento de correes recentes, originalmente feitas
para outros trechos do cdigo do kernel.
A implantao de uma ferramenta automtica de controle de verso (e integrao) do objeto
produzido ainda demorou a acontecer no Linux, pois Torvalds sempre se ops idia, uma vez
que somente confiava tal tarefa aos mantenedores credenciados (SHAIKH, 2003).
Com o nmero, cada vez maior, de mudanas sugeridas pelos participantes, entretanto, o
projeto precisou adotar uma ferramenta de controle de verses. Torvalds, que nunca quis
trabalhar com o CVS, apesar de alguns participantes usarem essa ferramenta extra-oficialmente,
decidiu pelo uso do BitKeeper, uma ferramenta que, apesar de ser tecnicamente superior outra,
gerou uma enorme polmica, com discusses dentro (e fora) da comunidade pois, ao contrrio
do CVS, o BitKeeper no possua a licena de uso segundo os conceitos de software livre
preconizados pela GPL (SHAIKH, 2003). Ideologias parte, o controle de verses do kernel23
com BitKeeper proporcionou um ganho significativo de produtividade em um sistema que fica
cada dia mais complexo. Como exemplo, somente nos nove primeiros meses do ano de 2003
ocorreram mais de 12 mil mudanas no cdigo do kernel, efetuadas por mais de 550
participantes (SEARLS, 2003). No incio de 2005, entretanto, o prprio Linus Torvalds
comeou o desenvolvimento de uma nova ferramenta, chamada Git24, que foi disponibilizada
sob a GPL e passou a ser a ferramenta usada na manuteno do kernel, sendo hoje tambm
aplicada em outros projetos de software.

3.2 A Padronizao das Distribuies do Linux

Nos primeiros anos de existncia do Linux, Torvalds simplesmente disponibilizava a verso
estvel do kernel e alguns comandos bem bsicos. O usurio interessado em usar o sistema,
entretanto, tinha que, alm do baixar o kernel pela Internet, tambm arranjar todos os demais
programas complementares, compilar tudo e acertar os arquivos de configurao para ento
poder proceder com a instalao. Como isso trabalhoso at mesmo para um hacker iniciado no
assunto, surgiram as distribuies, baseadas na idia de se disponibilizar os programas
principais pr-compilados, de tal forma que o usurio s precisasse peg-los (em CD-ROM ou
via Internet) e instal-los em sua mquina.
Hoje existem dezenas de empresas e instituies, ao redor do mundo, que mantm centenas
de distribuies e as principais diferenas entre elas so:
O sistema de empacotamento do software;
A estrutura dos diretrios. Teoricamente todas as distribuies seguem um mesmo padro,
o Filesystem Standard (FSSTND) mas esse padro bem relaxado e, especialmente os
arquivos de configurao do sistema, so bastante diferentes entre as distribuies;
21

http://bugme.osdl.org/
http://janitor.kernelnewbies.org/
23 http://linux.bkbits.net/
24 http://git.or.cz/
22

 A biblioteca bsica libc, que contm funes bsicas para o funcionamento do sistema
operacional. Quando uma nova verso dessa biblioteca lanada, algumas distribuies a
adotam imediatamente, enquanto outras, mais conservadoras, aguardam um pouco. Nesse
meio-tempo, alguns programas podem funcionar em algumas distribuies e no em
outras.
A diversidade de distribuies de Linux, que foi providencial na disseminao do sistema em
seus primeiros anos de vida, teve como conseqncia uma falta de padronizao que terminou
por criar problemas para a comunidade Linux. Entre outras questes, durante muito tempo era
difcil obter verses pr-compiladas de aplicativos, exceto se tivessem sido preparadas
especificamente para a distribuio de Linux que o usurio estivesse utilizando, o que exigia um
conhecimento da instalao de programas a partir da compilao de seu cdigo-fonte, o que se
constitua numa grande barreira ao uso e adoo do Linux.
Com a entrada de participantes de maior porte no mercado criado em torno do Linux surgiu a
necessidade de convergncia em torno de um padro, sem restringir a possibilidade de
diferenciao entre as distribuies - mantendo assim a liberdade, sem permitir a fragmentao
do Linux em uma srie de alternativas incompatveis entre si, como ocorreu com o sistema
operacional UNIX. Assim, em 2001, foi criado o Linux Standard Base (LSB25), que visa
desenvolver e promover um conjunto de padres para aumentar a compatibilidade entre as
distribuies de Linux. O LSB dividido em trs componentes principais: a especificao do
sistema, as ferramentas de teste e um exemplo de distribuio para referncia. A especificao
do sistema define a chamada Binary Application Interface (BIA), que o ambiente que toda
aplicao desenvolvida, levando em conta o LSB, dever esperar encontrar em qualquer
distribuio de Linux, incluindo o nome e localizao dos arquivos, verso das bibliotecas, e
diversos outros fatores. Apesar do padro LSB ter sido adotado pelos principais participantes do
mercado Linux, incluindo as principais distribuies, os desenvolvedores de aplicativos e as
empresas de suporte, ainda possvel encontrar aplicaes que somente funcionam em
determinadas distribuies do Linux.
Os esforos de padronizao so coordenados pelo Free Standards Group (FSG26), que alm
de cuidar do LSB, tambm promove outros padres do Linux relacionados
internacionalizao, clusterizao, impresso, etc.
3.3 O Projeto de Documentao do Linux
Visando diminuir a barreira de entrada do uso do Linux atravs da disponibilizao de
informaes para facilitao do uso, surgiu o Linux Documentation Project (LDP27), um projeto
cujo foco est na produo de documentao padronizada do Linux. Existem quatro tipos de
objetos produzidos no LDP:
Guias, que so livros com informao detalhada e aprofundada do sistema, segundo um
referencial variado (guia usurio, do programador, do administrador do sistema, etc.);
HOWTOs, que so como receitas de bolo para execuo de tarefas comuns no uso do
sistema, como a instalao, gerenciamento de caixas postais, habilitao de recursos de
segurana, etc;
Man pages, que so as pginas do manual on-line, que contm informaes a respeito dos
programas, funes e utilitrios de que fazem parte do sistema;

25

http://www.linuxbase.org/
http://www.freestandards.org/
27 http://www.tldp.org/
26

 FAQs (Frequently Asked Questions) que so as perguntas e respostas mais comuns

colecionadas ao longo da existncia do projeto e que so divididas em categorias
especficas (Linux, projeto LDP, intgrao com outros sistemas operacionais, etc.)
Alm dos objetos descritos acima, o LDP coordena a traduo do contedo produzido para
dezenas de idiomas, inclusive o portugus do Brasil, onde utiliza um vocabulrio padronizado
com milhares de entradas (entre termos simples, frases-exemplo reais e acrnimos). Os termos e
suas tradues foram obtidos de outros glossrios em papel, web, e termos discutidos (em vrias
listas de discusso) quando da traduo de outros livros e programas (ou seja, a experincia de
inmeros tradutores).

4 Desafios para o Software Livre

O software livre vem ganhando espao sistematicamente no cenrio mundial e talvez esse
interesse esteja crescendo mais rpido do que a conscincia sobre a filosofia na qual baseado,
e isto pode conduzir a problemas.
Como j foi dito na introduo deste texto, trata-se de um assunto multifacetado, que contm
questes relacionadas a diversos assuntos (engenharia de software, propriedade intelectual,
etc.). Do ponto de vista dos aspectos relacionados construo cooperativa, Rothfuss (2002)
indica que esses fatores so decorrentes, principalmente, da falta de organizao formal, e
podem ser resumidos conforme a seguir:
4.1 Redundncia de Esforos
A coordenao em projetos de software livre relativamente pouca. Grupos independentes
muitas vezes desenvolvem tarefas similares em paralelo sem conhecer o trabalho de seus pares,
gerando um consumo adicional de recursos. No h dvida que o efeito colateral benfico disso
o aumento do nmero de opes a escolher e que as diferentes alternativas melhoram a
qualidade final do software. Entretanto estes trabalhos paralelos dificultam a escolha de
alternativas por parte dos usurios, o que pode terminar em conflitos de posicionamento no
mercado, gerando discusses apaixonadas, quase religiosas, com potencial de provocar rachas
e enfraquecer o movimento de disseminao do software livre.
4.2 Problemas de Comunicao
Ainda que o ingls seja o principal idioma usado nos projetos de software livre, certamente
no o idioma nativo de todos os participantes. Isso pode acarretar em diversos problemas de
entendimento, que tendem a piorar conforme os projetos aumentem de nmero de participantes
ao redor do mundo.
Outro problema de comunicao, que tambm est relacionado expanso, diz respeito ao
volume e relevncia do contedo das mensagens, que ainda so a base da comunicao dos
grupos de desenvolvimento. comum perceber em grupos de discusso, cada vez mais, os
participantes reclamando da falta de etiqueta e boas maneiras em meio a uma profuso de
informaes inteis. Isso certamente menor nos grupos moderados, mas inegvel que a
relao sinal-rudo na Internet no das melhores atualmente e est piorando cada vez mais.
4.3 Senso de Prioridade
Em projetos de software livre, dificilmente as decises importantes e profundas so tomadas
com a agilidade necessria. Isso acontece devido natureza distribuda do processo, que aliada
a uma liderana tnue, pode impossibilitar a resoluo de uma prioridade ou distorc-la em
direo s tendncias pessoais de algum participante influenciador. Uma necessidade de

mudana mais profunda normalmente desencadeia uma seqncia interminvel de argumentos

favorveis e contrrios, uma vez que ningum pode forar sua opinio aos demais e todos se
sentem no direito de opinar, mesmo aqueles que no tm o conhecimento ou a preparao
necessria para analisar suas consideraes luz de outras questes.
4.4 Proliferao de grupos fechados
Os projetos de software livre no tm regras formais ou convenes escritas. As relaes
entre seus participantes so regidas por um conjunto de regras consuetudinrias no escritas,
baseadas em costumes criando uma netiqueta (regras de etiqueta na Internet). Dessa forma,
os novos membros tm que gradualmente aprender as regras informais e, de certa forma, so
medidos pelo sucesso em reagir s dicas passadas pelo grupo. As comunidades, principalmente
as mais antigas, so entrosadas e conseguem melhorar a comunicao entre os membros atravs
do compartilhamento de contextos culturais, porm acabam por dificultar ainda mais a
integrao do grupo com os recm chegados. medida que os participantes competem por
ateno e reconhecimento de talento, essas barreiras so danosas ao projeto, principalmente aos
menores, que ainda se estruturam. O desenvolvimento de software livre um processo de
aprendizado, onde as partes envolvidas contribuem para (e aprendem da) comunidade e esse
equilbrio importante. Edwards (2000) chamou este fenmeno de Comunidades
Epistmicas.
4.5 Falta de Foco
De acordo com estudos cerca de 70% dos participantes de software livre gastam 10 horas ou
menos por semana em trabalhos relacionados ao projeto e essas horas so, em sua maioria,
gastas durante noite ou nos finais de semana (BERLECON, 2002). O baixo nvel de
participao pode introduzir problemas de comunicao, dado que muitos participantes tm
dificuldade em acompanhar todos os desenvolvimentos realizados no projeto. Essas
circunstncias certamente dificultam o foco dos participantes no desenvolvimento do projeto.
Normalmente o trabalho conduzido aos pedaos e finalizado apenas aps um longo perodo. O
esforo dispensado em estar a par de todas as questes geralmente to grande que sobra pouco
tempo para as contribuies efetivas. Muitos participantes perdem o interesse ou so absorvidos
por outros comprometimentos externos, deixando muitos projetos pela metade.
4.6 Dependncia de Pessoas-Chave
Muitos projetos de software livre dependem de poucas pessoas. Taurion (2004) afirma que
10% dos participantes contribuem com 78% do cdigo; o segundo dcimo, com 12%, o terceiro,
com 3%; os outros, com menos de 1% cada. Existem algumas explicaes plausveis para este
fenmeno. A mais bvia que o nvel de conhecimento necessrio para se analisar e entender
um cdigo-fonte de um sistema grande requer treinamento e experincia. O esforo em adquirir
este conhecimento no efetuado pela maioria dos participantes. Outra explicao est
relacionada ao nvel de reconhecimento que os participantes esperam receber por suas
contribuies. Apenas um nmero pequeno de participantes acaba se tornando amplamente
reconhecido por suas contribuies, o que tende a fortalecer ainda mais o papel dos
contribuidores principais. Essa dependncia pode se tornar um risco se uma pessoa-chave no
puder continuar seu trabalho no projeto por algum motivo. Talvez seja impossvel reconstruir
todo seu conhecimento implcito a partir de seus objetos (cdigo-fonte e documentao).

4.7 Escassez de Lideranas Competentes

O sucesso de um projeto de software livre depende de uma boa e carismtica liderana. Alm
das qualidades intrnsecas da perspectiva da Engenharia de Software, o lder de projeto precisa
enderear questes de comunicao, marketing, juzo poltico e motivao. A liderana
normalmente feita por persuaso, pois no h um mandato oficial hierarquicamente
estabelecido. O lder avaliado no s por seus conhecimentos tcnicos, mas por sua viso e
habilidade em se comunicar com os co-participantes. (BCG, 2002). Ainda que haja muitos
participantes com conhecimentos tcnicos, as exigncias so to seletivas que se torna difcil
preencher todas as posies de liderana com pessoal qualificado. Raymond (1999) diz que o
sucesso do Linux se deve muito mais excelente liderana exercida por Torvalds do que por
suas habilidades tcnicas. A escassez de novos e bons lderes uma questo muito sensvel para
o futuro dos projetos de software livre, conforme atestado pelo prprio Torvalds (SEARLS,
2003).
4.8 Problemas Legais
A propriedade intelectual, com seus copyrights, patentes, marcas registradas e segredos
comerciais certamente um dos campos mais obscuros e esotricos da esfera jurdica,
principalmente quando aplicada ao software e seus algoritmos. muito difcil saber se
determinado mtodo para se resolver um problema de software j foi patenteado ou no, e a
interpretao dessas leis varia conforme o pas.
Stallman (1999) chegou a afirmar que A pior ameaa que ns enfrentamos so as patentes
de software que podem colocar algoritmos e caractersticas fora dos limites do software livre
por mais de vinte anos.
Ainda que esse problema exista para todo o mercado de software (livre e proprietrio), no
modelo de desenvolvimento de software livre, distribudo pelo mundo e sem organizao
formal, existe um maior risco potencial de se infringirem essas leis. Apenas como exemplo, um
estudo recente conduzido pela Open Source Risk Management28 mostrou que apenas o kernel do
Linux potencialmente viola 283 patentes, incluindo 27 que pertencem Microsoft. Esse tipo de
preocupao legal, que tambm varia conforme o pas pode prejudicar o futuro do software
livre.

5 Concluso
Este artigo procurou mostrar o modelo de desenvolvimento do software livre atravs da
perspectiva do Trabalho Cooperativo Suportado por Computador. Essa anlise ajudou a revelar
um pouco mais do contexto no qual software livre est inserido e reforar o argumento de que
esse assunto no pode ser explicado somente por uma disciplina ou viso, mas sim atravs de
um conjunto delas.
Atravs da apresentao de um framework conceitual, complementada com um estudo de
caso do desenvolvimento do Linux, foram apresentados os principais elementos e inter-relaes
que existem em um projeto tpico, com participantes, processos, ferramentas e objetos
produzidos em um modelo cooperativo de trabalho.
O estudo mostrou tambm que o fenmeno do software livre, apesar de ainda estar em
formao, vem crescendo bastante nos ltimos anos e que sua expanso (e futuro) dependem da
estabilizao de alguns fatores hoje apresentados como desafios.

28

http://www.osriskmanagement.com/

Referncias
AOKI, A., Hayashi, K., Kishida, K., Nakakoji, K., Nishinaka, Y., Reeves, B., Takashima,
A., & Yamamoto,Y. A case study of the evolution of Jun: an object-oriented open-source
3D multimedia library. In Proceedings of the 23rd international conference on software
engineering (ICSE 01) (pp. 524533). Toronto, Canad, 2001.
BCG, Boston Consulting Group. Hacker Survey release 0.73, 2002. Disponvel em
www.osdn.com/bcg/BCGHACKERSURVEY-0.73.pdf . Visitado em Jan de 2007.
BERLECON, Research. FLOSS. Free/Libre and Open Source Software: Survey and Study.
European Commission, 2002. Disponvel em http://www.infonomics.nl/FLOSS/. Visitado
em Jan de 2007.
BROOKS, F. P. Jr. The Mythical Man-Month. Addison-Wesley. 2 ed. 1995
BROWN, J. S. and Duguid, P. Organizational Learning and Communities-of-Practice:
Toward a Unified View of Working, Learning, and Innovation, Organization Science, 2(1),
1991, 40-57
BUTTON, G., Sharrock, W. Project Work: The Organisation of Collaborative Design and
Development in SoftwareEngineering, Computer Supported Cooperative Work: The Journal
of Collaborative Computing, 5, 1996, 369-386
DAFERMOS, George. Management and Virtual Decentralised Networks: The Linux
Project,
First
Monday,
2001.
Disponvel
em
http://www.firstmonday.dk/issues/issue6_11/dafermos/ . Visitado em Jan de 2007.
DEURZEN, Van. Linux Architectures. 2004.
Disponvel em http://home.hccnet.nl/p.van.deurzen/linuxweb/docs/architectures.htm .
Visitado em Jan de 2007.
EDWARDS, Kasper. Epistemic Communities, Situated Learning and Open Source Software
Development Department of Manufacturing Engineering and Management, Technical
University of Denmark, 2000.
FIELDING, R. T. Shared leadership in the Apache Project. Communications of the ACM,
v. 42, n. 4, p. 4243, abr 1999.
GANCARZ, M. UNIX Philosophy. Prentice-Hall, 1995.
HEXSEL, Roberto, Propostas de Aes de Governo para Incentivar o Uso de Software
Livre, Relatrio Tcnico do Departamento de Informtica da UFPR, 004/2002 , 2002.
KRAUT, R. E. and Streeter, L. Coordination in SoftwareDevelopment, Communications of
the ACM, 38(3),1995, 69-81
KUWABARA, Ko. Linux: A Bazaar at the Edge of Chaos. FirstMonday 5(3), 2000.
Disponvel em http://www.firstmonday.dk/issues/issue5_3/kuwabara/ . Visitado em Jan de
2007.
LANCASHIRE, D. Code, culture, and cash: The fading altruism of open source
development.
FirstMonday,
6(12),
2001.
Disponvel
em
http://firstmonday.org/issues/issue6_12/lancashire/ . Visitado em Jan de 2007.

MAADA, D. L. TIJIBOY, A.V. Aprendizagem Cooperativa em Ambientes Telemticos.

In: Congresso Ibero-Americano de Informtica na Educao, IV. Braslia, outubro de 1998.
MCKUSICK, M. K. Twenty years of Berkeley UNIX. In: Open Sources. Sebastopol:
OReilly and Associates, 1 ed., 1999. p. 3146.
MOON, J., SPROULL, L. Essence of Distributed Work: The Case of Linux Kernel. First
Monday. 2000. Disponvel em http://www.firstmonday.org/issues/issue5_11/moon/.
Visitado em Jan de 2007.
NAKAKOJI, K., Yamamoto, Y., Nishinaka, Y., Kishida, K., & Ye, Y.. Evolution patterns
of open-source software systems and communities. In Proceedings of the international
workshop on principles of software evolution (IWPSE 2002), Orlando, FL, 2002.
OSI. The Halloween Documents, 1988. Disponvel em http://www.catb.org/~esr/halloween/.
Visitado em jan de 2007.
PAVLICEK, C. Embracing insanity: Open source software development. Indianapolis,
Sams, 2000.
RAYMOND, E. S. The Cathedral and The Bazaar. OReilly and Associates, 1 ed., 1999. p.
2778.
REIS, Christian. Caracterizao de um Modelo de Processo para Projetos de Software
Livre, Instituto de Cincias Matemticas e de Computao, So Carlos SP, 2001.
ROTHFUSS, Gregor. A Framework for Open Source Projects, Universitt Zrich, Institut
fr Informatik, 2002. Disponvel em http://greg.abstrakt.ch/docs/OSP_framework.pdf .
Visitado em Jan de 2005.
SCHARFF, E. D. Open Source: A Conceptual Framework for Collaborative Artifact and
Knowledge. University of Colorado, 2002
STALLMAN, R. M. The GNU Operating System and the Free Software Movement. In:
Open Sources. Sebastopol: OReilly and Associates, 1. ed., 1999. p. 5370.
SCHENK, Thomas. Linux: Its history and current distributions. Disponvel em
http://www-106.ibm.com/developerworks/library/it-schenk1/schenk1.html, 2001.Visitado
em Jan de 2007.
SEARLS, Doc. Linus & the Lunatics. Transcrio de palestra no Linux Lunacy Geek Cruise
2003. Disponvel em http://www.linuxjournal.com/article/7272. Visitado em Jan de 2007.
SHAIKH, M. Cornford, T. 2003. Version Management Tools: CVS to BK in the Linux
Kernel, disponvel em http://opensource.mit.edu/papers/shaikhcornford.pdf . Visitado em
Set 2004.
TANENBAUM, Andrew. Operating Systems, Design and Implementation. Prentice-Hall,
1987.
TAURION, Cezar. Software Livre - Potencialidades e Modelos de Negcios. Brasport,
2004.
TORVALDS, L. The Linux Edge. In: Open Sources. Sebastopol: OReilly and Associates,
1 ed., 1999. p. 101111.

TUOMI, Ilkka. Evolution of the Linux Credits File: Methodological Challenges and
Reference Data for Open Source Research. FirstMonday, 2002 Disponvel em
http://www.firstmonday.dk/issues/issue9_6/tuomi/ . Visitado em Jan de 2007.
YAMAUCHI, Y., Yokozawa, M., Shinohara, T., Ishida, T. Collaboration with Lean Media:
How Open Source Succeeds. In: Proceedings of CSCW, 2000. ACM Press. p. 329-338.

Anexo 1
Definies de termos relacionados ao software livre (HEXSEL, 2002)
BSD: A licena BSD cobre as distribuies de software da Berkeley SoftwareDistribution,
alm de outros programas. Esta uma licena considerada 'permissiva' porque impe poucas
restries sobre a forma de uso, alteraes e redistribuio do software licenciado. O software
pode ser vendido e no h obrigaes quanto incluso do cdigo fonte, podendo o mesmo
ser includo em software proprietrio. Esta licena garante o crdito aos autores do software,
mas no tenta garantir que trabalhos derivados permanecem como software livre.
Copyleft: A maioria das licenas usadas na publicao de software livre permite que os
programas sejam modificados e redistribudos. Estas prticas so geralmente proibidas pela
legislao internacional de copyright, que tenta justamente impedir que alteraes e cpias
sejam efetuadas sem a autorizao dos autores. As licenas que acompanham software livre
fazem uso da legislao de copyright para impedir utilizao no-autorizada, mas estas
licenas definem clara e explicitamente as condies sob as quais cpias, modificaes e
redistribuies podem ser efetuadas, para garantir as liberdades de modificar e redistribuir o
software assim licenciado. A esta verso de copyright, d-se o nome de copyleft.
Debian: A licena Debian parte do contrato social celebrado entre a Debian e a
comunidade de usurios de software livre, e chamada de Debian Free SoftwareGuidelines
(DFSG). Em essncia, esta licena contm critrios para a distribuio que incluem, alm da
exigncia da publicao do cdigo fonte. Estes critrios so: (a) a redistribuio deve ser
livre; (b) o cdigo fonte deve ser includo e deve poder ser redistribudo; (c) trabalhos
derivados devem poder ser redistribudos sob a mesma licena do original; (d) pode haver
restries quanto redistribuio do cdigo fonte, se o original foi modificado; (e) a licena
no pode discriminar contra qualquer pessoa ou grupo de pessoas, nem quanto a formas de
utilizao do software; (f) os direitos outorgados no podem depender da distribuio onde o
software se encontra; e (g) a licena no pode 'contaminar' outro software.
Freeware: O termo freeware no possui uma definio amplamente aceita mas usado com
programas que permitem a redistribuio mas no a modificao, e seu cdigo fonte no
disponibilizado. Estes programas no so software livre.

GPL: A Licena Pblica Geral GNU (GNU General Public License) a licena que
acompanha os pacotes distribudos pelo Projeto GNU, e mais uma grande variedade de
software, incluindo o kernel do sistema operacional Linux. A formulao da GPL tal que ao
invs de limitar a distribuio do software por ela protegido, ela de fato impede que este
software seja integrado em software proprietrio. A GPL baseada na legislao
internacional de copyright.

Open Source: A licena da Open Source Initiative derivada da Licena Debian, com as
menes Debian removidas.
Shareware: o software disponibilizado com a permisso para que seja redistribudo, mas a
sua utilizao implica no pagamento pela sua licena. Geralmente, o cdigo fonte no
disponibilizado e portanto modificaes so impossveis.
Software Comercial: o software desenvolvido por uma empresa com o objetivo de lucrar
com sua utilizao. Note que 'comercial' e 'proprietrio' no so o mesmo. A maioria do
software comercial proprietrio mas existe software livre que comercial, e existe software
no-livre no-comercial.

 Software em Domnio Pblico: o software sem copyright. Alguns tipos de cpia, ou

verses modificadas, podem no ser livres porque o autor permite que restries adicionais
sejam impostas na redistribuio do original ou de trabalhos derivados.
Software Livre (Free Software): o software disponvel com a permisso para qualquer um
us-lo, copi-lo, e distribu-lo, seja na sua forma original ou com modificaes, seja
gratuitamente ou com custo. Em especial, a possibilidade de modificaes implica em que o
cdigo fonte esteja disponvel. Se um programa livre, potencialmente ele pode ser includo
em um sistema operacional tambm livre. E importante no confundir software livre com
software grtis porque a liberdade associada ao software livre de copiar, modificar e
redistribuir independe de gratuidade. Existem programas que podem ser obtidos
gratuitamente, mas que no podem ser modificados, nem redistribudos. Por outro lado, existe
a possibilidade de uso no-gratuito em todas as categorias listadas no que segue. H uma
cpia da definio de software livre pela Free SoftwareFoundation publicada na pgina
http://www.fsf.org/philosophy/free-sw.pt.html
Software Proprietrio: aquele cuja cpia, redistribuio ou modificao so em alguma
medida proibidos pelo seu proprietrio. Para usar, copiar ou redistribuir, deve-se solicitar
permisso ao proprietrio, ou pagar para poder faz-lo.
Software Semi-livre: software que no livre, mas concedida a permisso para que
indivduos o usem, copiem, distribuam e modifiquem, incluindo a distribuio de verses
modificadas, desde que o faam sem o propsito de auferir lucros. Exemplos de software
semi-livre so as primeiras verses do Internet Explorer da Microsoft, algumas verses dos
browsers da Netscape, e o StarOffice.
X.org: O Consrcio X distribui o X Window System sob uma licena que o faz software livre
mas no adere ao copyleft. Existem distribuies sob a licena da X.org que so software
livre, e outras distribuies no o so. Existem algumas verses no-livres do sistema de
janelas X11 para estaes de trabalho e certos dispositivos do IBM-PC que so as nicas
funcionais disponveis, sem similares distribudos como software livre.