Desenvolvimento de software livre é o processo pelo qual software livre (ou software similar, cujo código-fonte está disponível ao público) é desenvolvido. Estes são produtos de software “disponíveis com seu código-fonte e sob uma licença de software livre para estudar, mudar e melhorar o seu projeto”. Exemplos populares de software livre são os navegadores Mozilla Firefox e Google Chromium, o sistema operacional Android e o conjunto de aplicativos LibreOffice substituto do OpenOffice.org.

Em 1997, Eric S. Raymond escreveu A Catedral e o Bazar^[1]. Neste livro, Raymond faz a distinção entre dois tipos de desenvolvimento de software. O primeiro é o desenvolvimento convencional de código proprietário (fechado). Estes métodos de desenvolvimento são, de acordo com Raymond, como a construção de uma catedral: planejamento centralizado, organização apertada e um processo do início ao fim. O segundo é o desenvolvimento de software livre, que é mais como um "um grande bazar de diferentes agendas e abordagens, dos quais um sistema coerente e estável poderia aparentemente emergir somente por uma sucessão de milagres". Em alguns projetos, qualquer pessoa pode enviar sugestões e discutí-las. O termo "sistemas coerentes e estáveis", que Raymond menciona, surge muitas vezes a partir de projetos de desenvolvimento de software livre.

Diferenças entre os dois estilos de desenvolvimento, de acordo com Bar & Fogel^[2], são, em geral, o tratamento (e criação) de relatórios de bugs e solicitações de novas funcionalidades, e as restrições sob as quais os programadores estão trabalhando. No desenvolvimento de software proprietário, os programadores estão muitas vezes gastando muito tempo criando e lidando com relatórios de bugs, bem como solicitações de novas funcionalidades. Este tempo é gasto na priorização e criação de planos de desenvolvimento. Isto leva a equipe (ou parte da equipe) de desenvolvimento a gastar muito tempo com estas questões, e não no desenvolvimento do software em si. Também, em projetos de código proprietário, as equipes de desenvolvimento devem muitas vezes trabalhar sob restrições de gestão relacionadas com prazos e orçamentos, que interferem em questões técnicas do software. No desenvolvimento de software livre, essas questões são resolvidas por meio da integração dos usuários do software no processo de desenvolvimento, ou até mesmo deixar que esses usuários construam o sistema por si mesmos.

Existem vários tipos diferentes de projetos de software livre. Primeiro, existe uma variedade de programas de software e bibliotecas. Eles são pedaços autônomos de código-fonte. Alguns podem ser até dependentes de outros projetos de software livre. Esses projetos servem para um propósito especifico, para preencher uma necessidade bem definida. Exemplos deste tipo de projeto incluem o Kernel do Linux, o navegador web Firefox e o conjunto de aplicativos LibreOffice.

Distribuições são um outro tipo de projeto de software livre. Distribuições são coleções de software que são publicadas a partir de uma mesma fonte, com um propósito comum. O exemplo mais proeminente de uma "distribuição" é um sistema operacional. Há um grande número de distribuições Linux (como Debian, Fedora, Mandriva, Slackware, Ubuntu, entre outros) que distribuem o kernel do Linux, juntamente com muitos outros componentes. Há também outras distribuições, como o Perl (linguagem de programação) para vários sistemas operacionais, e até mesmo o OpenCD e cygwin, distribuições de software livre para Microsoft Windows.

Outros projetos de software livre, como os derivados do Berkeley Software Distribution, mantém o código-fonte de um sistema operacional completo, o kernel e todos os componentes do seu núcleo, em um sistema de versionamento, desenvolvendo o sistema todo em conjunto como uma única equipe. Esses projetos de desenvolvimento de sistemas operacionais tem uma grande integração de suas ferramentas, mais do que em outros sistemas baseados em distribuições.

Finalmente, existem os projetos isolados. Esses projetos geralmente não são fornecidos como parte de um pacote de software livre. O Linux Documentation Project hospeda muitos desses projetos que documentam vários aspectos do sistema operacional GNU/Linux. Há muitos outros exemplos deste tipo de projeto de software livre.

Existem várias maneiras pelas quais um projeto de software livre podem começar:

