The Apache Success Story Exploring an Open Source Development Process

Apresentação em tema: "The Apache Success Story Exploring an Open Source Development Process"— Transcrição da apresentação:

1 The Apache Success Story Exploring an Open Source Development Process
By Jim Jagielski Mestrado em Informática – UFCG Cesar Rocha – Na última vez eu havia falado sobre o ESCOT; Agora vamos falar sobre um outro estudo de caso: Apache;

2 Estrutura de Tópicos Introdução; O Processo de desenvolvimento;
Estrutura da equipe; Ferramentas; Infra-estrutura de comunicação utilizada; O Processo Apache; Especificidades; Síntese das principais condutas; O Futuro do processo Apache; Conclusões;

3 Introdução O movimento Open Source Tecnology (OST) tem se desenvolvido ao longo do tempo; Reuniu-se um grande número de desenvolvedores geograficamente dispersos em todo o globo; Um dos projetos mais conhecidos pela comunidade acadêmica: Linux; O servidor Web Apache também é um projeto Open Source de sucesso: O servidor Apache está presente em cerca de 60% de todos os Web sites na Internet; Hoje, junto com o Linux, o Apache denota um dos mais populares “pacotes OST”; A gente sabe que hj o movimento open source tem um apelo muito forte no cenário de desenvolvimento de software; muitos desenvolvedores em todo o mundo tem unido suas forcas para propor sistemas alternativos aqueles que estao inseridos

4 Introdução O sucesso do Apache Group ( Apache Software Foundation – ASF ) não está relacionado somente ao uso ou mesmo a qualidade do Apache em todo o mundo, mas, sobretudo, pelas regras e métodos que foram usados para controlar a forma de como o produto foi desenvolvido;

5 O Processo de Desenvolvimento
Basicamente, como o projeto é Open Source, o processo deve ser claramente definido e prover liberdade e flexibilidade aos “colaboradores”; Os riscos de fracasso nos projetos Open Source estão apoiados principalmente na motivação, coordenação, integração e comunicação entre os colaboradores; Em grandes projetos, com várias linhas de código como o Apache, essas dificuldades foram tratadas com medidas relativamente simples;

6 Estrutura da Equipe O Apache Group é formado principalmente por um pequeno grupo de “core developers”, os quais decidem a direção global do projeto; e noncore members; Aqueles que vem contribuindo com o Apache de maneira expressiva, eleitos e admitidos ao “core team”; A maior parte reside nos U.S., mas na Europa e também em outras partes do mundo residem uma parcela significante da equipe global; Coordenar patches submetidos por “noncore members”, relatórios de bugs, etc...

7 Ferramentas Concurrent Versions System (CVS) é usado como ferramenta de apoio no gerenciamento das versões emanadas pelos desenvolvedores; Provê uma coleção de arquivos dispostos em uma estrutura de diretórios; a ferramenta permite ainda rastrear, atualizar, enfim, gerenciar esse repositório de maneira concorrente; Trabalhos realizados nos “repositórios locais” (visões) são aplicados no repositório central (servidor); Cvs commit; cvs update, etc...

8 Ferramentas O pacote CVS foi usado para minimizar conflitos entre os patches com as constantes atualizações que iam sendo geradas; No início do projeto Apache, isso era feito manualmente! Os desenvolvedores deveriam estar totalmente livres para programar em vez de rastrear mudanças; Apenas o core team possui o privilégio cvs commit; FreeBSB e PHP utilizam CVS; Cvs commit; cvs update, etc...

9 Infra-estrutura de Comunicação
A comunicação entre os desenvolvedores se dá através de uma lista de discussão: Essa lista inclui core members, desenvolvedores e demais pessoas que simplesmente seguem o desenvolvimento do Apache; Existe também uma segunda lista apenas de core members; Pacotes de software relacionados à lista de como Majordomo e Ezmlm foram analisados;

10 O Processo Apache Inicialmente, core members elegiam os patches submetidos pelos desenvolvedores; Voto positivo = +1 e Voto negativo = -1; Para que um patch fosse aprovado, eram necessários 3 votos positivos e nenhum negativo; No caso de pelo menos 1 voto negativo, o patch inteiro era vetado; A pessoa que emitiu o voto negativo tinha o compromisso de justificar sua posição em relação ao patch; (precisava ter uma boa razão para isso...); Todos entendiam o poder do veto e não abusavam dele; Os votos eram registrados em um log;

