Aspectos Do Trabalho Cooperativo No Desenvolvimento De Software Livre

Aspectos do Trabalho Cooperativo no Desenvolvimento de Software Livre Marcelo Sávio IT Architect http://www.linkedin.com/in/msavio http://msavio.myplaxo.com/

Rio de Janeiro - Janeiro de 2007

Resumo. Software livre é todo software cujo código fonte está disponibilizado publicamente, e seu conteúdo pode ser livremente modificado e redistribuído (e não sendo permitida a apropriação desse código). Uma conseqüência indireta desta liberdade é o aparecimento de comunidades de desenvolvimento que trabalham de forma descentralizada, através 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 satisfação entre os seus desenvolvedores e usuários. 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, através do estudo de caso do desenvolvimento do sistema operacional Linux.

1 Introdução Apesar da definição apresentada acima, ainda existem controvérsias em relação ao que seja precisamente considerado software livre. Isso se dá pelo fato de que se trata de um assunto multifacetado, que contém questões relacionadas a assuntos como engenharia de software, propriedade intelectual, modelo econômico, política tecnológica, cooperação1, liderança e motivação. Uma olhada mais de perto em alguns projetos de software livre revela, ainda, uma grande diversidade de objetivos, formas de participação e técnicas de implementação. Ao analisar as atividades que suportam o desenvolvimento de software livre, do ponto de vista do trabalho cooperativo suportado por computador, é possível identificar um desafio comum a todos os projetos: a necessidade da criação e manutenção de um ambiente sociotécnico onde os participantes possam, de forma cooperativa, construir soluções para os problemas de interesse mútuo. As práticas do desenvolvimento de software livre são importantes para a pesquisa em CSCW por dois motivos principais. Primeiro porque o desenvolvimento de software é tradicionalmente um processo de coordenação intensiva que tem atraído 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, conversação on-line, World Wide Web e sistemas de controle de versão e de gerenciamento de configuração, tecnologias que, por sua vez, têm sido um aspecto central nas pesquisas de CSCW.

1

O conceito de cooperação é mais complexo que o de interação e de colaboração, pois além de pressupor ambos requer relações de respeito mútuo e não hierárquicas entre os envolvidos, uma postura de tolerância e convivência com as diferenças e um processo de negociação constante. Percebemos que a diferença fundamental entre os conceitos de colaboração e cooperação reside no fato de que para haver colaboração o indivíduo deve interagir com o outro existindo ajuda - mútua ou unilateral. Para existir cooperação deve haver interação, colaboração, mas também objetivos comuns, atividades e ações conjuntas e coordenadas. (MAÇADA; TIJIBOY, 1998).

1.1 Histórico Resumido do Software Livre (e do Linux) Software Livre é um conceito antigo, embora ainda não tivesse este nome específico desde o início. Até a década 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 código fonte de seus sistemas operacionais e aplicativos. Embora as licenças não explicitassem claramente a liberdade, a redistribuição do software era vista como positiva, e quase todo o software era fornecido com o seu código fonte (STALLMAN, 1999). Os fabricantes até estimulavam, como forma de diminuir os custos de suporte, o compartilhamento de informações e melhorias de software produzidas entre seus usuários2. 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 código fonte aberto em escala mundial. No início da década de 80 o cenário mudou, quando ganhou força o licenciamento restritivo, que não permitia a redistribuição do software fornecido e este passou a significar basicamente o módulo executável, suprimindo o acesso à maioria dos códigos-fonte. Esta mudança de cenário fez com que, em 1984, (STALLMAN, 1999) criasse a Free Software Foundation (FSF3). A filosofia do software livre se baseia em uma definição de liberdade. Por causa da ambigüidade em inglês da palavra "free", tornou-se necessário esclarecer que free software não se refere ao preço, mas à liberdade dos usuários 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 propósito. 2. A liberdade de estudar como o programa funciona e adaptá-lo às suas necessidades (o acesso ao código fonte é essencial para isso). 3. A liberdade para redistribuir cópias do programa de modo que outros se beneficiem. 4. A liberdade de melhorar o programa e distribuir o seu aperfeiçoamento para o público, de modo que toda a comunidade se beneficie (novamente o código fonte é necessário).

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 compatível com UNIX, foi chamado de GNU4 (um acrônimo recursivo que significa GNU is Not UNIX). O desafio não se restringia apenas à criação do núcleo do sistema em si (chamado HURD e que ainda não está pronto até hoje), mas também de uma coleção de aplicativos, ferramentas e bibliotecas que permitissem sua plena utilização, 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 usuários desse sistema, que tinha uma natureza aberta e uma filosofia própria, sumarizada por Gancarz (1995) como sendo composta dos seguintes pontos: 1. 2. 3. 4. 5. 6. 7. 8. 9.

Pequeno é belo; Faça cada programa perfazer bem apenas uma tarefa apenas; Construa um protótipo assim que possível; Escolha portabilidade sobre eficiência; Armazene dados numéricos em arquivos texto; Faça reuso do software para sua vantagem; Use scripts shell para aumentar portabilidade e reuso; Evite interfaces restritivas com o usuário; Faça 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 usuários, como o SHARE (para usuários de sistemas IBM) e o DECUS (para usuários de sistemas DEC). 3 http://www.fsf.org/ 4 http://www.gnu.org/

Em 1991, Torvalds (1999) então estudante da Universidade de Helsinki (Finlândia), iniciou o desenvolvimento do Linux, um núcleo de sistema operacional compatível com o UNIX, a partir do reuso de códigos e idéias do Minix, um pequeno sistema operacional de uso acadêmico criado por Tanenbaum (1987). A partir da primeira versão, Torvalds convidou, via newsgroups da Internet, outros desenvolvedores a contribuírem nessa empreitada. Houve bastante adesão e, de forma surpreendentemente rápida, a codificação e a manutenção constantes neste núcleo, o fizeram evoluir para se tornar um software com funcionalidades similares às dos núcleos 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 razão o sistema hoje também é chamado de GNU/Linux. O licenciamento através da GPL e a utilização da Internet como o canal principal de comunicação 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 contraposição ao “Catedral”, modelo tradicional no qual o desenvolvimento é realizado de forma fechada e pouco cooperativa. Ele reforçou esta perspectiva através da afirmação de que o Linux é um contra-exemplo da “Lei de Brooks”, uma lei clássica da Engenharia de Software, que diz o seguinte: “...o tempo de um programador não é 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 comunicação de um projeto crescem com o quadrado do número de desenvolvedores, enquanto o trabalho feito cresce somente linearmente” (BROOKS, 1995).

Outra característica do modelo Bazar, importante para a qualidade do objeto produzido, é ter uma grande base de usuários com acesso ao código fonte, pois segundo Raymond (1999) “Se exposto a um número suficiente de olhos, todos os bugs são superficiais”, pois a depuração de erros é uma atividade paralelizável e será resolvida mais rapidamente quanto maior for a base de usuários participantes. O tamanho e a agilidade de um projeto de software livre, não são as únicas qualidades que o distinguem de um modelo “Catedral”. Outra importante diferença está em sua organização interna, particularmente na ausência de uma coordenação global sob uma autoridade central e pela inexistência de um planejamento de projeto do tipo “Top-Down”. Aliás, em software livre normalmente a estratégia vem depois do desenvolvimento e a ação antes do planejamento (TAURION, 2004). A partir de 1988 o software livre se tornou notícia cada vez mais freqüente na imprensa, quando a Netscape abriu o código do seu principal produto, o Communicator e também quando empresas de grande porte como IBM e Oracle começaram dar suporte ao Linux e ao Apache. Esse ano também 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 após a criação da Open Source Initiative (OSI5), em 1988. Diferentemente da FSF, que suporta somente o uso de suas próprias licenças, a OSI não tem licenças próprias, mas certifica todas as dezenas licenças existentes no mercado (inclusive as da FSF) dentro de seus próprios parâmetros 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 licenças da FSF, representando assim uma espécie de alternativa intermediária. Desta forma, todo software livre é, por definição, aberto, porém nem todo software aberto é livre.