1. Um indivíduo que sente a necessidade de um projeto anuncia a intenção de desenvolver o projeto em público. O indivíduo pode receber ofertas de ajuda de outros. O grupo pode então trabalhar no desenvolvimento do software.
2. Um desenvolvedor trabalhando em um projeto inicial, tendo por base códigos fontes limitados, porém funcionais e de sua autoria, pode liberar o código-fonte ao público como uma primeira versão de um software livre. O desenvolvedor continua a trabalhar para melhorá-lo e, possivelmente, é acompanhado por outros desenvolvedores que se engajam no projeto.
3. O código-fonte de um projeto consolidado é liberado ao público, depois de ter sido desenvolvido como software proprietário.
4. Um projeto de software livre com uma estrutura bem estabelecida pode permitir que ramificações sejam feitas por uma parte externa interessada. Vários desenvolvedores podem então iniciar um novo projeto, cujo código-fonte toma outros rumos diferentes do original.

Eric Raymond observa em seu famoso ensaio "The Cathedral and the Bazaar", que o anúncio da intenção de se desenvolver um projeto é geralmente menos impactante do que o lançamento de um projeto em funcionamento para o público.

É um erro comum iniciar um novo projeto quando contribuir para um projeto semelhante existente seria mais eficaz. Para iniciar um projeto de sucesso é muito importante investigar o que já existe de semelhante ao novo projeto.

É difícil executar um projeto de software livre seguindo um método mais tradicional de desenvolvimento de software, como o Modelo Cascata, uma vez que nestes métodos tradicionais, a volta a fases anteriores é complicada. No desenvolvimento de software livre os requisitos raramente são reunidos antes do início do projeto; em vez disso eles são normalmente baseados em versões preliminares do software, como descreve Robbins ^[3]. Além dos requisitos, muitas vezes pessoal voluntário é atraído para ajudar a desenvolver o software com base nas primeiras versões lançadas. Este efeito de rede é essencial segundo a Abrahamsson et al. ^[4]: "Se protótipo apresentado consegue reunir atenção suficiente, ele irá gradativamente começar a atrair mais e mais desenvolvedores". No entanto, Abrahamsson et al. também apontam que a comunidade é muito crítica, muito parecida com o mundo dos negócios de software proprietário: "se você encontrar os clientes você sobrevive, mas sem os clientes você morre".

Alfonso Fuggetta menciona ^[5] que "prototipagem rápida, desenvolvimento incremental e evolutivo, espiral de ciclo de vida, o desenvolvimento rápido de aplicativos e, recentemente, a programação extrema e o processo ágil de software podem ser igualmente aplicados ao software livre e proprietário". Um método de desenvolvimento de código aberto mencionados por Fuggetta são os métodos ágeis, dentre eles, a Programação Extrema mais conhecida como XP. Métodos ágeis são essencialmente aplicáveis ao desenvolvimento de software livre, por causa de seu caráter iterativo e incremental.

Outro método ágil, o Internet-Speed Development, também é adequado para o desenvolvimento de software livre, em especial pelo desenvolvimento distribuído que o método adota. O Internet-Speed Development pode ser usado em equipes geograficamente distribuídas para trabalhar contra o relógio. Este método é especialmente adotado pelas grandes empresas de código proprietário como a Microsoft, uma vez que só grandes empresas de software são capazes de criar centros de desenvolvimento distribuídos em diferentes fusos horários. É claro que se o software é desenvolvido por um grande grupo de voluntários de diferentes países, isto será conseguido de forma natural e sem investimentos extras, como no caso do desenvolvimento de software proprietário.

A relação entre projetos de software livre e métodos ágeis pode ser encontrada na dissertação de Corbucci ^[6]. Corbucci identifica soluções de diversas comunidades apresentando ferramentas e processos de desenvolvimento utilizados. O trabalho também apresenta uma análise da Programação Extrema, do ponto de vista de um modelo de maturidade para ambientes de software livre, o Modelo de Maturidade Aberto (OMM) do projeto QualiPSo ^[7]. OMM é um modelo de processo para o desenvolvimento FLOSS, como é o CMMI. Seu objetivo é auxiliar a construção de confiança nos processos de desenvolvimento de empresas que utilizam ou desenvolvem software livre. Os elementos de confiança estão agrupados em três níveis de maturidade: básico, intermediário e avançado.

