Segue abaixo a tradução do texto do Josh Berkus (desenvolvedor do PostgreSQL e do Bizgres) devidamente autorizada pelo autor. Achei o texto interessante, particularmente num momento crucial para a organização do PSL-ABCD.
Tradução livre do texto: “The 5 Types of Open Source Projects” Posted by Josh Berkus at 15/03/2005 in http://www.powerpostgresql.com/5_types
Copyright (c) 2005 by Josh Berkus and Joe Conway. This material may be distributed only subject to the terms and conditions set forth in the Open Publication License, v1.0 or later (the latest version is presently available at http://www.opencontent.org/openpub/).
Há cerca de dois anos atrás, Bruce Momjian foi ao Japão ensinar aos executivos japoneses sobre Software de Código Aberto. Como muitos executivos de negócio dos E.U.A., estes gerentes japoneses tinham ouvido sobre Linux e talvez Apache, mas de não tiveram nenhum noção da quantidade, deixando para traz a diversidade de projetos de código aberto existentes. Assim eu escrevi para Bruce uma apresentação de Slides chamada “os seis tipos de projetos de código aberto”.
Com quase cem mil projetos apenas no SourceForge, seria possível classificar projetos em uma miríade das maneiras. Podem ser categorizados pela licença, pela origem, pela arquitetura da colaboração, pelo método de comunicação, ou até pelo epicentro geográfico do desenvolvimento.
Aqui eu estou olhando a classificação organizacional. Quem toma as decisões no projeto? Como um contribuinte se junta ao projeto? Como o código é aprovado? Como são os objetivos estratégicos, se existirem?
Examinando o mundo do código aberto sob esta luz, cada projeto de OSS que eu encontrei pode ser encaixado em somente uma de cinco categorias, ou como um híbrido de duas das cinco. São elas:
1. Solo
2. Monarquia
3. Comunidade
4. Corporativo
5. Fundação
Eu numerei 1-5 acima porque a numeração indica uma tendência geral para o formalismo crescente. Isto é, os projetos solo são, geralmente, muito informais e têm pouca burocracia, e os projetos corporativos e de fundação tendem a ter por escrito exigências e regras e uma extensiva política interna que é inevitável aos seus participantes. Também, os projetos tendem a mover-se “para acima” não “para baixo”: um projeto da comunidade pôde transformar-se em uma fundação, mas é improvável transformar-se numa Monarquia. Há, obviamente, algumas variações significativas nisso. Agora, algumas definições:
Solo
===
Descrição: de longe a maioria numérica dos projetos (90% ou mais). Os projetos de solo têm somente um ou dois colaboradores que são responsáveis por 100% do código, das decisões, e da sustentação do projeto. Consistem geralmente em um ou dois programadores que se decidiram abrir a fonte de um projeto feito por eles na esperança de melhorar sua imagem profissional e/ou de atrair outros colaboradores para ajuda-los. Alguns projetos solo são derivações (forks) de outros projetos onde um colaborador que discordou com o restante do projeto decidiu romper criando o seu próprio.
Contribuição: Os projetos de solo tendem a ser impossíveis ou extremamente fáceis de se contribuir. Na maioria dos casos, os colaboradores do projeto ficam emocionados em ter ajuda e interesse e serão extremamente responsivos: afinal de contas, eles abrem o código a fim compartilhar. Às vezes, particularmente no exemplo de projetos derivados (forks), o desenvolvedor/dono do projeto pode ter uma personalidade espinhosa, difícil de se aproximar.
Suporte: Os proprietários de projetos de solo tendem a ser extremamente responsivos aos pedidos de usuário, em parte porque muitos destes projetos têm poucos usuários. Alguns, entretanto, são abandonados por seus criadores (como o Flexbackup foi por diversos anos) ou pertencem a programadores anti-sociais ou sobrecarregados de trabalho que são completamente incomunicáveis. Emitir algumas mensagens a sua lista enviar lhe dirá rapidamente com o que você está tratando. O ponto principal ao adotar um software de projeto solo é a possibilidade do único colaborador perder o interesse, ter problemas pessoais, ou mesmo morrer, quebrando toda a sustentação do projeto. Assim os negócios que pensam em incorporar o software solo na sua infrastrutura ou produto devem certificar-se de que podem contratar/empregar o proprietário do projeto, ou em que alguém de sua equipe de funcionários é suficientemente hábil para assumir o projeto na eventualidade dele falhar.
Exemplos: Bricolage é um projeto solo muito bonito, com o 90% do código escrito por David Wheeler e seu empregado. Para outros exemplos, navegue pelo SourceForge e FreshMeat: você verá milhares de projetos de solo como o iBookshelf, o editor de texto de Joe, o dbmail, e o Framewerk.
Notas: Há uma tendência na imprensa em pintar projetos de solo como menos legítimos do que projetos maiores. Isto é realmente injusto; frequentemente estes projetos são extremamente úteis, e às vezes há somente um colaborador porque somente um é necessário. Para a maioria deles, é simplesmente porque o projeto é muito novo.
Monarquia
=======
Descrição: Um projeto de Monarquia é geralmente um projeto de solo que “deu certo” e desenvolveu uma comunidade grande. Enquanto estes projetos podem envolver um grande número contribuintes, todas as decisões são feitas pelo lider do projeto e um número pequeno de “colaboradores” que ele/ela aponta. Os objetivos estratégicos, e as disputas políticas, são definidas sempre pelo desenvolvedor lider ou pelo colaborador indicado.
Contribuição: contribuir num projeto Monárquico é relativamente fácil. Você necessita apenas se aproximar do lider do projeto ou de ou um de seus colaboradores indicados com um pedido ou uma contribuição do código, e eles se decidirão imediatamente. Para projetos maiores, mais populares, o colaborador indicado não responderá aos contatos sempre porque ele é demasiado ocupado. No geral, a estrutura hierárquica apertada destes projetos resulta muito pouca politicagem: todas as disputas long-running serão definidas pelo programador lider rapidamente.
Suporte: projetos monarquistas, sendo maiores do que projetos solo, serão proporcionalmente mais formais. Nas listas de e-mail, você receberá frequentemente mais respostas de seus colegas usuários do que dos colaboradores a menos que você seja um colaborador do projeto. Para bugs, Monarquistas frequentemente irão requerer o uso de um bug-tracker formal, tal como Bugzilla. Para o suporte corporativo, a prática aceita é a de empregar ou contratar o lider do projeto ou sua empresa ou empregar/contratar um de seus colaboradores indicados ou suas empresas. De fato, algumas companhias mantém um lider de projeto ou colaborador indicado em sua folha de pagamento justamente para poder oferecer suporte pleno ao software para clientes.
Exemplos: Muitas linguagens de programação, incluindo o Perl e o Python, são projetos Monarquistas. Por outro lado, o Linux, OpenBSD, Memcached e Bittorrent são projetos populares Monarquistas de tamanho variando.
Notas: O crescimento de projetos de Monarquistas dependem geralmente pesadamente da habilidade gerencial e da liderança inspiradora do lider do projeto. Isto significa também que conflitos de personalidade entre colaboradores e o lider de projeto resultam frequentemente em derivações(fork) do projeto.
Comunidade
========
Descrição: Os projetos de comunidade têm um número significativo de contribuintes que fazem o projeto funcionar democraticamente como pares. Enquanto votações majoritárias são ocasionalmente realizadas, a maioria de decisões são feitas por uma combinação de meritocracia* e consenso. Os projetos maiores podem ter um comitê superior dos membros sénior que decidem o sentido estratégico, disputas dos colaboradores, e quem tem o direito de “commitar”.
Contribuição: Os projetos de comunidade geralmente estão dando extremas boas-vindas aos novos contribuinte, e não têm geralmente nenhum processo de ingresso formal pelo qual você “é aceito.” No entanto, os membros novos são incentivados fazer contribuições ao projeto e estas contribuições são vigorosamente (às vezes ásperamente) revistas. Uma vez que você começa, sua voz dentro do projeto está determinada geralmente por uma combinação de seu tempo de contribuição, da quantidade e da qualidade de suas contribuições, e da sua eloquência online. Todas as decisões executivas feitas sem discussão serão altamente suspeitas e podem resultar em flamewars ou em ostracismo.
Suporte: Por causa deste processo social intenso, os projetos de comunidade confiam geralmente em listas extremamente ativas, fóruns, e/ou ferramentas do bate-papo, adicionando às vezes até milhares das mensagens por semana. Estes meios são também seu canal principal de suporte, assim para ter suporte pontual dos desenvolvedores para bugs e instruções requer que você participe do processo social. Para uns níveis maiores de suporte você emprega geralmente um contribuinte principal do projeto, ou uma das diversas empresas participantes.
Exemplos: Os projetos grandes de comunidade são relativamente poucos devido ao balanço político requerido para mantê-los estáveis. O projeto PostgreSQL e o Linux Terminal Server Project são bons exemplos. O Debian é também um projeto de comunidade mas tem uma política de fundação de acordo com muitos e o FreeBSD é uma comunidade mas tem incorporado recentemente uma Fundação não comercial.
Notas: Os projetos de comunidade operam-se por uma sinergia geral, e em consequência tendem a não ter nenhum planejamento estratégico detalhado. Mais que trabalhar para objetivos específicos, as comunidades focaliza o recrutamento para avançar no projeto adquirindo código e ideias o mais rápido possível.
Corporativo
========
Descrição: Os projetos corporativos consistem geralmente no código fechado que foi aberto por uma companhia mas não se alienou completamente dele. Para muitos, pode ser duro dizer a diferença entre o projeto e a companhia: a maioria dos programadores são empregados da companhia e o departamento do marketing da companhia determina o sentido estratégico para o projeto. Às vezes estes projetos consistem em código antigo ou não comercializável que a companhia lançou na esfera pública por razões estratégicas ou de relações públicas. Outros projetos incorporados são parte de uma classe crescente das companhias pequenas que vêem o código aberto como o melhor método de distribuição para seus produtos: as companhias com “licenciamento duplo”.
Contribuição: é freqüentemente difícil ou impalatável participar de projetos corporativos, motivo pelo qual geralmente não atraem muitos colaboradores independentes. Geralmente é preciso atravessar um processo de entrada formal incluindo a atribuição dos direitos à companhia patrocinadora. Além disso, os contribuintes externos serão geralmente colocados de fora nas tomadas de decisão dentro do projeto, já que as decisões se originam na companhia. Assim a maioria dos contribuintes externos tendem a focalizar add-ons ao software central.
Suporte: uma quantidade variável de suporte pontual estará disponível em listas e outros fórums públicos, dependendo da popularidade do projeto e a quantidade de tempo que a companhia deixa seus colaboradores gastar no tratar com o público. O suporte confiável freqüentemente é obtido somente com um contrato de suporte ou licença comercial com a companhia patrocinadora.
Exemplos: Este é um tipo popular em bases de dados: MySQL, Firebird, BerkeleyDB e Ingres são todos projetos corporativos, os primeiros três da variedade com “licenciamento duplo” e o último exemplo de uma corporação grande que liberou um código mais velho abrindo-o. Compiere e Hed Hat Fedora são outros exemplos, como os outros métodos de licença dupla, o JBoss.
Notas: OpenOffice.org, como um projeto corporativo grande e muito popular, chegou em uma estrutura peculiar com uma comunidade de usuários grande em diálogo com a corporação patrocinadora. Apesar da vibrante comunidade de usuários, no entanto, todos os colaboradores principais permanecem empregados da Sun. É também ruim notar que projetos corporativos estão sozinhos por terem um modelo organizacional que requeira uma licença particular. Quase universalmente, usam o GPL ou LGPL (a fim compelir que a contribuição retorne) ou a licença no estilo da Mozilla que maximizam o crédito para a companhia.
Fundação
======
Descrição: uma fundação não comercial pode ser pensada como o ponto final na organização formal de projetos de código aberto. Tais projetos são incorporados com gerentes e diretores e toda a tomada de decisão é formalizada pelas necessidades da estrutura incorporada. Isto é feito frequentemente em resposta ao projeto que é crítico a diversas companhias grandes, que usam a estrutura formal para proteger seus interesses mútuos e assegurar a si mesmos uma voz. Às vezes as fundações se originam quando projetos bem estabelecidos da comunidade sentem que necessitam das vantagens de uma estrutura legal e a habilidade de empregar uma equipe de funcionários. Finalmente, algumas fundações são o resultado de uma companhia que se aliena de um código de um projeto corporativo e que cria uma fundação não comercial para protegê-lo.
Contribuição: As fundações têm geralmente um processo de ingresso formal que incluem, como em projetos corporativos, aderir a um documento de garantia de direitos. Em algumas fundações criadas por corporações, indivíduos não podem participar dos grupos do processo de governanaça, somente representantes de companhias e grupos. Isto significa que você deve contribuir enquanto patrocinador do projeto a fim participar inteiramente. Outros dividiram o projeto em pequenos sub-projetos secundários que se operam bem como projetos monárquicos ou de comunidade individualmente.
Suporte: Frequentemente as fundações terão listas dos patrocinadores que dão forma também ao núcleo da sustentação comercial para o projeto. Isto torna relativamente fácil encontrar sustentação paga. O suporte não pago varia: algumas fundações comportam-se mais como comunidades, e alguns mais como projetos corporativos canalizando pedidos para o suporte pago. As fundações são o único tipo de projeto a acoplar um fundo sistemático. Os usuários serão incentivados em muitos fóruns públicos a fazerem doações para o projeto.
Exemplos: A Apache Software Foundation o a uber-Foundation, usando sua estrutura formal para governar não apenas a si própria, mas projetos secundários numerosos tais como o mod_perl e o SpamAssassin. A Fundação Mozilla está crescendo na mesma maneira. Outras fundações incluem Gnome, o Projeto Gnu a Free Software Foundation e o Projeto XFree86.
Notas: por favor note que a mera posse de papéis de incorporação não faz do projeto uma fundação na sua estrutura. Linus Torvalds trabalha para OSDL, no entanto o Linux remanesce na maior parte Monarquista, e a base de dados de Firebird é incorporada pela organização não comercial, contudo remanesce no controle da companhia cd consultoria IBPhoenix.
Tenha em mente que a estrutura organizacional de um projeto não é estática; muitos, se não a maioria dos projetos são de um tipo e estão no processo de transformar-se em um outro tipo, tal como Bricolage que é solo mas está se tornando comunidade, ou FreeBSD que é comunidade se tornando fundação. Alguns projetos são híbridos, tais como a linguagem PHP, que mantém um contrapeso entre o núcleo core dominado pela Zend (corporativo) e um grande número de contribuintes externos(comunidade).
E, naturalmente, minha categorização dos projetos é na maior parte subjetiva, assim esteja certo de verificar as coisas por si mesmo.
De mais a mais, a vibração, a durabilidade, e a adoção de um projeto de código aberto (sucesso, em outras palavras) não são dependentes do tipo da organização. Depende de uma variedade de fatores, sobretudo da boa liderança do projeto por seus lideres/donos.