5

http://www.opensource.org/

1.2 Os Projetos de Software Livre Embora não exista uma definição precisa do que seja um projeto de software livre, existe um consenso informal de que o software em conjunto com seus desenvolvedores, usuários e repositórios de código e documentos constitui um projeto, que desta forma abrange: • Código fonte, que é o software propriamente dito, mas que existe em forma de inúmeras cópias entre todos seus usuários e repositórios de dados. Software livre, em geral, tem uma versão bem definida e distribuída 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 exceção, trabalham cooperativamente através da Internet e podem ter status diferenciados dentro do projeto (FIELDING, 1999). • Os usuários do software. Apesar de todo software ter usuários, sua participação em projetos de software livre é essencial, pois discutem inovações e apresentam erros encontrados com freqüência, incentivando os desenvolvedores a trabalhar por um produto melhor (RAYMOND, 1999). • Os repositórios de documentos e códigos. Normalmente todo projeto tem algum site central que é uma referência para desenvolvedores e usuários buscarem códigos e informações atualizadas. É interessante perceber que todo o processo de desenvolvimento e distribuição depende essencialmente do uso da Internet, e que esta é um pré-requisito para a existência de um projeto de software livre. Segundo o Sourceforge6, website do Open Source Technology Group (OSTG7), que é o maior repositório de software livre e de código aberto disponível na Internet, existem em seus registros mais de 130 mil projetos, em diferentes estágios de desenvolvimento, classificados da seguinte forma: • Planejamento: Nenhum código foi escrito ainda e o escopo do projeto ainda está sendo definido, Logo que algum resultado tangível em forma de código apareça, o projeto entra no próximo estágio; • Pré-Alfa: Código muito preliminar produzido. Não é esperado, entretanto que este código seja capaz de compilar ou ser executado. Observadores externos ao projeto poderão ter dificuldade em entender o significado do código. Assim que uma intenção coerente que indique uma direção seja percebida no código, o projeto passa para o estágio seguinte; • Alfa: O código produzido funciona pelo menos de forma parcial e o projeto começa a tomar forma e absorver novas características. À medida que o número de sugestões e modificações começa a diminuir, o projeto entra no estágio seguinte; • Beta: O código está, de uma forma geral, completo em relação às características propostas no projeto original, mas requer testes de depuração. Quando o número de erros estiver reduzido o suficiente para entrar em produção, o projeto passa para o estágio seguinte; • Estável: O software é utilizável e confiável o suficiente. As mudanças serão aplicadas cuidadosamente e com o objetivo de aumentar a estabilidade, nunca de adicionar funcionalidades. Se nenhuma mudança significante acontecer em um período longo, o projeto entra no último estágio, mesmo se problemas menores ainda possam existir;

6 7

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

• Maduro: Há muito pouco ou nenhum desenvolvimento no código, uma vez que o software preenche todos os seus objetivos corretamente. Mudanças serão aplicadas com extremo cuidado. Pode permanecer nesta fase por vários anos, até que se torne obsoleto ou substituído por outro melhor. Ainda assim o código permanecerá indefinidamente disponível para servir a objetivos educacionais; • Inativo: Projeto interrompido por falta de manutenção, movimentação de arquivos ou abandono por parte de seus líderes (projeto órfão).

2 O Modelo de Desenvolvimento do Software Livre Quando o desenvolvimento é feito por uma equipe pequena e local, ou por uma comunidade de prática, onde os participantes estão fortemente ligados uns aos outros, o trabalho cooperativo é certamente mais fácil, pois, nessas comunidades de prática, os membros podem aprender as novidades de forma mais eficiente, resolver seus problemas de maneira mais tranqüila, e ainda têm mais possibilidades de encontrar novas oportunidades de inovação (BROWN, 1991). Em contraste, a coordenação de uma equipe numerosa e remota precisa ser inevitavelmente formal e o gerenciamento das contingências sempre é uma tarefa muito mais difícil de gerenciar (KRAUT, 1995). Os projetos de desenvolvimento distribuído de software livre apresentam características comuns, quando analisados do ponto de vista de construção cooperativa. Segundo Scharff (2002), essas características comuns podem ser mapeadas em um framework que as organiza de forma descritiva em um modelo que enfatiza a construção 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 estão criando (objeto produzido), os processos empregados (processos colaborativos) e os meios usados para comunicação e coordenação do projeto (tecnologias colaborativas).

Fig. 1. Framework conceitual do desenvolvimento do software livre 2.1 Os Participantes São os componentes principais de um projeto de software livre. Sem um grupo de participantes ativos não haverá software produzido ou este será apenas um pedaço de software sem mudanças. A participação em um projeto de software livre abrange, além da produção do código fonte em si, a contribuição em forma de idéias, feedbacks, correções e demonstrações. Assim, os participantes podem ser simpatizantes, usuários, desenvolvedores, testadores, documentadores ou evangelistas. Geralmente são ativamente envolvidos em todas as fases de um projeto e trabalham de forma voluntária, motivados por uma mentalidade altruísta (RAYMOND, 1999).

Um estudo demográfico realizado por Boston (2002) com uma população de líderes e desenvolvedores principais de projetos registrados no Sourceforge, revelou que entre os entrevistados: • • • • • • • • • • •

72,6% disseram que, quando estão programando, perdem a noção do tempo por estarem motivados, sendo o tempo de sono considerado a principal contrapartida resultante da participação em um projeto de software livre seguida de perto pela vida social; 44,9% são motivados a trabalhar no projeto pelo desafio intelectual que representa; Apenas 11,1% revelaram como motivação principal desbancar o software proprietário; 70% dos participantes são voluntários e não são financeiramente recompensados (direta ou indiretamente) pelo seu trabalho no projeto; O tempo médio de trabalho gasto nos projetos foi de 14,9 horas por semana; 48,1% revelou que o maior benefício pessoal é o aumento do conhecimento;. 83% se identificaram com a comunidade hacker; 70,2 % dos participantes estão entre 22 e 38 anos, com a média em torno de 30 anos; A população provém de dezenas de países, e a maior parte vem EUA, Alemanha e Reino Unido; 45,4 % dos participantes são programadores profissionais e a média de experiência de 11 anos; A maioria afirmou esperar do líder do projeto não só a realização de tarefas práticas (criação da base de código original e contribuições constantes), mas uma boa visão de longo prazo, iniciativa para diálogo, e disposição para integrar contribuições.

2.2 O Objeto Produzido É o resultado da criação e dos refinamentos sucessivos. Ainda que a produção de código fonte seja atividade central de um projeto de software livre, este não é o único produto final, pois também figuram neste componente toda a documentação, os relatórios de defeitos, as ferramentas de instalação e outros materiais de suporte. A versão do software recomendada para uso em produção é chamada de distribuição padrão. 2.3 Os Processos Colaborativos São convenções, procedimentos, práticas, papéis e responsabilidades que regem as interações entre os membros de um projeto de software livre. Geralmente são difíceis de definir, pois são conhecimentos tácitos, 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 relação à construção cooperativa, seja enfatizando a correção de erros, promovendo novas funcionalidades ou criando referências de implantação. Essas diferentes perspectivas afetam a natureza dos processos colaborativos (NAKAKOJI et al., 2002), e normalmente aparecem quando são endereçadas as questões dos participantes e as respectivas respostas da comunidade. São situações que invariavelmente remetem a novas situações de colaborações, como por exemplo: • Quando uma comunidade é intolerante com perguntas simples ou assume uma postura defensiva perante uma sugestão, pode inibir os participantes; • Se algum participante quer contribuir com uma correção ou melhoria, a comunidade deve ter processos para absorver e encaminhar estas questões; • É necessário que a comunidade esteja preparada para atender às múltiplas contribuições em paralelo para vários pedaços ou módulo do software em questão; • Finalmente é preciso ter um processo de adoção de mudanças na distribuição padrão, pois se nenhuma contribuição for incorporada, os participantes podem se sentir discriminados no projeto.

