Software livre em uma nova luz

O software livre não é mais apenas para alpha-geeks!

Open source em 2010

Antes
que você desista desta leitura, isso não diz respeito à união de
software livre. É uma tentativa de acabar com todos os mitos relacionados às declarações sobre o software livre. Se existe
alguma coisa em que você precisa começar a pensar é que o
software livre não é mais uma opção de tudo ou nada. Nada neste artigo vai insistir para que você remova o
Windows, instale GNU Linux ou amaldiçoe o Adobe ou queime Apple.

O que este artigo tenta é
fazer algo muito mais modesto: convencê-lo de que o software livre é
uma solução para alguns subconjuntos de problemas e que alguns dos seus
problemas muito provavelmente estão dentro desse subconjunto. Portanto,
se você tiver problemas de navegador com o Internet Explorer, estiver
procurando um Integrated Development Environment (IDE) com um ótimo
código, estiver cansado de pagar pelo PhotoShop ou apenas quiser um
sistema de suporte quase em tempo real, o software livre pode ser a melhor escolha.

Uma abordagem híbrida é quase sempre a melhor

Se você não adota o software livre por questões puramente filosóficas, isso não quer dizer que você não aprecia a abordagem de software livre;
quer dizer simplesmente que você busca soluções alternativas relacionadas aos problemas de software que
está enfrentando. Posto isso, certamente você não é um candidato para
adotar o software livre aproveitando todos os seus recursos. Você até terá alguns
softwares, a maioria deles “fechados” – software comercial ou que não lhe dá acesso ao código de origem. Mas não há nada que sugira que essa é uma forma ruim de mesclar software
livre e coisas que não sejam softwares.

Na verdade, uma abordagem híbrida do software livre é a melhor opção.
Nessa abordagem, você encontra um ou dois pontos problemáticos no seu
ambiente atual. Por exemplo, suponha que você esteja no Windows e o
Internet Explorer apresente problemas. Se você mudar para o Firefox, essa
será uma abordagem híbrida para o software livre. (Sim, se você não
tiver perceber, o Firefox é construído justamente com base em software
livre.) Você está misturando software comercial, como o Windows, com
software livre, como o Firefox. Você está obtendo o melhor de dois
mundos sem precisar residir integralmente em um ou no outro.

O
equilíbrio entre o software livre e o que não é livre convém totalmente
a você. Pode ser que você use nada mais além do Firefox, mas é possível que possa pender para a abordagem de Ernie
Ball defendida por Sterling Ball (veja o link para a história de Ernie
Ball em CNET mencionado em Recursos). Em qualquer um dos casos
ou nos locais existentes entre eles, você faz escolhas com base no que
precisa, e essa é uma coisa boa.

O software livre não diz respeito somente aos desenvolvedores

Como
desenvolvedor que trabalha em projetos de software livre há
aproximadamente 10 anos, tenho consciência de que muitas
comunidades de software livre têm estado tradicionalmente fechadas e
têm sido até mesmo arrogantes. Faça uma pergunta em uma lista de
usuários que alguma pessoa fez oito meses antes e você receberá apenas a resposta para ler os arquivos. Faça um pedido de um recurso e poderá
ouvir um “Pare de reclamar e faça você mesmo. Isso é software livre”.
Essas são abordagens centralizadas no desenvolvedor terrivelmente
arrogantes ao software livre.

Felizmente,
a maioria dos projetos com esse tipo de cultura desapareceu ou mudou
drasticamente. Os desenvolvedores com um pouco de decência voltaram
atrás ou até mesmo abandonaram projetos com esse tipo de comportamento.
Agora em 2010, os projetos de software livre, em sua maioria, não só
têm listas repletas de usuários que são patrulhados por desenvolvedores
que ajudam, como também integram Facebook, Twitter e LinkedIn
como canais de comunicação complementares. Os sistemas de controle de
erros são comuns para os projetos, portanto, é possível enviar um
pedido de recurso ou corrigir erros sem medo de ser atacado. Os melhores projetos acolhem esses relatórios justamente porque eles aprimoram
o conteúdo.

Como exemplo, Xalan-J, um
transformador e processador XML, tem uma página abrangente detalhando
como lidar com problemas, o que é mostrado na Figura 1.

