1.1 Público Alvo

Este documento tem como público alvo os seguintes grupos de pessoas:

• Tomadores de decisão em empresas que estejam em busca de meios para melhorar a qualidade de seus produtos, de reduzir o tempo necessário para lançá-los no mercado e de reduzir seus custos de engenharia no longo prazo.

• Consultores de tecnologia procurando as melhores práticas para alavancar projetos de “código aberto”.

• Observadores da indústria interessados em compreender a dinâmica dos projetos de “código aberto”.

• Desenvolvedores de software que utilizam o FreeBSD e que buscam formas de contribuir com o projeto.

1.2 Objetivos do artigo

Após a leitura deste artigo, você deve ter:

• Uma melhor compreensão dos objetivos do Projeto FreeBSD e de sua estrutura organizacional.

• Uma visão geral das tecnologias disponíveis no projeto.

• Uma melhor compreensão do modelo de desenvolvimento adotado pelo Projeto FreeBSD e dos processos de engenharia envolvidos no lançamento de uma nova versão do sistema.

• Uma compreensão de como os processos convencionais de desenvolvimento de software em uma empresa diferem dos processos utilizados no projeto FreeBSD.

• Consciência dos canais de comunicação utilizados pelo projeto e do nível de transparência que você pode esperar.

• Consciência das melhores formas de se trabalhar com o projeto — a melhor forma de reduzir os custos de engenharia, de reduzir o tempo necessário para levar seu produto ao mercado, de gerir vulnerabilidades de segurança, e de preservar a compatibilidade futura com o seu produto a medida que o Projeto FreeBSD evolui.

1.3 Estrutura do Artigo

O restante deste artigo está estruturado da seguinte forma:

• A Seção 2 apresenta o projeto FreeBSD, explora sua estrutura organizacional, as principais tecnologias e processos de engenharia envolvidos no lançamento de uma nova versão do sistema.

• A Seção 3 descreve formas de colaborar com o Projeto FreeBSD. Esta seção também aborda as armadilhas que são geralmente encontradas por empresas que trabalham com projetos voluntários como o FreeBSD.

• A Seção 4 conclui o artigo.

2.1 Construindo com o FreeBSD

Aqui estão alguns exemplos de como as empresas estão utilizando o FreeBSD:

• Como um provedor (upstream source) de códigos testados para bibliotecas e utilitários.

  Sendo o downstream do projeto, as organizações se aproveitam das novas funcionalidades, das correções de bugs e dos testes que o código fonte do projeto FreeBSD recebe.

• Como sistema operacional integrado (por exemplo, em um roteador OEM e ou em um dispositivo de firewall). Neste modelo, as empresas utilizam uma versão customizada do kernel e do conjunto de aplicativos do FreeBSD, juntamente com uma camada proprietária de gestão para os seus dispositivos. Os fabricantes de equipamentos originais (OEMs) se beneficiam da adição por parte do FreeBSD de suporte a novos componentes de hardware, bem como se beneficia dos testes que o sistema base recebe.

  O FreeBSD é distribuído com um ambiente de desenvolvimento auto-hospedado o qual permite a fácil criação de tais configurações.

• Como um ambiente Unix compatível para as funções de gerenciamento em dispositivos de armazenamento high-end e em dispositivos de rede, executando em uma lâmina separada.

  O FreeBSD fornece ferramentas para a criação de imagens do sistema operacional dedicadas a executar uma função específica. Sua implementação da API unix BSD é madura e testada. O FreeBSD também pode proporcionar um ambiente de desenvolvimento cruzado estável para os outros componentes de dispositivos topo de linha.

• Como um veículo para obter suporte e testes amplos de uma equipe mundial de desenvolvedores para a sua “propriedade intelectual” não-crítica.

  Neste modelo, as organizações contribuem com frameworks de infra-estrutura úteis ao projeto FreeBSD (por exemplo, veja o netgraph(3)). A ampla exposição que o código obtém ajuda na rápida identificação de bugs e de problemas de desempenho. O envolvimento de desenvolvedores de alta qualidade também resulta no desenvolvimento de extensões úteis para a infra-estrutura do sistema, e das quais a empresa que está contribuindo com o projeto também se beneficia.

