Software livre em uma nova luz

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

Então, você precisa cortar custos, mas não é gerente. Você é um desenvolvedor de software ou um usuário avançado ou alguém que precisa manter os resultados saudáveis o suficiente para justificar o seu salário. Essas situações são ideais para apresentar soluções de software livre no seu ambiente. Isso pode fazer parecer que você passará as próximas três semanas aprendendo a programar ou escrever makefiles, mas não é isso. Leia e veja como o software livre é uma abordagem flexível e que pode ser usada de maneira eficiente no seu ambiente de trabalho.

Brett McLaughlin, Author and Editor, O'Reilly & Associates

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.



26/Mai/2014

Open source em 2010

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

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 exatamente parte de sua pilha de software.

Uma abordagem híbrida é quase sempre a melhor

Digamos que 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ê tem preocupações pragmáticas para buscar soluções alternativas relacionadas aos problemas de software que está enfrentando. Posto isso, certamente você não é um candidato para adotar o software livre "em sua plenitude". Portanto, você terá alguns softwares — até mesmo a maioria deles — "fechados". Isso significa que o software é comercial ou não lhe dá acesso ao código de origem. Ótimo. Não há nada que sugira que essa é uma forma ruim de mesclar software livre e coisas que não sejam softwares.

De fato, uma abordagem híbrida do software livre é a sua 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 o deixe doido. 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. Isso é ótimo. Por outro lado, é 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); eles praticamente usam apenas software livre. 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 muita 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ê verá a imitação "Leia os arquivos, bobinho!". 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, de fato, 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. De fato, os melhores projetos acolhem esses relatórios, visto que eles aprimoram o projeto.

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, por natureza, é 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). Em outras palavras, você não está lidando com interfaces do usuário somente texto estranhas 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

Por fim, os tipos de interações descritos aqui 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 que podem dar conselhos ou a quem é possível dar conselhos, no contexto dos seus problemas de software. Retornando ao artigo já mencionado de Ernie Ball: 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 seriamente à interação por interesse próprio, mesmo empresas comerciais. Mas, com o software livre, essa interação parece promover uma interação posterior e a interação entre usuários especialmente bem. Esse é um benefício não tão trivial do software livre.


O software livre é aberto

Eu tento evitar títulos mais inteligentes — em livros, seções de um artigo, você dá um nome a eles — mas, aqui, a coisa precisa ser dita: o "aberto" em software livre não é redundante ou sem importância. Sim, vamos considerar que você tenha gerentes e interesses corporativos; a primeira seção deste artigo deve ter soado familiar a eles em detalhes.

Mas, em virtude de você se expor no IBM® developerWorks, vou fazer outra suposição: 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. Essa é uma coisa boa. É nisso que, honestamente, o software livre brilha cada vez mais. A partir do momento 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, que já existe há vários anos (ver Recursos). JDOM é uma API de software livre para análise mais amigável do que SAX ou DOM. 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
 /**  * This protected
                constructor is provided in order to support an Element  * subclass that
                wants full control over variable initialization. It  * intentionally
                leaves all instance variables null, allowing a lightweight  * subclass
                implementation. The subclass is responsible for ensuring all the  * get
                and set methods on Element behave as documented.  * <p>  * When
                implementing an Element subclass which doesn't require full control  *
                over variable initialization, be aware that simply calling super() (or  *
                letting the compiler add the implicit super() call) will not initialize  *
                the instance variables which will cause many of the methods to throw a  *
                NullPointerException. Therefore, the constructor for these subclasses  *
                should call one of the public constructors so variable initialization is
                * handled automatically.  */
protected Element() { }

Como desenvolvedor, isso é muito útil. Não há confusão, e usar essa classe ficou muito mais fácil. Claro, 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; é chocante 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?

OK, isso é um pequeno golpe. 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, joga-se o dado para ver quem atende ao telefone quando você liga.

Agora, para ficar claro: Eu, assim como você, temos certeza de ter tido excelentes experiências de suporte. Eu vi pessoas ignorando o fato de eu estar fora do meu período de registro e ajuda; tive explicações excelentes e cuidadosas em grandes e-mails após desligar o telefone; entram em contato comigo apenas para acompanharmos 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. Por fim, eu preferiria contar com alguém que passou a noite toda caçando um erro para me 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 detalhado 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, você — 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? Bem, 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 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)

Por fim, 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 em um discurso 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. (Sim, de novo, este é um artigo publicado 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. Isso é ótimo. Apenas não desperdice mais qualquer software aberto por causa de um pequeno momento de indignação. (Essa sentença soa bastante dramática devido à ação que ela descreve.) 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 que. Vejo você por aí on-line.

Recursos

Aprender

Obter produtos e tecnologias

  • Eclipse é um dos melhores IDEs existentes e tem uma arquitetura de plug-in abrangente. E, o melhor de tudo, ele é um software totalmente livre.
  • Xalan-J é um processador XML de software livre, criado com base em todas as ferramentas e todos os analisadores de software livre.
  • JDOM é uma API de analisador de software livre criada devido à frustração com as APIs existentes. Esse é um verdadeiro software livre: você corrige alguma coisa porque ela não funciona.
  • Veja o Mozilla Firefox, um excelente navegador da Web e o melhor ponto de partida para se conhecer um software livre confiável.
  • Inove em seu próximo projeto de desenvolvimento de software livre com o software de avaliação da IBM, disponível para download ou em DVD.
  • Faça download das versões de avaliação de produtos IBM ou explore as avaliações on-line no IBM SOA Sandbox e utilize as ferramentas de desenvolvimento de aplicativos e produtos de middleware do DB2®, Lotus®, Rational®, Tivoli® e WebSphere®.

Discutir

Comentários

developerWorks: Conecte-se

Los campos obligatorios están marcados con un asterisco (*).


Precisa de um ID IBM?
Esqueceu seu ID IBM?


Esqueceu sua senha?
Alterar sua senha

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


A primeira vez que você entrar no developerWorks, um perfil é criado para você. Informações no seu perfil (seu nome, país / região, e nome da empresa) é apresentado ao público e vai acompanhar qualquer conteúdo que você postar, a menos que você opte por esconder o nome da empresa. Você pode atualizar sua conta IBM a qualquer momento.

Todas as informações enviadas são seguras.

Elija su nombre para mostrar



Ao se conectar ao developerWorks pela primeira vez, é criado um perfil para você e é necessário selecionar um nome de exibição. O nome de exibição acompanhará o conteúdo que você postar no developerWorks.

Escolha um nome de exibição de 3 - 31 caracteres. Seu nome de exibição deve ser exclusivo na comunidade do developerWorks e não deve ser o seu endereço de email por motivo de privacidade.

Los campos obligatorios están marcados con un asterisco (*).

(Escolha um nome de exibição de 3 - 31 caracteres.)

Ao clicar em Enviar, você concorda com os termos e condições do developerWorks.

 


Todas as informações enviadas são seguras.


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=80
Zone=Software livre, Linux
ArticleID=487626
ArticleTitle=Software livre em uma nova luz
publish-date=05262014