Figura 1 – Xalan-J apresenta uma página escrita com clareza detalhando como relatar problemas

Você
não só recebe instruções, como também há uma lista de usuários
mencionada para ajudar. Embora essa página não defenda o fato de tentar
corrigir um problema, vale a pena observar que Xerces-J
é um projeto de código de baixo nível. Até agora, há informações sobre
como enviar um erro usando JIRA, uma API de relatório de erros completa
excelente (ver Figura 2).

Resumindo, você não está lidando com
interfaces do usuário, somente texto estranhos e instruções complicadas.
Os pedidos de recursos e relatórios de erros são caminhos facilmente
acessíveis que estão documentados para os usuários.

Figura 2 – JIRA oferece relatórios de erros robustos e está completamente aberto e acessível aos usuários

A comunidade é uma coisa boa

Os tipos de interações descritos neste artigo levam ao que podemos chamar
sinceramente de comunidade. Embora seja possível simplesmente interromper um pedido de ajuda ou arquivar um relatório de erros e sair
das listas de usuários, essa não é a norma. A maioria dos usuários que
se inscreve em uma lista de e-mails de projeto de software acaba
ficando. Eles encontram outros usuários que estão trabalhando nos
mesmos domínios com problema ou enfrentando problemas semelhantes em
outro domínio.

Embora pareça simples
e até mesmo muito idealista, a comunidade se forma nessas listas de
e-mails e nos sites de suporte. Você encontrará pessoas que nunca
encontraria e que podem dar conselhos para seus problemas de software. Retornando ao artigo já
mencionado, a experiência de Sterling Ball com software
livre fez mais do que melhorar seus negócios, fez com que ele sentisse
o desejo de permitir que outras pessoas em situações semelhantes
soubessem como lidar com um problema muito real e superar esse
problema. Como resultado, muitas outras empresas estão testando
variações da solução de Sterling e Ernie Ball.

O
software livre parece produzir esses tipos de iniciativas comuns. Seja
essa a natureza de se ter listas de e-mails abertas ou seja esse o fato
de os softwares livres evoluírem rapidamente, a interação parece
progredir. Certamente, ninguém parece se opor à interação
por interesse próprio, mesmo empresas comerciais. Mas, com o software
livre, essa interação parece promover muito bem uma interação posterior e a
interação entre usuários. Esse é um benefício não tão
trivial do software livre.

O software livre é aberto

O “aberto” em software livre não é redundante ou sem importância. Vamos supor que você pelo menos começou a ter a mentalidade de um
desenvolvedor. Talvez você não precise codificar tanto quanto gostaria,
mas você ainda pensa como um desenvolvedor. É
nisso que o software livre brilha cada vez mais. A
partir do momento em que você vai além da comunidade e das abordagens
híbridas, suas preocupações se tornam mais técnicas e o software livre
cuida da maioria dessas preocupações muito bem.

A autodocumentação está geralmente atrasada, mas é útil

Primeiro,
a notícia ruim: os desenvolvedores são reconhecidos por serem ruins na
documentação de seu código. Isso significa que se você for se
aprofundar em Xalan-J ou Firefox ou no seu projeto favorito em
Sourceforge.net, você nem sempre encontrará documentação realmente boa
(os links para todos esses projetos estão na seção Recursos). Não é incomum ver um método denominado initParser() rotulado com algo extremamente inútil como “inicializar o analisador”. Isso é bem útil.

Entretanto,
quanto mais maduro um projeto e sua base de código, melhor a
documentação tende a ser. Pegue o projeto JDOM – uma API de software livre para análise mais amigável do que SAX
ou DOM que já existe há vários
anos. De fato, muita gente – desde a NASA e até mesmo a Sun
Microsystems (agora Oracle) – está usando JDOM. Parte desse uso vem de
sua API bem documentada. Por exemplo, a Listagem 1 mostra o código de
apenas um método na interface Element.

Listagem 1. Amostra da documentação interna de JDOM