• Como um ambiente de desenvolvimento apoiando desenvolvimento cruzado para sistemas operacionais embarcados como RTEMS e o eCOS.

  Existem muitos ambientes de desenvolvimento completos na forte coleção de mais de 24,000 aplicativos portados e empacotados para o FreeBSD.

• Como forma de suportar uma API estilo Unix em um sistema operacional que de outro modo seria proprietário, aumentando a sua palatabilidade para os desenvolvedores de aplicativos.

  Aqui as partes do kernel do FreeBSD e as aplicações são “portadas” para serem executadas juntamente com outras tarefas no sistema operacional proprietário. A disponibilidade de uma implementação estável e bem testada da API Unix™ pode reduzir o esforço necessário para portar aplicações populares para um sistema operacional proprietário. Como o FreeBSD é distribuído acompanhado de uma documentação de alta qualidade sobre a sua estrutura interna, e possui processos eficazes de engenharia para gerenciamento de vulnerabilidades e para lançamento de novas versões, os custos para mantê-lo atualizado são baixos.

2.2 Tecnologias

Existe um grande número de tecnologias suportadas pelo projeto FreeBSD. Abaixo você encontra uma lista com alguma delas:

• Um sistema completo que pode compilar a si mesmo de forma cruzada para as seguintes arquiteturas: alpha (até o FreeBSD versão 6.X), amd64, ia64, i386, sparc64, powerpc (veja build(7)).

• Suporte para as seguintes tecnologias, protocolos e padrões: ATA, ATAPI, ATM, Bluetooth™, CAM, CardBus™, DHCP, DNS, EISA™, Ethernet™, FDDI, Fibre Channel, GPIB, IEEE 1394, IPv4, IPv6, IPSEC, IPX™, ISDN, MAC, NIS, NFS, OpenSSH, OPIE, PAM, PCI™, PCMCIA, POSIX™, PnP, RAID, RPC, SATA, SCSI, SMB, TCP, USB, VESA, VLAN, VLB, WebNFS™.

• Um kernel modular capaz de multiprocessamento simétrico, com módulos de kernel carregáveis e um sistema de configuração flexível e fácil de usar.

• Suporta a emulação de binários do Linux e do SVR4 com velocidades próximas as que você obtém executando os aplicativos de forma nativa. Suporte para os binários dos drivers de rede do Windows™ (NDIS).

• Bibliotecas para muitas tarefas de programação: arquivos, suporte a FTP e HTTP, suporte a threads, além de um ambiente completo de programação POSIX like.

• Funcionalidades avançadas de segurança: Controle de Acesso Obrigatório (mac(9)), jails (jail(2)), ACLs,e suporte no kernel a dispositivos de criptografia.

• Funcionalidades avançadas de rede: firewalls, gerenciamento de QoS, rede TCP/IP de alta performance com suporte a muitos recursos avançados.

  O framework Netgraph (netgraph(4)) presente no kernel do FreeBSD, permite que os módulos de rede possam ser conectados entre si de formas flexíveis.

• Suporte para tecnologias avançadas de armazenamento Fibre Channel, SCSI, RAID por software e hardware, ATA e SATA.

  O FreeBSD suporta um grande numero de sistemas de arquivos, e o seu sistema de arquivos nativo UFS2 suporta soft updates, snapshots e sistemas de arquivos de tamanho muito grandes (até 16 TB por sistema de arquivos) [McKu1999].

  O framework GEOM (geom(4)) presente no kernel do FreeBSD permite que módulos de armazenamento sejam compostos de forma flexível.

• Mais de 24,000 aplicativos portados, tanto comerciais quanto de código aberto, gerenciados através da coleção de ports do FreeBSD.

2.3 Estrutura Organizacional

A estrutura organizacional do FreeBSD não é hierárquica

Existem basicamente dois tipos de colaboradores no projeto FreeBSD, os usuários em geral e os desenvolvedores com acesso de escrita (conhecidos como committers no jargão) ao repositório de código fonte.

Existem muitos milhares de colaboradores no primeiro grupo, a grande maioria das contribuições para o FreeBSD vêm de indivíduos desse grupo; A permissão de commit (acesso de escrita) no repositório é concedida a pessoas que contribuem de forma consistente para o projeto. O direito de commit vem acompanhado de responsabilidades adicionais, e para facilitar o aprendizado das mesmas, um mentor é atribuído a todos os novos committers.

A resolução de conflitos é realizada por um “Core Team” de 9 pessoas, o qual é eleito a partir do grupo de committers.