Em um projeto de software livre, este ciclo de discussão, mudança e incorporação de mudanças, por definição não termina nunca, pelo menos enquanto houver o projeto. A técnica mais adotada nos projetos de software livre é a utilização de alguma forma de liderança. Normalmente um líder de projetos é uma pessoa (ou um pequeno grupo de pessoas) que participou da concepção da idéia ou de sua implementação inicial e que, principalmente, goza de respeito e reconhecimento por parte dos outros membros da comunidade. O papel desempenhado por um líder em um projeto de software livre pode variar muito porque depende fortemente da pessoa que exerce esta liderança, a começar pela própria definição desta função, referenciada por diversos nomes como “chefe”, “arquiteto-chefe”, “mantenedor”, “coordenador”, etc. Em linhas gerais o líder provê direção e coerência para o projeto, resolve eventuais disputas e mantém o controle da distribuição padrão, diferenciando-se assim de um ambiente corporativo tradicional, cuja liderança normalmente está inserida em um contexto hierárquico de uma “cadeia de comando”. Outra técnica muito disseminada na organização de processos colaborativos de software livre diz respeito ao framework do projeto em si, que paraleliza a organização da comunidade e a arquitetura do software que está sendo desenvolvido. Entre as estruturas organizacionais típicas temos as decomposições funcionais hierárquicas em módulos fracamente acoplados e um núcleo central com módulos encaixáveis. Um importante objetivo do framework deste tipo é a capacidade que oferece de, dado um problema específico, saber quais as mudanças que serão necessárias e onde precisam ser feitas. A divisão de tarefas, diferente do modelo tradicional, é feita de forma democrática 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 delegação de tarefas visando evitar conflitos e que normalmente é explicitada através de uma lista de participantes e de subprojetos ativos, criando uma percepção 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 documentação ou interfaces), ainda que sejam importantes. Um conceito implícito do software livre que tem profundas implicações no processo colaborativo é o compartilhamento de informações. Qualquer um pode ter acesso, ler ou modificar qualquer código fonte no sistema. Este caráter público do código cria uma espécie de pressão social que motiva a produção de código de qualidade, pois todos os participantes querem que suas contribuições sejam reconhecidamente positivas para a comunidade (AOKI et al., 2001). Mudanças 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 críticas ou mudanças em um pedaço de código podem ser interpretadas como uma crítica pessoal. A submissão não só de erros e críticas, mas de correções e sugestões é importante para o desenvolvimento de uma comunidade (PAVLICEK, 2000). 2.4 As Tecnologias Colaborativas As tecnologias colaborativas desempenham duas atividades essenciais ao processo de construção cooperativa. A primeira é dar aos participantes um canal de comunicação entre si e a segunda fornece mecanismos de armazenamento, distribuição e acompanhamento de versões de objetos produzidos pela comunidade. Ambas as atividades podem se basear em ferramentas síncronas ou assíncronas e de forma independente da sofisticação técnica e das questões temporais, ou seja, podem ser realizadas por contato físico face-a-face, videoconferência, batepapo eletrônico, cartas postais, etc..

2.4.1 Comunicação 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 país, as dificuldades de agendar reuniões com presença física são consideráveis, porém quando os participantes se encontram fisicamente, estas reuniões são tão importantes quanto qualquer outra tecnologia colaborativa (LANCASHIRE, 2001). A Internet é um elemento indispensável na criação e desenvolvimento de projetos de software livre. Como os projetos de software livre tiveram sua origem e disseminação em paralelo com origem e disseminação da própria Internet, as principais tecnologias colaborativas utilizadas passam pelas ferramentas disponíveis nessa rede. Sobre esse aspecto Yamauchi (2000) oferece uma visão geral dos mecanismos de comunicação usados em projetos de software livre e afirma que, apesar da tendência acadêmica da pesquisa em CSCW apontar para a produção de ferramentas complexas para suportar trabalho cooperativo desta natureza, os projetos de software livre sobrevivem e comprovam a eficácia do uso de ferramentas e meios de comunicação simples e disponíveis há muito tempo na Internet, como o email, as listas de distribuição, os newsgroups, os chats e os sites repositórios de conteúdo. Os canais de comunicação baseados na Internet são relativamente baratos (quando comparadas às ligações telefônicas internacionais, reuniões com presença física e videoconferência por satélites) e aqueles com características assíncronas são importantes para minimizar o problema das fronteiras geográficas e dos fusos horários, especialmente na coordenação 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 versões e erros Os mecanismos de armazenamento, distribuição e acompanhamento de objetos produzidos pela comunidade também utilizam ferramentas disponíveis na Internet. A distribuição padrão normalmente é disponibilizada em website conhecido, que funciona como repositório daquela versão (estática) até que seja substituída por outra mais nova. Cada vez mais projetos de software livre estão adotando ferramentas de controle de versão para gerenciamento do conteúdo do objeto produzido. Essas ferramentas são vistas como uma extensão natural do processo de desenvolvimento, permitindo que se possam realizar modificações paralelas de forma coerente e padronizada, através de um mecanismo automatizado para identificar e controlar as modificações realizadas nos arquivos de um projeto ao longo do tempo, garantindo a integridade e a rastreabilidade das modificações. Para enviar as modificações feitas em um objeto, um participante não precisa enviar todo o conjunto de arquivos, pois as ferramentas específicas normalmente extraem a diferença 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 modificações e gerar a nova versão. Esse recurso é importante na economia do uso da rede, pois os arquivos com as diferenças normalmente são substancialmente menores do que as versões completas dos arquivos. Existem diversas ferramentas em uso nos projetos de software livre, como BitKeeper8, Subversion9 e Revision Control System (RCS10), porém a mais utilizada atualmente é a Concurrent Versions System (CVS11), um software (livre) relativamente simples, que foi

8

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 construção cooperativa, seja de códigos fonte, documentação, arquivos de configuração, etc. O CVS surgiu em 1986 como uma coleção de scripts para melhorar o RCS e depois se transformou em uma ferramenta própria, que funciona segundo o modelo copy-modify-merge (copia-modifica-integra) que, baseado no trabalho off-line, permite que múltiplos participantes efetuem, de forma independente, alterações em suas cópias locais do objeto, uma vez que não utiliza mecanismos de exclusão mútua. A seguir estão apresentados os principais aspectos do fluxo de trabalho do CVS, extraído de Reis (2001):

