Como um projeto open source é desenvolvido

O código fonte

Antes de tudo, para se ter um software é necessário escrevê-lo em uma linguagem de programação. O código fonte é composto de vários arquivos, normalmente resultado de uma engenharia que permite a sua escrita e manutenção em pequenas unidades de código.

Grande parte dos projetos open source são desenvolvidos nas linguagens C e C++. No entanto, esta não é uma regra. Há milhares de projetos livres em Python, Ruby, Perl, PHP e outras linguagens.

vim
©2008 HowStuffWorks
Arquivo fonte do projeto lighttpd, servidor
web escrito em C, editado no VIM

Ambiente de Compilação e Depuração

Compilar um programa significa traduzir o código fonte em código de máquina. Para isso utilizam-se softwares compiladores, como o gcc e o g++ (GNU C Compiler e GNU C++ Compiler). Porém, projetos grandes costumam ter centenas ou milhares de arquivos fontes, e para que o projeto funcione com tanta gente trabalhando neles é necessário um sistema de compilação automatizado.

Os softwares desenvolvidos em C/C++ normalmente utilizam a suíte de aplicativos de compilação do GNU Build System, conjunto de softwares de linha de comando que “preparam” o código fonte para que funcione em várias plataformas com vários desenvolvedores.

a depuração é o meio pelo qual os desenvolvedores checam se suas partes de código estão funcionando. Pode ser feita manualmente, utilizando softwares como o gdb (GNU debugger), ou em alguns casos utilizando rotinas de testes automatizados que alguns projetos de software open source disponibilizam.

Árvores de código

Para que não haja confusão entre código novo e testado e código em desenvolvimento, a maioria dos projetos separam os códigos fontes em três unidades diferentes: estável, testes e desenvolvimento.

Ciclo de desenvolvimento de um projeto open source
©2008 HowStuffWorks
Ciclo de desenvolvimento de
­­ um projeto open source

­A árvore estável contém apenas código fonte de lançamentos. Isso significa que as únicas alterações que ela irá receber é de bugfixes (correções) de erros encontrados depois do seu lançamento. Nenhuma nova funcionalidade será incluída nesta árvore de código. Essa árvore corresponde à última versão estável liberada para o público e pronta para o uso.

A árvore de testes contém códigos que precisam ser testados (e normalmente reparados, caso ocorram erros). Correspondem às versões beta e não são totalmente seguras. Devem ser usadas apenas para depuração, garantindo estar livre de bugs na próxima versão estável.

A árvo­re de ­desenvolvimento contém código mutável. Nela todos os dias são incluídas novas funcionalidades, e não há garantias de que o software irá funcionar, pois a versão baixada uma hora antes pode ser diferente da versão atual, dependendo do fluxo de desenvolvimento do projeto. Versões de desenvolvimento só são usadas por programadores envolvidos no projeto.

Forks

No mundo do desenvolvimento de software, os forks acontecem quando um programador copia uma árvore de código e nela inicia um desenvolvimento independente, criando um software diferente. As alterações feitas no fork não são aplicadas na árvore de código do primeiro projeto, fazendo com que o software copiado vire um novo software.

Os forks são um recurso muito interessante nos projetos Open Source. Se um time de desenvolvedores resolver não mais liberar o código fonte de algum software, os usuários poderão continuar o desenvolvimento da última versão liberada ao público.

Um exemplo disso é o Mozilla Firefox, que derivou do Mozilla, que por sua vez derivou do código aberto do Netscape Navigator. O OpenBSD surgiu como um fork do NetBSD.

Os Modelos de Desenvolvimento

Softwares Open Source podem ser desenvolvidos de várias maneiras, no entanto há duas formas de desenvolvimento mais utilizados nos projetos abertos:

  • O modelo Catedral e
  • O modelo Bazar

No modelo Catedral, há um time de desenvolvedores eleitos que estão lá por próprio mérito e que conhecem bem os objetivos do projeto e a estrutura de código do software. Nesse modelo, os projetos aceitam contribuições da comunidade em geral através de relatos de falhas (bug reports) ou correções (patches), que são partes de código que alteram o código fonte do software, mas que só irão fazer parte do código fonte principal se forem aceitos pelos desenvolvedores do time.

Para fazer parte do time de desenvolvimento, uma pessoa poderia ser indicada ou mostrar suas habilidades técnicas contribuindo com o projeto, mas sem fazer parte dele.

O modelo de desenvolvimento Catedral pode ser comparado ao desenvolvimento de um software proprietário, com a diferença que o código fonte está lá disponível para os usuários e que eles podem fazer o que bem entenderem (dependendo da licença usada).

no modelo Bazar, usado primeiramente no projeto do kernel Linux, o desenvolvimento é feito de forma totalmente aberta, utilizando a internet, e qualquer pessoa está livre para inserir suas próprias funcionalidades ou remendos. O livro de Eric Raymond, "A Catedral e o Bazar", mostra mais detalhes desses dois estilos de desenvolvimento.