/**<br />  * This protected constructor is provided in order to support an Element<br />  * subclass that wants full control over variable initialization. It<br />  * intentionally leaves all instance variables null, allowing a lightweight<br />  * subclass implementation. The subclass is responsible for ensuring all the<br />  * get and set methods on Element behave as documented.<br />  * <p><br />  * When implementing an Element subclass which doesn't require full control<br />  * over variable initialization, be aware that simply calling super() (or<br />  * letting the compiler add the implicit super() call) will not initialize<br />  * the instance variables which will cause many of the methods to throw a<br />  * NullPointerException. Therefore, the constructor for these subclasses<br />  * should call one of the public constructors so variable initialization is<br />  * handled automatically. */<br /><br />protected Element() { } 

Como
desenvolvedor, isso é muito útil. Não há confusão, e usar essa classe
ficou muito mais fácil. A maioria das linguagens – incluindo a Java – permite que esse tipo de documentação em nível de código seja
transformado em algo ainda mais utilizável. A Figura 3 mostra JavaDoc
para a interface Element, gerada diretamente a partir da documentação do código acima.

Figura 3 – JavaDoc é uma representação visual da documentação em nível de código

Comunidades grandes são equipes de suporte grandes

Crie
essa ideia de documentação em nível de código. Primeiro, um
desenvolvedor escreve alguma documentação. Em seguida, outros que estão
no projeto interagem com esse código e refinam ou deixam o
desenvolvedor original refinar sua documentação. Portanto, a
documentação é aprimorada.

Em
seguida, os usuários começam a interagir com o código. Alguns desses
usuários encontrarão problemas, relatarão esses problemas e até mesmo
ajudarão a resolvê-los. A documentação cresce.

À
medida que a base de usuários cresce, algo mais ocorre: Vários desses
usuários serão do tipo A, tipos orientados pelo excesso de detalhes (e
eu posso dizer isso porque sou uma dessas pessoas). Essas pessoas irão
trabalhar arduamente na base de código e aprimorar a documentação. Eles
não podem ajudar nisso, faz parte de sua natureza. Portanto, embora
alguns desses usuários nunca venham a mudar a funcionalidade do código,
eles estão melhorando a sua documentação.

Em
todo esse processo, a comunidade de usuários está se tornando a
comunidade de suporte. As respostas são reunidas por um grupo cada vez
maior de interessados – muitos dos quais não são pagos ou nem mesmo
estão associados à base de código de origem original. Por exemplo, veja
o fórum de projetos do Eclipse dos novatos (ver Recursos).
Esse é um ambiente de desenvolvimento de software livre. Veja os
diversos posts e note como muitos são respondidos – e respondidos
por completo – por pessoas sem um e-mail Eclipse.org. Não se trata do
pessoal da IBM atuando às escondidas. Pelo contrário, você está vendo
como uma comunidade de software livre se torna uma comunidade de
suporte. Isso não é software comercial, é?

Você pode enviar um e-mail diretamente para a Microsoft?

O problema é real: quanto maior a empresa,
mais difícil fica obter um suporte de qualidade. Quando foi a última
vez que você achou que poderia receber um e-mail pessoal sobre os seus
problemas com Excel® ou Mac OS X? Embora isso ocorra ocasionalmente – e
parece frequentemente estar relacionado a PR como suporte real – essa
não é a norma. E embora você possa certamente adquirir contratos de
suporte, aguarde pela sorte quando
ligar para o atendimento.

Agora, para ficar claro: assim como você, temos certeza de ter tido excelentes experiências de
suporte. Já vi pessoas ignorando o fato de eu estar fora do meu período
de registro e receber ajuda, tive explicações excelentes e cuidadosas em
grandes e-mails após desligar o telefone, recebi acompanhamento para verificarmos juntos as coisas. Não há nada que diz que
empresas comerciais não podem ter um excelente suporte.

Além
do mais, muitos projetos de software livre têm empresas que foram
montadas para fornecer suporte para esses projetos. Alguns usam essas
empresas, outros, não. Portanto, o suporte pode ser “comercial” tanto
em um ambiente de software livre quanto em um de software fechado. Os
estereótipos raramente ajudam e fazem você e aqueles que poderiam
compartilhar sua posição parecerem mais tolos do que nunca.