Fig. 2. Diagrama de fluxo de trabalho com o uso do CVS (REIS, 2001). • Repositório: Consiste em um conjunto de arquivos mantido em um local central (normalmente um servidor conectado à Internet, que permita acesso anônimo). Opera, principalmente, segundo um modelo de incrementos, ou seja, armazena as cópias mais atuais dos arquivos do projeto, e as diferenças entre esta e as versões anteriores. • Cópia Local: Qualquer participante interessado solicita ao servidor, através de uma ferramenta front-end, uma cópia do objeto em uma determinada versão desejada. Uma vez criada esta cópia local, também chamada de sandbox, o participante tem acesso total aos arquivos que deseja trabalhar e pode aplicar suas modificações. O participante pode sempre solicitar ao servidor uma atualização de sua base de objeto local, recebendo as alterações que foram integradas ao repositório principal após a criação da sua cópia local. • Integração: Ao alterar o código, o participante está livre de qualquer interação com o repositório e quando julgar que sua versão alterada está pronta para ser integrada à base principal, usa a ferramenta front-end para submeter o objeto de volta ao repositório central. A esta ação de integração é dado o nome de checkin ou merge. • Resolução de conflitos: Se múltiplos participantes alteram o mesmo trecho de um objeto, conceitualmente ocorre um conflito. O processo de resolução de conflitos é feito da seguinte forma: O primeiro participante a integrar um objeto ignora, a princípio, o fato de que outros estejam trabalhando no mesmo trecho. Cada participante subseqüente que iniciar uma ação de merge receberá do repositório a mensagem de que precisa atualizar a sua versão local (já que

uma integração no mesmo arquivo foi feita pelo primeiro participante). Neste momento, ao atualizar a cópia local a ferramenta irá informar que houve alterações provindas do repositório no mesmo trecho de código alterado localmente. Estes trechos do código são marcados com indicadores que diferenciam a versão do repositório da versão local. O participante precisa analisar com cuidado as alterações e decidir de que forma o código deve ficar; ele pode resolver o conflito removendo uma das versões, mas freqüentemente a opção correta é integrar mudanças de ambas as versões num novo trecho único. • Versões: Cada arquivo modificado no repositório recebe uma versão numérica. É possível criar aliases (apelidos) que abstraiam as versões de um conjunto de arquivos em um determinado instante do tempo. Com isso, é possível reverter alterações de arquivos individuais para versões anteriores, e também regenerar uma versão completa do repositório em um determinado momento. Do ponto de vista do participante, o CVS permite que se comparem facilmente as alterações feitas na sua cópia local com qualquer versão integrada no repositório, e torna possível reverter alterações integradas no repositório central para versões anteriores. Este último recurso é normalmente utilizado para remover alterações problemáticas que tenham causado algum um defeito ou regressão funcional no objeto produzido. • Branches: Além das versões alternativas da base de objeto principal, o CVS permite que se crie uma linha de versões paralelas à principal. Resumidamente, é estabelecido um branch (bifurcação) a partir do código principal, chamado trunk (tronco). Alterações integradas sobre este branch são isoladas, não refletindo no tronco. É possível criar um número arbitrário de branches e cada um deles terá um nome simbólico, que o participante especifica ao usar a ferramenta. Eventualmente alterações de um branch podem ser “aplicadas” no trunk principal. Esta operação tem o nome de merge (incorporação). É prática comum, entre os projetos de software livre, manter branches estáveis conforme apresentado a seguir:

Fig. 3 No exemplo acima, o branch estável foi criado logo após o lançamento da versão 0.9, e mantido separado da versão principal (head), recebendo apenas reparos de bugs. Duas novas versões estáveis foram lançadas (1.0.1 e 1.0.2). O desenvolvimento e a adição de funcionalidades continuam normalmente na versão principal. (REIS, 2001).

• Branch Estável: Onde tendem a ser integradas apenas correções de erros, ainda que esta regra não seja explícita. Esta versão é tratada de forma especial, e usuários têm expectativas de que entre uma versão e outra do branch estável não ocorram regressões. • Branch Instável: Onde são aceitos tanto reparos de erros quanto adições de funcionalidade. Não há uma garantia de que as versões funcionem de forma confiável, especialmente nas primeiras versões lançadas neste ciclo. Com o passar do tempo, é declarada uma “moratória” à adição de funcionalidades (o chamado feature freeze), e a versão instável passa por um período de estabilização. Ao final deste período, uma versão considerada “estável o suficiente” é batizada de “nova versão estável”, e um novo ciclo se inicia.

Além de manter versões estáveis, branches são utilizados para implementar mudanças que tenham grande impacto sobre a base do objeto. Como visto anteriormente, cada participante trabalha em relativo isolamento, com sua cópia local. Se não existissem branches, a integração de mudanças extensas seria bem difícil, já que por grandes períodos de tempo corre-se o risco de outro participante ter alterado o mesmo trecho. Utilizando um branch, é possível desenvolver a alteração paralelamente, e integrar mudanças no trunk principal de forma incremental. As ferramentas que documentam e controlam os erros encontrados (e suas correções) são muito importantes para qualidade e a produtividade dos projetos de desenvolvimento distribuído de software. Cada erro, informado por um usuário participante, é registrado em um informe individual e cada informe possui um ciclo de vida que vai desde a sua criação, no momento em que é informado, até seu fechamento, quando o erro é reparado no objeto produzido. Essas ferramentas, que normalmente têm interface Web ou via email permitem, em geral, um bom gerenciamento dos erros, com capacidade de localização, confirmação e detecção de erros duplicados ou que não se apliquem à versão 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 alterações do projeto do browser Mozilla13, no qual é usada em todas as etapas do processo de desenvolvimento, desde a definição de funcionalidades até o projeto, implementação e revisão de alterações. O Bugzilla possui, além do registro de informes de erros, funcionalidades de priorização de atendimento, assinalamento de erros aos participantes apropriados, configuração de dependências entre os erros, organização de erros por produto ou componentes e, principalmente, a capacidade de revisão de código, na qual cada informe pode ser vinculado a uma alteração de código provisória, que deve ser revisada e aprovada para integração na base de código principal. Outra ferramenta comumente utilizada é o GNATS14. 2.5 As Inter-relações Nenhum dos componentes deste framework conceitual existe de forma isolada e assim como cada aspecto muda com o tempo, o mesmo acontece com as relações. A seguir estão listadas as inter-relações mais encontradas entre os componentes: 2.5.1 O Uso O objeto produzido em um projeto de software livre é um pedaço de software de computador, que as pessoas irão baixar e usar em um contexto específico. O uso é um tipo de atividade reflexiva, na qual o usuário cria um modelo de percepção das limitações e pontos fortes do software em uso e identifica mudanças e características que acreditam que o software deveria ter para atender suas necessidades e preferências. Quando mais o software estiver relacionado com cotidiano do usuário, principalmente relacionado ao seu trabalho, mais chances existem desse usuário querer contribuir com críticas e sugestões para o desenvolvimento do software. 2.5.2 A Facilitação Social O processo colaborativo emerge dos participantes ao mesmo tempo em que influencia suas ações. A facilitação social é a maneira com que os processos colaborativos encorajam as pessoas a se envolverem no desenvolvimento e evolução do projeto. Por exemplo, o processo colaborativo pode requerer que as pessoas que corrijam erros anexem seus nomes às correções. Em alguns grupos isso pode ser um grande incentivo à correção de erros porque o reconhecimento pessoal e os elogios motivam as pessoas a contribuir cada vez mais. Em outro exemplo, se um líder que precisa aprovar todas as mudanças nunca aceita as sugestões da 12

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

