A Sun e o código aberto corporativo

Sun and corporate open source

Autor original: Jonathan Corbet

Publicado originalmente no: https://lwn.net/

Tradução: Roberto Bechtlufft

Nas últimas semanas, vários blogs publicaram artigos interessantes sobre a forma como a Sun vem gerenciando seus projetos de código aberto. Em um momento em que mais e mais empresas se envolvem com o software livre, há muito que elas podem aprender com esta discussão. Então, aqui vão algumas opiniões sobre o código aberto corporativo.

Tudo começou com um post de Ted T afirmando:

Se um vendedor ou CEO da Sun vier dizendo que o OpenSolaris é como o Linux, saiba que ele não é. Fundamentalmente, o OpenSolaris foi lançado sob uma licença de código aberto, mas ele não tem uma comunidade de desenvolvimento de código aberto. Talvez um dia ela se torne uma, como alguns executivos da Sun andam dizendo, mas isso definitivamente não é uma prioridade para a Sun; se fosse, isso já teria sido feito.

O post rendeu respostas de Dave Neary e Alvaro Lopez Ortega, dentre outros; tanto a mensagem original quanto as respostas merecem ser lidas integralmente. Resumindo, as respostas diziam que (1) a Sun está se esforçando para ser uma boa atuante no código aberto, e (2) a Sun vem se saindo tão bem quanto pode, já que criar comunidades verdadeiramente de código aberto não é nada fácil.

A primeira afirmação deve ser verdade mesmo. A Sun tem sido fonte de muito software livre, incluindo pacotes com o OpenOffice.org, encontrado em quase toda distribuição Linux. A empresa lançou seu sistema operacional como código aberto, e finalmente vem falando em abrir completamente o Java. Poucas empresas contribuíram com código a esse ponto, e isso tem que ser reconhecido. Não há dúvidas de que a Sun está contribuindo para a comunidade.

O que se questiona, porém, é o interesse da Sun em criar comunidades reais em torno de seus projetos de código aberto. A dificuldade em se participar e contribuir com esses projetos já é notória. Como Ted destaca, atualmente o OpenSolaris recebe menos de um patch por dia vindo de fora da Sun, o comitê diretor do projeto é inteiramente composto por funcionários da Sun e o sistema de controle de versão (não distribuído) reside nos limites do firewall deles. Desenvolvedores do OpenSolaris que não fazem parte da Sun rotineiramente abandonam o projeto com mensagens como:

A Sun combinou que o OpenSolaris seria governado pela comunidade mas se recusou, em todos os momentos, a ceder qualquer controle real sobre o software produzido ou sobre a maneira como ele é produzido, continuando a tomar decisões privadas diariamente que mais tarde são promovidas a decisões para essa coisa que chamamos de OpenSolaris. Ao invés de ser honesta sobre isso e reestruturar a comunidade para que corresponda a esse estilo MySolaris de desenvolvimento, a Sun prefere mentir para a comunidade de membros externos e ignorar suas opiniões.

Também continua difícil contribuir com o OpenOffice.org; daí os muitos comentários desencorajadores no ooo-build wiki da parte de desenvolvedores que querem fazer as coisas andarem:

Muitos patches do ooo-build estão prontos para serem incorporados ao upstream, mas há pouca ou nenhuma resposta vindo de lá. Pior que isso é a percepção de que assumir uma posição de liderança e fazer algo a esse respeito provavelmente sofrerá uma forte oposição. Por fim, mesmo quando os mantenedores estão ativos, responsivos e amigáveis, não há um mecanismo estabelecido para a aprovação de correções, que infestam o IssueZilla.

A chave para o que está acontecendo pode ser encontrada em muitos lugares, como no post de Alvaro:

Além disso, o modelo de desenvolvimento do OpenSolaris é bem diferente por motivos técnicos. Na minha opinião, o primeiro motivo é simples: queremos garantir a qualidade, e para isso seguimos uma série de procedimentos. Outra questão técnica muito importante é que queremos que o OpenSolaris continue a ter compatibilidade binária (ABI) com as versões anteriores do Solaris, algo que seria impossível com o Linux.

O verdadeiro problema é o controle; a Sun não quer abrir mão do controle sobre a evolução do projeto. Isso é bastante comum em projetos controlados por corporações; esses projetos sempre serão guiados pelos objetivos da empresa que os controla. Assim, nenhum desenvolvedor será bem-sucedido em projetos como:

  • Adicionar recursos ao MySQL para oferecer funcionalidades reservadas ao pacote “enterprise.”
  • Adicionar pacotes ao Fedora que deixem o departamento legal da Red Hat nervoso.
  • Adicionar recursos a projetos da Free Software Foundation que, na opinião da FSF, não sejam condizentes com seus objetivos – vide o suporte ao carregamento de módulos do Emacs a partir de um repositório externo, por exemplo.
  • Fazer modificações no Firefox que ameacem os lucros obtidos pela Mozilla Corporation com o Google.

As empresas que controlam projetos de código aberto dessa forma geralmente tem o direito de agir assim; elas podem até mesmo agir em nome de seus próprios interesses. O software continua sendo de código aberto. Mas exercer esse tipo de controle acaba tendo um efeito na comunidade que se formou em torno do software. Muitas vezes, isso pode até impedir a criação da comunidade.

E isso também pode ser o que a empresa tinha em mente. Há vários projetos de código aberto controlados por empresas que, pelo visto, são de código aberto só para chamar a atenção e usufruir dos benefícios. Essas empresas não parecem ter muito interesse em desenvolver uma comunidade externa significativa. Em casos assim, se o software oferecido é valioso o suficiente, o resultado provavelmente será um fork mais orientado à comunidade. Projetos como ADempiere, LedgerSMB e Cinelerra CV são resultado desse tipo de frustração.

Será que a Sun não está realmente interessada na criação de uma comunidade de desenvolvedores externos para seus projetos, ou ela só está tendo dificuldades em se adaptar? As opiniões variam bastante. No segundo caso, a Sun talvez deva seguir a sugestão de Dave Neary e criar uma fundação separada e sem fins lucrativos para o desenvolvimento do OpenOffice.org. Os defensores da Sun estão certos ao afirmarem que transformar um monte de código proprietário em código livre é muito difícil. Mas fica ainda mais difícil se você não der à comunidade o poder de ajudar; no caso do OpenOffice.org, parece haver uma comunidade interessada o suficiente para fazer as coisas acontecerem. Pode ser a grande chance da Sun mostrar que pode criar comunidades de desenvolvimento reais em torno de seu software.

Créditos a Jonathan Corbethttps://lwn.net/

Tradução por Roberto Bechtlufft <robertobech at gmail.com>

Ver Mais

Esta postagem foi modificada pela última vez em 02/06/2009 22:26

Postagem relacionada