Desenvolvedores e usuários de um projeto de software livre não estão todos necessariamente trabalhando próximos. Normalmente, projeto de software livre demandam alguns mecanismos eletrônicos de comunicação. E-mail é uma das formas mais comuns de comunicação entre os desenvolvedores de software livre e os usuários. Muitas vezes, listas de e-mails são usadas para garantir que as mensagens sejam entregues a todos os interessados de uma só vez. Isso garante que os receptores possam responder em privado ou para a lista inteira, dependendo do contexto. A fim de se comunicar em tempo real, muitos projetos usam comunicadores instantâneos como o IRC (embora existam muitos outros disponíveis). Fóruns na web se tornaram recentemente uma forma comum para obtençao de ajuda para usuários com problemas que surgem durante o uso de um software livre. As Wikis também se tornaram um meio de comunicação comum para os desenvolvedores e usuários.

No desenvolvimento de software livre, os participantes, que são em sua maioria voluntários, estão distribuídos entre diferentes regiões geográficas. Por isso há a necessidade de ferramentas para ajudar no desenvolvimento colaborativo do software. Algumas das principais ferramentas de controle de versionamento estão listadas a seguir:

• CVS ou Sistema de Versões Concorrentes é um exemplo de ferramenta de colaboração de código-fonte que já foi muito usada em projetos de software livre. A ferramenta permite que se trabalhe com diversas versões de arquivos organizados em um diretório local ou remoto, mantendo-se versões antigas e logs de quem e quando manipulou os arquivos.
• SVN ou Subversion foi criado para substituir o CVS. Bastante difundido ainda na comunidade de desenvolvimento de software livre. Possui limitações quanto ao seu uso, principalmente relacionados ao desenvolvimento distribuído de software, amplamente difundido nos dias atuais. Portanto não é recomendado a sua utilização, uma vez que existem sistemas de gerenciamento de versão mais modernos como o Git, Bazaar e o Mercurial.
• Git é um sistema de controle de versão distribuído com ênfase em velocidade. O Git foi inicialmente projetado e desenvolvido por Linus Torvalds para o desenvolvimento do kernel do Linux. Cada diretório de trabalho Git é um repositório com todos os históricos, possui habilidade total de controle das revisões, e não é dependente de acesso a uma rede ou a um servidor central.
• Bazaar é um sistema de revisão de versões descentralizado que serve para seguir o processo de evolução de código de software ou informação semelhante. A filosofia de concepção deste programa é dar o máximo de liberdade ao utilizador para fazer as alterações que forem necessárias.
• Mercurial é uma ferramenta multi-plataforma de controle distribuído de versão para desenvolvedores de software. É principalmente um programa de linha de comando. Todas operações do Mercurial são chamadas através de palavras chave de opções para o programa controlador hg, uma referência para o símbolo químico do elemento Mercúrio.

Existe, atualmente, uma tendência de adotar ferramentas modernas como o Git, Bazzar e Mercurial. Muitos projetos de código aberto já estão usando estas ferramentas uma vez que não dependem de repositórios centralizados como o SVN e CVS. Exemplos de uso são Git, usado pelo kernel do Linux, e Mercurial, usado pela linguagem de programação Python.

A maioria dos projetos de grande porte necessitam de um sistema de acompanhamento de bugs (geralmente baseados na Internet) para acompanhar o status de vários problemas no desenvolvimento do projeto. Um arquivo de texto simples não é suficiente, primeiro pela quantidade de bugs a serem registrados, e segundo, porque pretendem facilitar a comunicação e manutenção corretiva de bugs por usuários e desenvolvedores secundários. Alguns Bug Tracker:

• Bugzilla - rastreador de bugs baseado na web desenvolvido pela Mozilla
• Mantis Bug Tracker - rastreador de bugs baseado na web desenvolvido em PHP com suporte ao MySQL e PostgreSQL
• Trac - ferramenra que integra um rastreador de bugs com um wiki, e uma interface para o Subversion
• GNATS - O sistema de rastreamento de bugs da GNU Operating System
• SourceForge e suas ramificações fornecem um rastreador de bugs como parte de seus serviços. Como resultado muitos projetos hospedados no SourceForge.net usam a ferramenta como padrão para o rastreamento de bugs