comunidade, seus participantes perceberão que suas contribuições não estão recebendo o devido reconhecimento e poderão abandonar o projeto. Em suma, a facilitação social se refere às reações dos participantes ao contexto social do projeto. 2.5.3 A Facilitação Técnica O processo colaborativo está intimamente relacionado com as tecnologias colaborativas empregadas. Algumas vezes as limitações da tecnologia influenciam no processo colaborativo em si. Por exemplo, as equipes que dependem da comunicação por email, muitas vezes têm dificuldade de encontrar mensagens importantes devido ao volume e a inerente falta de estrutura dos sistemas de correio eletrônico. Para compensar essa deficiência, o processo colaborativo pode especificar que quando a palavra “ANNOUNCE” aparece entre colchetes no início do assunto da mensagem, significa que se trata de um anúncio importante e que todos devem ler. Em alguns grupos são criados filtros automáticos que varrem as mensagens em busca dos identificadores de anúncios importantes que, uma vez identificados, são imediatamente postados em uma página de anúncios no website do grupo. Neste caso uma tecnologia colaborativa foi adaptada para reforçar um processo colaborativo de divulgação de anúncios importantes. A facilitação técnica se refere às conexões entre os processos colaborativos e as tecnologias que suportam esses processos. 2.5.4 Gerenciamento das Mudanças O gerenciamento das mudanças está relacionado ao uso das tecnologias de comunicação, armazenamento e controle de versões e de erros da distribuição padrão. Como os objetos produzidos devem estar publicamente disponíveis e fáceis de serem acessados, a tecnologia colaborativa deve prover uma maneira confiável de se armazenar e disponibilizar esses objetos. A estrutura dos repositórios da distribuição padrão geralmente reflete as mudanças que ocorreram ao longo do tempo que, junto com os padrões de nomenclatura (numeração de versões) e com as tecnologias de controle de versão e de erros, ajudam no rastreamento das mudanças no objeto produzido, facilitando a volta para uma versão anterior caso problemas sejam encontrados após uma mudança na distribuição padrão. 2.5.5 As Contribuições Contribuição são os processos nos quais os indivíduos propõem melhorias ou extensões no projeto através de mudanças relacionadas à distribuição padrão do objeto produzido. A forma como uma contribuição acontece varia de projeto para projeto, mas certamente envolve todos os aspectos e componentes do framework. Participantes criam mudanças, que passam por alguns processos colaborativos onde o grupo decide aceitar, refinar ou rejeitar as contribuições. Durante esses processos, a tecnologia colaborativa coordena a comunicação e provê o suporte técnico para rastrear as múltiplas versões de uma mudança. Se uma contribuição é aceita, passa então a ser incorporada ao objeto produzido e atualizam-se todas as referências. Assim, apesar das contribuições serem atividades desempenhadas por participantes, são 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 Questão O Linux é um kernel (cerne ou núcleo) de sistema operacional multitarefa preemptivo baseado na Application Program Interface (API) definida pelo padrão 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 análise histórica do desenvolvimento do kernel e coloca claramente a importância do desenvolvimento em comunidade, fornecendo estatísticas históricas da participação de desenvolvedores externos: “ ...em duas semanas do anúncio de Torvalds em Outubro de 1991, 30 pessoas tinham contribuído com cerca de 200 informes de erros, contribuições de utilitários, drivers e melhorias para serem adicionadas ao kernel [...] em Julho de 1995, mais de 15.000 pessoas de 90 países em 5 continentes tinham contribuído com comentários, informes de erro, correções, alterações, reparos e melhorias.” (MOON, 2000)

O primeiro release da primeira versão do kernel possuía um pouco mais de três mil linhas de código, distribuídas em 88 arquivos escritos em linguagens C e Assembly. Atualmente o kernel está no release 6 da versão 2, cujo tamanho ultrapassa a quantidade de dois milhões e meio de linhas de código, distribuídos entre milhares de arquivos. O kernel fica disponível na Internet16 e uma visão da sua estrutura atual pode ser vista em um mapa disponível no website do projeto Kernel Mapper17 O desenvolvimento do kernel costuma ocorrer em duas séries separadas: uma delas é a de produção, ou estável, cujo segundo número (de release) é sempre par: 2.0.x, 2.2.x, 2.4.x, 2.6.x, etc. A outra série é a de desenvolvimento, que não é garantida para ser utilizada em sistemas em produção, e tem o número de release sempre ímpar: 2.1.x, 2.3.x, 2.5.x etc. Quando a série de desenvolvimento atinge a maturidade, ela muda de numeração e se transforma na nova série de produção (feature freeze), e uma nova série de desenvolvimento tem início. O terceiro número (x) refere-se ao patch (remendo) de correção em uso na versão. O desenvolvimento do Linux segue a filosofia preconizada por Raymonds (1999) de “Faça releases o quanto antes e libere-os com freqüência. E ouça o que os seus usuários têm a dizer”. O kernel ainda hoje tem em Torvalds seu expoente máximo, que toma as principais decisões e define a filosofia geral do projeto. Entretanto, cada release tem sempre um mantenedor responsável, que aprova cada aperfeiçoamento e garante que não haja versões conflitantes. O primeiro mantenedor do kernel estável foi próprio Linus Torvalds, seguido pelo inglês Alan Cox (versões 2.0 e 2.2), depois pelo brasileiro Marcelo Tosatti (versão 2.4) e hoje pelo inglês Andrew Morton (na atual versão 2.6). Torvalds e Cox continuam responsáveis por supervisionar as versões do kernel que ainda estão 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 disseminação internacional do Linux. A OSDL foi fundada no ano 2000, com sedes nos Estados Unidos e Japão, e é mantida por investimentos de cerca de 50 empresas como Cisco, HP, IBM, Intel e Sun. Posteriormente Cox e Morton também passaram a fazer parte do OSDL. 3.2 Comunicação e Percepção O projeto do desenvolvimento do Linux sempre foi, levando-se em conta o tamanho do objeto produzido e do número de participantes envolvidos, um dos projetos mais minimalistas em relação à infra-estrutura de desenvolvimento. A lista de distribuição de emails linux-kernel mailing list (LKML) é o fórum central de discussão entre os participantes do projeto de desenvolvimento do Linux, incluindo o próprio 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 idéia do que seja o desenvolvimento no modelo “Bazar”, pois apenas em uma semana comum de trabalho é normal alcançar um volume superior a 5 MB de mensagens, sejam relacionadas aos diversos subprojetos em andamento ou a um conjunto de novas idéias ou mesmo às velhas questões recorrentes e suas discussões 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 créditos que sempre acompanha o kernel. Trata-se de um arquivo de texto simples onde o participante inclui suas informações pessoais e principais áreas de contribuição, segundo o seguinte modelo:

Fig. 4 A estrutura do arquivo de créditos do Linux. As informações são colocadas pelos próprios participantes, mas precisam ser aceitas pelos mantenedores do kernel (TUOMI, 2004). Ainda que não haja uma hierarquia definida e que todos trabalham de acordo com interesses e aptidões pessoais, sabe-se que entre Torvalds e a comunidade de participantes existe um grupo de consultores técnicos, informalmente chamados de “lieutenants” (“tenentes”), que são participantes que ganharam o status de programadores competentes e com expertise de comprovada importância para o projeto através de anos de participação. Apesar desse grupo não existir de maneira formal, sua composição é aceita pela comunidade como uma espécie de “seleção natural”, ainda que as informações e opiniões sobre quem faz (ou deveria fazer) parte do grupo divergem entre os participantes do projeto (KUWABARA, 2000).

Fig. 5 A estrutura do Linux mostrada através do fluxo de informações.

Esta estrutura mostra que os “lieutenants" representam uma espécie de suporte da cadeia de valor e não uma camada, pois os participantes podem interagir diretamente com Torvalds. Trata-se de uma estrutura em rede, na qual todos os participantes têm acesso a todos os nós do sistema. O fluxo da informação também abrange toda a rede, uma vez que toda a comunicação se da através da lista de distribuição 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 documentação de perguntas e respostas mais freqüentes (LKML FAQ19), que nesse caso, entre suas questões principais, esclarece algumas regras implícitas 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 inglês!; Não coloque mensagens em formato HTML, apenas em modo texto; Se você usa outro sistema operacional, esteja seguro de que seu programa de email não usa Charset="Windows*" ou suas mensagens serão bloqueadas; Se for fazer uma pergunta, antes procure ver se já não há uma resposta na documentação 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 alguém que já respondeu a mesma pergunta uma dúzia de vezes. Seja preciso, claro e conciso ao fazer uma pergunta, comentário, anúncio de bug, sugestão de correção ou qualquer outra coisa. Coloque fatos, evite opiniões. Seja gentil, não há necessidade em ser rude. Evite expressões que possam ser interpretadas como agressivas em relação aos outros participantes da lista, mesmo que o assunto tratado seja controverso ou particularmente relevante para você; Não se arraste em controvérsias. Não tente impor a última palavra. Você até poderá ter a última palavra, mas certamente terá perdido toda sua simpatia; Uma linha de código vale mais do que mil palavras. Se está pensando em uma nova funcionalidade, implemente-a primeiro e só depois coloque-a na lista para comentários; É fácil criticar o código dos outros, mas quando se escreve código pela primeira vez não é fácil. Se você encontrar um erro ou alguma coisa que possa ser melhorada, não coloque imediatamente uma mensagem do tipo “Este pedaço de código é um lixo, como foi parar dentro do kernel?” Ao invés disso, entre em contato com o autor do código, explique a questão e faça o entender de uma maneira simples e humilde. Faça isso algumas vezes e será reconhecido como um bom depurador de códigos. E quando escrever o seu pedaço de código, os outros irão prestar atenção no que fez; Não se aborreça e responda com veemência os iniciantes que fazem perguntas erradas. Isso aumenta o ruído na lista. Envie-os um email privado apontando a fonte da informação que procuram (por exemplo, esta FAQ); Não coloque nenhuma mensagem religiosa ou política, inclusive em sua assinatura de email. Ao fazer isso no corpo da mensagem as pessoas irão se aborrecer, pois é um assunto fora do objetivo da lista, além do desperdício de uso da banda de rede (lembre-se que apesar de estarmos no século 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 sério, limite-se aos assuntos técnicos.