Entretanto,
considere o que foi projetado aqui: o suporte não é mais o domínio
principal de um grupo seleto de pessoas. A documentação do código
fornece suporte. A leitura dessa documentação o torna mais instruído e,
em muitos casos, atende às suas próprias necessidades. O grupo de
usuários forma uma comunidade de suporte maior. Prefiro
contar com alguém que passou a noite toda caçando um erro para dar
agora um grande conselho do que com uma pessoa que pagou para ler as
respostas de uma seção de perguntas frequentes – não importa quão
excelente e detalhada seja essa seção.

O software livre é iterativo

Iteração é um termo falado à exaustão. Ele aparece particularmente nos círculos
de desenvolvimento de softwares. No software livre, a iteração
vagamente se refere à tendência do software de ser lançado com
frequência. De fato, essa é uma ideia principal do software livre:
lançar cedo, lançar com frequência. Portanto, é possível ter com
facilidade 15 ou 20 releases entre os releases principais (2.0, 2.1,
2.1.1, 2.1.2, 2.2 etc. e finalmente 3.0).

Não
existe nada aqui para sugerir que o software comercial também não
itera. Entretanto, essas iterações são frequentemente ocultadas da base
de usuários comum e típica. Até mesmo softwares como o Windows e Mac OS
X, embora atualizados frequentemente, subestimam essas atualizações
com slide-ins e slide-outs reservados na parte inferior da tela ou em
janelas minimizadas. Por quê? Porque para a maioria dos softwares
comerciais, a revisão é vista como correção de erros. Quanto mais
revisões, mais erros precisam ser corrigidos.

Com o software livre, o oposto é verdadeiro. O código está aberto, portanto, se houver erros, todos
saberão que ele existe. Apenas se inscreva em uma lista de usuários
para JDOM ou Xalan-J ou Eclipse ou Firefox. Os erros não são secretos.
Faça logon em JIRA para qualquer projeto de que goste. O resultado?
Releases e revisões frequentes para corrigir esses erros. Não há o que
esconder, certo? E com esses releases frequentes, o usuário
pode conseguir vantagens muito boas.

Você controla os pedidos de recursos

Quando os softwares são lançados com frequência e não há erros reais que são
“ocultados”, você tem uma base de código em constante evolução.
Portanto, como consequência natural, as atualizações são fáceis. Se
você já está produzindo um release por mês (ou até mesmo mais), por que
não adicionar recursos ao software, em vez de apenas corrigir erros?

Agora,
pense nisso. A comunidade de usuários é a comunidade de suporte, que
localiza e corrige erros. Os desenvolvedores estão engajados com o seu
público porque eles são também o público. Então, quem está controlando
os pedidos de recursos? Um gerente em algum lugar? Um grupo de
acionistas? Um gerente de projetos? Na verdade a resposta é não, embora todos possam estar
envolvidos em algum estágio ou outro. Você está no controle. Você é o
público. Você é o acionista, de muitas formas.

Por
fim, releases frequentes indicam melhorias frequentes. As correções de
erros não são uma melhoria, mas são atualizações da funcionalidade. E como
o desenvolvimento é aberto, você é um grande influenciador. Em JDOM – em
que fui um cocriador e ativista de longa data -, a maioria de nossas
principais mudanças de software estava nas respostas às solicitações
dos usuários. A mudança para uma nova versão que tivesse mais suporte
orientado a interface era desenvolvida por um usuário que não tinha
nenhuma relação “oficial” com o projeto. Ele apenas se envolveu no
projeto. O Eclipse é largamente conduzido por programadores espertos
que se aproximam de novos usuários para o código base.

O software livre é feito sob medida para você (um pouco)

Os usuários de longa data de software livre são uma força que cria
esse software sob medida para as suas necessidades. Você pode ficar em
silêncio, nunca participar de uma lista de e-mails e deixar a qualidade
ser o seu único agente de decisão. Foi isso que muito direcionou as
ações de Ernie Ball. Por outro lado, o seu comprometimento significa
que você ganha controle sobre o seu software. Os pedidos de recursos
que você tem são comunicados, e você fica ainda mais capacitado para
adicionar a sua própria funcionalidade.