11 O Processo Apache O processo do voto evoluiu para fazer um melhor uso do tempo dos colaboradores core; O conceito do “lazy voting” ou “silent gives consent”; Isso, no entanto, vale apenas para os patches submetidos por core members; Submissões realizadas por desenvolvedores são votadas pela abordagem anterior; Outra evolução foi o conceito do “commit and review”; Reduz o tempo de submissão e commit para zero;

12 O Processo Apache Continuação:
Supõe-se que o core team sabe o que está fazendo, de maneira que votar em “patches core” não mais seria necessário; Se após ser aprovado um determinado patch despertar suspeitas ou mesmo preocupações, duas opções serão apresentadas: reverter a atualização; o core member que submeteu deve corrigir o erro; Se por acaso uma submissão trouxer a reboque mudanças drásticas, faz-se necessário o uso de uma votação comum;

13 O Processo Apache Conceito de Group Ideal;
Ao contrário de outros projetos Open Source (Linux), o Apache Group não possui um Líder; Nem mesmo entre os Core members – todos são considerados iguais; Escalonamento de atividades e Entrega Não há um momento definido para a disponibilização dos releases; Os releases acontecem quando o grupo sente que é a hora – grande quantidade de mudanças ou mesmo “mudanças especiais”;

14 O Processo Apache Escalonamento e Entrega (cont.):
Entretanto, se bugs relacionados a segurança forem encontrados, novo(s) release(s) serão disponibilizados mesmo antes do desejado; Não há um conjunto de pessoas no grupo responsável por coordenar o release; Normalmente, existem voluntários a “Release Manager”; O Release Manager executa tarefas como: rotular o release, criar o arquivo de distribuição (tarball), assinar digitalmente o tarball, distribuição do tarball no site principal do Apache como também em seus “mirrors”

15 O Processo Apache Divisão do trabalho:
Os desenvolvedores trabalham nas seções de código e áreas nas quais eles têm um maior interesse; As pessoas estão livres para escolher e trabalhar em outras seções que desejarem; Nenhum desenvolvedor em especial é o único responsável por uma determinada funcionalidade; Em contraste com outros projetos Open Source, como FreeBSB, que atribui a conclusão de aspectos do projeto a uma única pessoa;

16 Características do Processo
Em síntese: CVS Commit Privileges: O Apache Group é um pouco conservador em prover esses privilégios por merecimento. Um problema é que atualmente existem novos noncore members que fornecem submissões altamente consistentes, mas que não podem “commitá-las” no repositório – desmotivando-os; Diferentes classes de desenvolvedores: Core Team e Noncore Members; Não há Divisão do Trabalho;

17 Características do Processo
Continuação: Release Schedules: Apesar de alguns desenvolvedores produzirem mais sob pressão, é sabido que em projetos open source a maior parte dos desenvolvedores despedem seus esforços apenas quando possuem um tempo livre; Prazos inadequados podem vir a limitar severamente a criatividade e, sobretudo, a qualidade final do código; Alta Flexibilidade: Projetos altamente rígidos e inflexíveis tendem a dificultar a execução do projeto e sua compreensão;

18 O Futuro do Processo Apache
Já existem alguns projetos usando o processo Apache: Projetos Jakarta; Java Apache; Embora sejam famílias ligadas ao Apache Software Foundation (ASF), em cada projeto os seus desenvolvedores decidem o que funciona melhor para eles; Outros projetos não open source já utilizam uma derivação do processo Apache: OneStopSite – uma firma de Web design;

19 Conclusão do Artigo O projeto Apache mostrou sucesso com o qual o desenvolvimento de código aberto está adquirindo a cada dia em grandes projetos. O compartilhamento de visões e de metas comuns e a alta flexibilidade denotam o combustível que faz com que todos os outros fatores inerentes ao processo trabalhem suavemente; Novos projetos se beneficiam desse tipo de experiência, de modo que o reuso das atividades pode ser empregado;

20 Conclusão Pessoal Acredito que o processo Apache não está limitado apenas a ambientes distribuídos open source, mas também em projetos de software convencionais; Aspectos como alta flexibilidade: seja na divisão do trabalho ou mesmo no escalonamento de atividades devem ser tratados com cuidado; Não limitam criatividade e qualidade; Funcionam principalmente pela cultura e equipes com uma quantidade razoável de pessoas;