Apesar de ser um projeto virtual, com participantes espalhados ao redor do mundo, a comunidade de desenvolvimento do Linux se reúne pessoalmente em eventos anuais informais como o Kernel Summit20 para trocar experiências, combinar as agendas e próximos passos.

19 20

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

3.3 Controle de Versões e Erros O projeto do desenvolvimento do Linux sempre foi, levando-se em conta o tamanho do objeto produzido e do número de participantes envolvidos, um dos projetos mais minimalistas em relação à infra-estrutura de desenvolvimento. Até a versão 2.4, incrivelmente, apenas listas de discussão e emails eram utilizadas por sua comunidade de desenvolvimento. No de final de 2002, no entanto, foi lançado o Kernel Bug Tracker21 sistema para controle de erros, baseado na ferramenta Bugzilla. Este sistema está hospedado em um website no OSDL, com a administração do banco de dados de erros sendo realizada pela IBM. Outro recente projeto importante na manutenção da qualidade é o Kernel Janitor22, que objetiva “limpar” constantemente o código-fonte do kernel através da busca e eliminação de erros em trechos antigos através do reaproveitamento de correções recentes, originalmente feitas para outros trechos do código do kernel. A implantação de uma ferramenta automática de controle de versão (e integração) do objeto produzido ainda demorou a acontecer no Linux, pois Torvalds sempre se opôs à idéia, uma vez que somente confiava tal tarefa aos mantenedores credenciados (SHAIKH, 2003). Com o número, cada vez maior, de mudanças sugeridas pelos participantes, entretanto, o projeto precisou adotar uma ferramenta de controle de versões. 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 polêmica, com discussões dentro (e fora) da comunidade pois, ao contrário do CVS, o BitKeeper não possuía a licença de uso segundo os conceitos de software livre preconizados pela GPL (SHAIKH, 2003). Ideologias à parte, o controle de versões 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 mudanças no código do kernel, efetuadas por mais de 550 participantes (SEARLS, 2003). No início de 2005, entretanto, o próprio Linus Torvalds começou o desenvolvimento de uma nova ferramenta, chamada Git24, que foi disponibilizada sob a GPL e passou a ser a ferramenta usada na manutenção do kernel, sendo hoje também aplicada em outros projetos de software.

3.2 A Padronização das Distribuições do Linux Nos primeiros anos de existência do Linux, Torvalds simplesmente disponibilizava a versão estável do kernel e alguns comandos bem básicos. O usuário interessado em usar o sistema, entretanto, tinha que, além do baixar o kernel pela Internet, também arranjar todos os demais programas complementares, compilar tudo e acertar os arquivos de configuração para então poder proceder com a instalação. Como isso é trabalhoso até mesmo para um hacker iniciado no assunto, surgiram as distribuições, baseadas na idéia de se disponibilizar os programas principais pré-compilados, de tal forma que o usuário só precisasse pegá-los (em CD-ROM ou via Internet) e instalá-los em sua máquina. Hoje existem dezenas de empresas e instituições, ao redor do mundo, que mantém centenas de distribuições e as principais diferenças entre elas são: • O sistema de empacotamento do software; • A estrutura dos diretórios. Teoricamente todas as distribuições seguem um mesmo padrão, o Filesystem Standard (FSSTND) mas esse padrão é bem relaxado e, especialmente os arquivos de configuração do sistema, são bastante diferentes entre as distribuições; 21

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

• A biblioteca básica libc, que contém funções básicas para o funcionamento do sistema operacional. Quando uma nova versão dessa biblioteca é lançada, algumas distribuições a adotam imediatamente, enquanto outras, mais conservadoras, aguardam um pouco. Nesse meio-tempo, alguns programas podem funcionar em algumas distribuições e não em outras. A diversidade de distribuições de Linux, que foi providencial na disseminação do sistema em seus primeiros anos de vida, teve como conseqüência uma falta de padronização que terminou por criar problemas para a comunidade Linux. Entre outras questões, durante muito tempo era difícil obter versões pré-compiladas de aplicativos, exceto se tivessem sido preparadas especificamente para a distribuição de Linux que o usuário estivesse utilizando, o que exigia um conhecimento da instalação de programas a partir da compilação de seu código-fonte, o que se constituía numa grande barreira ao uso e adoção do Linux. Com a entrada de participantes de maior porte no mercado criado em torno do Linux surgiu a necessidade de convergência em torno de um padrão, sem restringir a possibilidade de diferenciação entre as distribuições - mantendo assim a liberdade, sem permitir a fragmentação do Linux em uma série de alternativas incompatíveis 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 padrões para aumentar a compatibilidade entre as distribuições de Linux. O LSB é dividido em três componentes principais: a especificação do sistema, as ferramentas de teste e um exemplo de distribuição para referência. A especificação do sistema define a chamada Binary Application Interface (BIA), que é o ambiente que toda aplicação desenvolvida, levando em conta o LSB, deverá esperar encontrar em qualquer distribuição de Linux, incluindo o nome e localização dos arquivos, versão das bibliotecas, e diversos outros fatores. Apesar do padrão LSB ter sido adotado pelos principais participantes do mercado Linux, incluindo as principais distribuições, os desenvolvedores de aplicativos e as empresas de suporte, ainda é possível encontrar aplicações que somente funcionam em determinadas distribuições do Linux. Os esforços de padronização são coordenados pelo Free Standards Group (FSG26), que além de cuidar do LSB, também promove outros padrões do Linux relacionados à internacionalização, clusterização, impressão, etc. 3.3 O Projeto de Documentação do Linux Visando diminuir a barreira de entrada do uso do Linux através da disponibilização de informações para facilitação do uso, surgiu o Linux Documentation Project (LDP27), um projeto cujo foco está na produção de documentação padronizada do Linux. Existem quatro tipos de objetos produzidos no LDP: • Guias, que são livros com informação detalhada e aprofundada do sistema, segundo um referencial variado (guia usuário, do programador, do administrador do sistema, etc.); • HOWTOs, que são como “receitas de bolo” para execução de tarefas comuns no uso do sistema, como a instalação, gerenciamento de caixas postais, habilitação de recursos de segurança, etc; • Man pages, que são as páginas do manual on-line, que contém informações a respeito dos programas, funções e utilitários 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 são as perguntas e respostas mais comuns colecionadas ao longo da existência do projeto e que são divididas em categorias específicas (Linux, projeto LDP, intgração com outros sistemas operacionais, etc.) Além dos objetos descritos acima, o LDP coordena a tradução do conteúdo produzido para dezenas de idiomas, inclusive o português do Brasil, onde utiliza um vocabulário padronizado com milhares de entradas (entre termos simples, frases-exemplo reais e acrônimos). Os termos e suas traduções foram obtidos de outros glossários em papel, web, e termos discutidos (em várias listas de discussão) quando da tradução de outros livros e programas (ou seja, a experiência de inúmeros tradutores).