O FreeBSD não tem committers corporativos. Os committers são obrigados a assumir de forma individual a responsabilidade pelas mudanças que introduzem no código. O FreeBSD Committer's Guide [ComGuide] documenta as regras e responsabilidades que se aplicam aos committers.

O modelo do projeto FreeBSD é examinado em detalhes no [Nik2005].

2.4 Processos de Engenharia para liberação de novas versões do FreeBSD.

O processo de engenharia para a liberação de uma nova versão do FreeBSD desempenha um papel importante para assegurar que as suas novas versões sejam de alta qualidade. Em qualquer ponto do tempo, os voluntários do FreeBSD suportam múltiplas versões do código sistema (Figura 2):

• As novas funcionalidades e os códigos disruptivos entram no ramo de desenvolvimento, também conhecido como ramo -CURRENT.

• O ramo -STABLE contém linhas de código que são ramificadas a partir do HEAD em intervalos regulares. Apenas código devidamente testado é permitido no ramo -STABLE. Novas funcionalidades são permitidas após terem sido testadas e estabilizadas no ramo -CURRENT.

• O ramo -RELEASE é mantido pela equipe de segurança do FreeBSD. Somente correções de bugs críticos são permitidos no ramo -RELEASE.

As linhas de código são mantidas vivas enquanto houver interesse dos usuários e dos desenvolvedores nelas.

As arquiteturas de máquina estão agrupadas em “tiers”; As arquiteturas Tier 1 são totalmente suportadas pelas equipes de engenharia de lançamento e de segurança, as arquiteturas Tier 2 são suportadas em regime de “melhores esforços”, e as arquiteturas experimentais compreendem o Tier 3. A lista das arquiteturas suportadas é parte da coleção de documentos do FreeBSD.

A equipe de engenharia de lançamentos publica um road map para as versões futuras do FreeBSD no web site do projeto. As datas indicadas no road map não são prazos; As novas versões do FreeBSD são liberadas apenas quando o seu código e documentação estão prontos.

O processo de engenharia para a liberação de novas versões do FreeBSD é descrito em detalhes no [RelEngDoc].

3.1 Compreendendo a cultura do FreeBSD

Para ser capaz de trabalhar de forma eficaz com o projeto FreeBSD, você precisa entender a cultura do projeto.

As regras que regem a operação de um projeto voluntário são diferentes das que regem a operação de uma empresa com fins lucrativos. Um erro comum que as empresas cometem ao se aventurar no mundo open-source é o de desvalorizar essas diferenças.

O projeto valoriza perspectivas de longo prazo [Nor2001]. Uma sigla encontrada com frequência no projeto é DTRT, a qual significa “Faça a Coisa Certa” (Do The Right Thing).

Especificações formais e documentos de design raramente são utilizados no projeto. Código claro e bem escrito, acompanhado de logs bem escritos para as alterações das (Figura 3), são usados em seu lugar. O desenvolvimento do FreeBSD acontece por “consenso áspero e por código sendo executado” [Carp1996].

bde         2005-10-29 16:34:50 UTC

  FreeBSD src repository

  Modified files:
    lib/msun/src         e_rem_pio2f.c
  Log:
  Use double precision to simplify and optimize arg reduction for small
  and medium size args too: instead of conditionally subtracting a float
  17+24, 17+17+24 or 17+17+17+24 bit approximation to pi/2, always
  subtract a double 33+53 bit one.  The float version is now closer to
  the double version than to old versions of itself — it uses the same
  33+53 bit approximation as the simplest cases in the double version,
  and where the float version had to switch to the slow general case at
  |x| == 2^7*pi/2, it now switches at |x| == 2^19*pi/2 the same as the
  double version.

  This speeds up arg reduction by a factor of 2 for |x| between 3*pi/4 and
  2^7*pi/4, and by a factor of 7 for |x| between 2^7*pi/4 and 2^19*pi/4.

  Revision  Changes    Path
  1.14      +22 -97    src/lib/msun/src/e_rem_pio2f.c
        

A comunicação entre os programadores é reforçada pelo uso de um style(9) padrão de codificação, comum entre eles.

3.2 Melhores práticas para colaborar com o projeto FreeBSD.

Agora iremos examinar algumas das melhores práticas para se fazer um melhor uso do FreeBSD no desenvolvimento de produtos.