Como os projetos de software livre convivem com a integração contínua, ferramentas que automatizam os testes durante a integração do sistema devem ser usadas. Ferramentas como o JUnit auxiliam nesta tarefa. O JUnit é um framework livre com suporte à criação de testes automatizados na linguagem de programação Java. Esse framework facilita a criação de código para a automação de testes com apresentação dos resultados. Desta forma os testes verificam se códigos modificados não alteram o funcionamento do sistema de forma indesejada.

Um depurador (debugger) é um programa de computador usado para executar e encontrar possíveis erros no código-fonte. O GNU Debugger (GDB) é um exemplo de um depurador usado no desenvolvimento de software livre. Este depurador oferece depuração remota, o que o torna especialmente aplicável ao desenvolvimento de software livre.

Ferramentas de vazamento de memória (memory leak) são usadas para encontrar vazamentos memória e transbordamento de dados buffer overflow. Um vazamento de memória é um tipo particular de consumo de memória desnecessário por um programa de computador, onde o programa falha ao liberar memória que não é mais necessária.

Ferramentas de validação são usadas para verificar se trechos de código estão em conformidade com a sintaxe especificada. Elas são mais frequentemente utilizadas no contexto de HTML/XML, mas também podem ser usadas com linguagens de programação.

Um sistema de gerenciamento de pacotes é uma coleção de ferramentas para automatizar o processo de instalação, atualização, configuração e remoção de pacotes de software de um computador. O Gerenciador de Pacotes Red Hat (RPM) para arquivos do tipo "rpm" e Advanced Packaging Tool (APT) para arquivos do tipo "deb", são alguns dos diversos sistemas de gestão de pacotes utilizados por distribuições Linux.

Muitas vezes os desenvolvedores de software livre percebem que seu código exige uma reformulação. Isso pode ser porque o código foi escrito ou mantido sem a devida refatoração (como é frequentemente o caso, se o código foi herdado de um desenvolvedor anterior), ou porque uma funcionalidade ou extensão proposta não pode ser implementada inicialmente de maneira razoável com base no código existente. A última razão para desenvolvedores que desejam renovar seu código é a afirmação de Martin Fowler^[8] em seu livro de refatoração dizendo que o código "cheira mal" e não satisfaz os padrões do desenvolvedor.

Existem diversos tipos de melhoria de código:

1. Refatoração implica movimentação de código. Métodos, funções ou classes podem ser extraídos, código duplicado é eliminado e assim por diante - tudo isto mantendo a integridade do código. A Refatoração pode ser feita em pequenas quantidades (a chamada "refatoração contínua") para justificar uma certa mudança, ou pode-se decidir sobre grandes refatorações para um código existente, que podem durar vários dias ou semanas.
2. Reescrita parcial envolve reescrever uma determinada parte do código a partir do zero, mantendo o resto do código. Reescritas parciais têm sido comuns no desenvolvimento do kernel do Linux, onde vários subsistemas foram reescritos ou re-implementados a partir do zero, mantendo o restante do código intacto.
3. Reescrita completa envolve iniciar o projeto a partir do zero, possivelmente, ainda fazendo uso de algum código-fonte antigo. Um bom exemplo de uma reescrita completa foi o sistema de controle de versão Subversion, cujos desenvolvedores começaram a partir do zero: eles acreditavam que a base de código do CVS, era inútil e precisava ser completamente reescrito. Outro bom exemplo de reescrita de código foi a do servidor web Apache, que foi quase completamente re-escrito entre a versão 1.3.x e a versão 2.0.x.

Tradicionalmente, na maior parte do código-fonte aberto, existe uma falta de consciência para testes automatizados, em que são escritos scripts de testes automatizados e programas executam estes testes para tentar descobrir se o código-fonte se comporta corretamente, conforme o esperado. Recentemente, no entanto, essa consciência tem aumentado, possivelmente devido à influência das metodologias de desenvolvimento ágil, como a Programação Extrema. Grande parte do software livre são na verdade ferramentas de comando ou, alternativamente, APIs, facilitando ainda mais o uso de testes automatizados.

Referências