4 Desafios para o Software Livre O software livre vem ganhando espaço sistematicamente no cenário mundial e talvez esse interesse esteja crescendo mais rápido do que a consciência sobre a filosofia na qual é baseado, e isto pode conduzir a problemas. Como já foi dito na introdução deste texto, trata-se de um assunto multifacetado, que contém questões relacionadas a diversos assuntos (engenharia de software, propriedade intelectual, etc.). Do ponto de vista dos aspectos relacionados à construção cooperativa, Rothfuss (2002) indica que esses fatores são decorrentes, principalmente, da falta de organização formal, e podem ser resumidos conforme a seguir: 4.1 Redundância de Esforços A coordenação 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. Não há dúvida que o efeito colateral benéfico disso é o aumento do número de opções 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 usuários, o que pode terminar em conflitos de posicionamento no mercado, gerando discussões apaixonadas, quase religiosas, com potencial de provocar “rachas” e enfraquecer o movimento de disseminação do software livre. 4.2 Problemas de Comunicação Ainda que o inglês seja o principal idioma usado nos projetos de software livre, certamente não é o idioma nativo de todos os participantes. Isso pode acarretar em diversos problemas de entendimento, que tendem a piorar conforme os projetos aumentem de número de participantes ao redor do mundo. Outro problema de comunicação, que também está relacionado à expansão, diz respeito ao volume e à relevância do conteúdo das mensagens, que ainda são a base da comunicação dos grupos de desenvolvimento. É comum perceber em grupos de discussão, cada vez mais, os participantes reclamando da falta de etiqueta e boas maneiras em meio a uma profusão de informações inúteis. Isso certamente é menor nos grupos moderados, mas é inegável que a relação sinal-ruído na Internet não é das melhores atualmente e está piorando cada vez mais. 4.3 Senso de Prioridade Em projetos de software livre, dificilmente as decisões importantes e profundas são tomadas com a agilidade necessária. Isso acontece devido à natureza distribuída do processo, que aliada a uma liderança tênue, pode impossibilitar a resolução de uma prioridade ou distorcê-la em direção às tendências pessoais de algum participante influenciador. Uma necessidade de

mudança mais profunda normalmente desencadeia uma seqüência interminável de argumentos favoráveis e contrários, uma vez que ninguém pode forçar sua opinião aos demais e todos se sentem no direito de opinar, mesmo aqueles que não têm o conhecimento ou a preparação necessária para analisar suas considerações à luz de outras questões. 4.4 Proliferação de “grupos fechados” Os projetos de software livre não têm regras formais ou convenções escritas. As relações entre seus participantes são regidas por um conjunto de regras consuetudinárias – não escritas, baseadas em costumes – criando uma “netiqueta” (regras de etiqueta na Internet). Dessa forma, os novos membros têm que gradualmente aprender as regras informais e, de certa forma, são medidos pelo sucesso em reagir às dicas passadas pelo grupo. As comunidades, principalmente as mais antigas, são entrosadas e conseguem melhorar a comunicação entre os membros através do compartilhamento de contextos culturais, porém acabam por dificultar ainda mais a integração do grupo com os recém chegados. À medida que os participantes competem por atenção e reconhecimento de talento, essas barreiras são 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 equilíbrio é importante. Edwards (2000) chamou este fenômeno de “Comunidades Epistêmicas”. 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 são, em sua maioria, gastas durante à noite ou nos finais de semana (BERLECON, 2002). O baixo nível de participação pode introduzir problemas de comunicação, dado que muitos participantes têm dificuldade em acompanhar todos os desenvolvimentos realizados no projeto. Essas circunstâncias certamente dificultam o foco dos participantes no desenvolvimento do projeto. Normalmente o trabalho é conduzido aos pedaços e finalizado apenas após um longo período. O esforço dispensado em estar a par de todas as questões é geralmente tão grande que sobra pouco tempo para as contribuições efetivas. Muitos participantes perdem o interesse ou são absorvidos por outros comprometimentos externos, deixando muitos projetos pela metade. 4.6 Dependência de Pessoas-Chave Muitos projetos de software livre dependem de poucas pessoas. Taurion (2004) afirma que 10% dos participantes contribuem com 78% do código; o segundo décimo, com 12%, o terceiro, com 3%; os outros, com menos de 1% cada. Existem algumas explicações plausíveis para este fenômeno. A mais óbvia é que o nível de conhecimento necessário para se analisar e entender um código-fonte de um sistema grande requer treinamento e experiência. O esforço em adquirir este conhecimento não é efetuado pela maioria dos participantes. Outra explicação está relacionada ao nível de reconhecimento que os participantes esperam receber por suas contribuições. Apenas um número pequeno de participantes acaba se tornando amplamente reconhecido por suas contribuições, o que tende a fortalecer ainda mais o papel dos contribuidores principais. Essa dependência pode se tornar um risco se uma pessoa-chave não puder continuar seu trabalho no projeto por algum motivo. Talvez seja impossível reconstruir todo seu conhecimento implícito a partir de seus objetos (código-fonte e documentação).

4.7 Escassez de Lideranças Competentes O sucesso de um projeto de software livre depende de uma boa e carismática liderança. Além das qualidades intrínsecas da perspectiva da Engenharia de Software, o líder de projeto precisa endereçar questões de comunicação, marketing, juízo político e motivação. A liderança normalmente é feita por persuasão, pois não há um mandato oficial hierarquicamente estabelecido. O líder é avaliado não só por seus conhecimentos técnicos, mas por sua visão e habilidade em se comunicar com os co-participantes. (BCG, 2002). Ainda que haja muitos participantes com conhecimentos técnicos, as exigências são tão seletivas que se torna difícil preencher todas as posições de liderança com pessoal qualificado. Raymond (1999) diz que o sucesso do Linux se deve muito mais à excelente liderança exercida por Torvalds do que por suas habilidades técnicas. A escassez de novos e bons líderes é uma questão muito sensível para o futuro dos projetos de software livre, conforme atestado pelo próprio 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 esotéricos da esfera jurídica, principalmente quando aplicada ao software e seus algoritmos. É muito difícil saber se determinado método para se resolver um problema de software já foi patenteado ou não, e a interpretação dessas leis varia conforme o país. Stallman (1999) chegou a afirmar que “A pior ameaça que nós enfrentamos são as patentes de software que podem colocar algoritmos e características fora dos limites do software livre por mais de vinte anos”. Ainda que esse problema exista para todo o mercado de software (livre e proprietário), no modelo de desenvolvimento de software livre, distribuído pelo mundo e sem organização 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 preocupação legal, que também varia conforme o país pode prejudicar o futuro do software livre.

5 Conclusão Este artigo procurou mostrar o modelo de desenvolvimento do software livre através da perspectiva do Trabalho Cooperativo Suportado por Computador. Essa análise ajudou a revelar um pouco mais do contexto no qual software livre está inserido e reforçar o argumento de que esse assunto não pode ser explicado somente por uma disciplina ou visão, mas sim através de um conjunto delas. Através da apresentação de um framework conceitual, complementada com um estudo de caso do desenvolvimento do Linux, foram apresentados os principais elementos e inter-relações que existem em um projeto típico, com participantes, processos, ferramentas e objetos produzidos em um modelo cooperativo de trabalho. O estudo mostrou também que o fenômeno do software livre, apesar de ainda estar em formação, vem crescendo bastante nos últimos anos e que sua expansão (e futuro) dependem da estabilização de alguns fatores hoje apresentados como desafios.