Ao
mesmo tempo, você mesmo está se adaptando ao software. Isso não é ruim.
O uso frequente e o tipo de entendimento de uma base de código
fornecida pelo software livre permitem definir sob medida a sua forma
de trabalhar com relação ao que o seu software faz melhor. Você verá
que à medida que o seu conhecimento do funcionamento interno do
software aumenta – um efeito natural da participação em listas de
usuários e até mesmo a ajuda com o código – você toma decisões que
otimizam o uso desse software. Você conhece os detalhes, sabe onde o
software funciona bem e sabe onde há problemas. E, no final das contas,
você terá a vantagem de ter esse conhecimento e de fazer mais e melhor
com ele.

Conclusão

A
maioria dos artigos que você vai ler atualmente são discursos vazios.
Ou, na melhor das hipóteses, eles falam do assunto, mas ainda com um ar
de entusiasmo que não leva a lugar algum. Por muitos
anos, os defensores do software livre vêm usando argumentos filosóficos
para dar sustentação ao seu caso. Os defensores parecem ter um desejo
maior de ter mais “convertidos” em sua “doutrina” do que os usuários.
Esse é um grande divisor de águas – não apenas para os não
desenvolvedores, mas para muitos programadores que não têm tempo de
fincar uma bandeira do software livre dentro do seu espaço.

Entretanto,
esse tipo de propaganda oculta os benefícios reais do software livre.
Usado criteriosamente (essa é uma forma menos ofensiva de dizer “Não
use software livre em qualquer lugar na maioria dos casos!”), o
software livre pode reduzir os custos e, em alguns casos, aprimorar
realmente a funcionalidade. Conforme mencionado, o Firefox é o exemplo
mais óbvio para a maioria dos usuários casuais: poucas pessoas instalam
o Firefox porque elas têm uma agenda de software livre. Ele é de fato
um navegador útil, com mais plug-ins do que todos os outros navegadores
juntos. Por quê? Porque o software tem o suporte de uma comunidade
ativa e vibrante.

Talvez o melhor
argumento para a sua consideração do software livre em um ambiente
híbrido continue sendo a própria IBM. (Este é um artigo retirado em um site da IBM. Ainda assim, mantenho a afirmação.) A IBM
parece estar agindo para apresentar suas ofertas comerciais e ainda tem
uma lista muito boa de softwares livres circulando por aí, com doações
de Apache a Eclipse e de todo mundo. Essa abordagem – o uso do software
livre quando ele faz sentido – é a recomendada a você.

Talvez
você não goste do Gimp, e o PhotoShop seja a sua melhor aposta. Talvez
marcadores sincronizados com o Safari em seu desktop e iPhone realmente
sejam a melhor solução. Apenas não desperdice mais
qualquer software aberto por causa de um pequeno momento de indignação.
Se você precisar de ciclos de atualização rápidos e recursos incríveis,
procure as alternativas de software livre. Se precisar de suporte sem
gastar tanta grana durante o ano, veja o que o software livre tem a
oferecer a uma determinada área. E o que quer que faça, informe-se
antes. Faça boas escolhas com base em boas informações. Todos nós
ficaremos mais felizes. E conte-nos quais ofertas de software livre
você particularmente escolheu – e recusou – e por quê. Vejo você por aí
on-line.

*

artigo publicado originalmente em IBM developerWorks, por Brett McLaughlin

Brett McLaughlin é uma das autoridades líderes atualmente em
programação corporativa. Ele projetou, arquitetou e implementou
soluções corporativas na Nextel Communications e na Allegiance Telecom,
Inc. e ajudou a desenvolver o servidor de aplicativos J2EE de software
livre Lutris Enhydra. Escreveu livros sobre XML, Java, ligação de dados
e aplicativos corporativos e é autor de mais de 50 livros sobre
programação corporativa. Além disso, Brett é membro responsável por
todo servidor de aplicativos J2EE de software livre disponível hoje:
JBoss, Enhydra e OpenEJB. É também cofundador da API JDOM para Java e
XML, do projeto Apache Turbine e está envolvido em vários outros
projetos de software livre. Atualmente, escreve e edita para a O’Reilly
& Associates, a maior editora técnica do mundo. Entre em contato
com Brett no endereço brett@oreilly.com.