28

http://www.osriskmanagement.com/

Referências 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. 524–533). Toronto, Canadá, 2001. BCG, Boston Consulting Group. Hacker Survey release 0.73, 2002. Disponível 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. Disponível 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. Disponível em http://www.firstmonday.dk/issues/issue6_11/dafermos/ . Visitado em Jan de 2007. DEURZEN, Van. Linux Architectures. 2004. Disponível 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. 42–43, abr 1999. GANCARZ, M. UNIX Philosophy. Prentice-Hall, 1995. HEXSEL, Roberto, Propostas de Ações de Governo para Incentivar o Uso de Software Livre, Relatório Técnico do Departamento de Informática 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. Disponível 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. Disponível em http://firstmonday.org/issues/issue6_12/lancashire/ . Visitado em Jan de 2007.

MAÇADA, D. L. TIJIBOY, A.V. Aprendizagem Cooperativa em Ambientes Telemáticos. In: Congresso Ibero-Americano de Informática na Educação, IV. Brasília, outubro de 1998. MCKUSICK, M. K. Twenty years of Berkeley UNIX. In: Open Sources. Sebastopol: O’Reilly and Associates, 1ª ed., 1999. p. 31–46. MOON, J., SPROULL, L. Essence of Distributed Work: The Case of Linux Kernel. First Monday. 2000. Disponível 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. Disponível 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. O’Reilly and Associates, 1ª ed., 1999. p. 27–78. REIS, Christian. Caracterização de um Modelo de Processo para Projetos de Software Livre, Instituto de Ciências Matemáticas e de Computação, São Carlos SP, 2001. ROTHFUSS, Gregor. A Framework for Open Source Projects, Universität Zürich, Institut für Informatik, 2002. Disponível 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: O’Reilly and Associates, 1ª. ed., 1999. p. 53–70. SCHENK, Thomas. Linux: Its history and current distributions. Disponível em http://www-106.ibm.com/developerworks/library/it-schenk1/schenk1.html, 2001.Visitado em Jan de 2007. SEARLS, Doc. Linus & the Lunatics. Transcrição de palestra no Linux Lunacy Geek Cruise 2003. Disponível 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, disponível 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 Negócios. Brasport, 2004. TORVALDS, L. The Linux Edge. In: Open Sources. Sebastopol: O’Reilly and Associates, 1ª ed., 1999. p. 101–111.

TUOMI, Ilkka. Evolution of the Linux Credits File: Methodological Challenges and Reference Data for Open Source Research. FirstMonday, 2002 Disponível 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 Definições de termos relacionados ao software livre (HEXSEL, 2002) • BSD: A licença BSD cobre as distribuições de software da Berkeley SoftwareDistribution, além de outros programas. Esta é uma licença considerada 'permissiva' porque impõe poucas restrições sobre a forma de uso, alterações e redistribuição do software licenciado. O software pode ser vendido e não há obrigações quanto à inclusão do código fonte, podendo o mesmo ser incluído em software proprietário. Esta licença garante o crédito aos autores do software, mas não tenta garantir que trabalhos derivados permanecem como software livre. • Copyleft: A maioria das licenças usadas na publicação de software livre permite que os programas sejam modificados e redistribuídos. Estas práticas são geralmente proibidas pela legislação internacional de copyright, que tenta justamente impedir que alterações e cópias sejam efetuadas sem a autorização dos autores. As licenças que acompanham software livre fazem uso da legislação de copyright para impedir utilização não-autorizada, mas estas licenças definem clara e explicitamente as condições sob as quais cópias, modificações e redistribuições podem ser efetuadas, para garantir as liberdades de modificar e redistribuir o software assim licenciado. A esta versão de copyright, dá-se o nome de copyleft. • Debian: A licença Debian é parte do contrato social celebrado entre a Debian e a comunidade de usuários de software livre, e é chamada de Debian Free SoftwareGuidelines (DFSG). Em essência, esta licença contém critérios para a distribuição que incluem, além da exigência da publicação do código fonte. Estes critérios são: (a) a redistribuição deve ser livre; (b) o código fonte deve ser incluído e deve poder ser redistribuído; (c) trabalhos derivados devem poder ser redistribuídos sob a mesma licença do original; (d) pode haver restrições quanto à redistribuição do código fonte, se o original foi modificado; (e) a licença não pode discriminar contra qualquer pessoa ou grupo de pessoas, nem quanto a formas de utilização do software; (f) os direitos outorgados não podem depender da distribuição onde o software se encontra; e (g) a licença não pode 'contaminar' outro software. • Freeware: O termo freeware não possui uma definição amplamente aceita mas é usado com programas que permitem a redistribuição mas não a modificação, e seu código fonte não é disponibilizado. Estes programas não são software livre. •

GPL: A Licença Pública Geral GNU (GNU General Public License) é a licença que acompanha os pacotes distribuídos pelo Projeto GNU, e mais uma grande variedade de software, incluindo o kernel do sistema operacional Linux. A formulação da GPL é tal que ao invés de limitar a distribuição do software por ela protegido, ela de fato impede que este software seja integrado em software proprietário. A GPL é baseada na legislação internacional de copyright.

• Open Source: A licença da Open Source Initiative é derivada da Licença Debian, com as menções à Debian removidas. • Shareware: É o software disponibilizado com a permissão para que seja redistribuído, mas a sua utilização implica no pagamento pela sua licença. Geralmente, o código fonte não é disponibilizado e portanto modificações são impossíveis. • Software Comercial: É o software desenvolvido por uma empresa com o objetivo de lucrar com sua utilização. Note que 'comercial' e 'proprietário' não são o mesmo. A maioria do software comercial é proprietário mas existe software livre que é comercial, e existe software não-livre não-comercial.

• Software em Domínio Público: É o software sem copyright. Alguns tipos de cópia, ou versões modificadas, podem não ser livres porque o autor permite que restrições adicionais sejam impostas na redistribuição do original ou de trabalhos derivados. • Software Livre (Free Software): É o software disponível com a permissão para qualquer um usá-lo, copiá-lo, e distribuí-lo, seja na sua forma original ou com modificações, seja gratuitamente ou com custo. Em especial, a possibilidade de modificações implica em que o código fonte esteja disponível. Se um programa é livre, potencialmente ele pode ser incluído em um sistema operacional também livre. E importante não confundir software livre com software grátis porque a liberdade associada ao software livre de copiar, modificar e redistribuir independe de gratuidade. Existem programas que podem ser obtidos gratuitamente, mas que não podem ser modificados, nem redistribuídos. Por outro lado, existe a possibilidade de uso não-gratuito em todas as categorias listadas no que segue. Há uma cópia da definição de software livre pela Free SoftwareFoundation publicada na página http://www.fsf.org/philosophy/free-sw.pt.html • Software Proprietário: É aquele cuja cópia, redistribuição ou modificação são em alguma medida proibidos pelo seu proprietário. Para usar, copiar ou redistribuir, deve-se solicitar permissão ao proprietário, ou pagar para poder fazê-lo. • Software Semi-livre: É software que não é livre, mas é concedida a permissão para que indivíduos o usem, copiem, distribuam e modifiquem, incluindo a distribuição de versões modificadas, desde que o façam sem o propósito de auferir lucros. Exemplos de software semi-livre são as primeiras versões do Internet Explorer da Microsoft, algumas versões dos browsers da Netscape, e o StarOffice. • X.org: O Consórcio X distribui o X Window System sob uma licença que o faz software livre mas não adere ao copyleft. Existem distribuições sob a licença da X.org que são software livre, e outras distribuições não o são. Existem algumas versões não-livres do sistema de janelas X11 para estações de trabalho e certos dispositivos do IBM-PC que são as únicas funcionais disponíveis, sem similares distribuídos como software livre.