4

UNIDADE 4

Seleção de software de
código aberto

Objetivos de aprendizagem
„„ Ser capaz de identificar e pesquisar soluções de
software de código aberto.

„„ Conhecer os itens comuns no processo de seleção úteis

para a tomada de decisão na adoção de software livre.
„„ Compreender outras técnicas de seleção.

Seções de estudo
Seção 1 Identificação do produto

Seção 2 Análise dos atributos

Seção 3 Modelo de maturidade do produto de código

aberto

software_livre.indb 79 28/06/11 10:58

 Universidade do Sul de Santa Catarina

Para início de estudo

Para iniciar esta unidade, você vai compreender “como é feita a
seleção de software de código aberto”.

No momento em que este parágrafo foi escrito encontravam-se no

site <www.sourceforge.org> mais de 169.000 projetos cadastrados. Se
apenas 1% destes contarem com alguma qualidade, isto já representa
quase 1.700 projetos disponíveis para se realizar uma seleção inicial.
Certamente, menos ainda têm um nível de maturidade que os
tornam úteis para serem utilizados em missão crítica, mas, mesmo
assim, trata-se ainda de uma grande quantidade.

Para que um determinado sistema seja adotado, as empresas

necessitam que o produto escolhido esteja em um estágio de
desenvolvimento completo e maduro.

Os itens de verificação básicos para a avaliação de sistemas, tanto

proprietários como software de código aberto, são os seguintes:

„„ identificação;

„„ leitura de avaliações;

„„ comparação;

„„ análise.

Estas etapas, embora comuns aos dois tipos de sistemas,

proprietário e de código aberto, são consideravelmente diferentes.
A maioria dos programas de código aberto tem uma grande
quantidade de informações técnicas prontamente disponíveis, que
permitem verificar muitos detalhes sobre um projeto e possíveis
direções que este tomará no futuro. É possível verificar o quanto
um determinado produto de código aberto tem sido útil e os
defeitos que apresenta, bem como o quanto a comunidade tem
sido eficiente no conserto dos problemas que se apresentam.

Estas fontes de informação são úteis no momento da seleção.

Os itens apresentados nesta unidade servem como base para
comparar soluções de código aberto e estas com proprietárias. O
tempo gasto na avaliação de uma determinada solução depende

80

software_livre.indb 80 28/06/11 10:58

 Software Livre

do tamanho do programa, o quanto detalhada será a avaliação e

o quanto o produto é vital para a empresa. Mas, antes de começar
a seleção, é importante ter em mente quais são as necessidades a
serem supridas pelo produto.

Estes aspectos também mostram a diferença entre o produto

proprietário e o de código aberto, pois o processo de fabricação e
o processo de evolução de um produto proprietário fazem parte
de sua vantagem competitiva e não podem tornar-se públicos.

Observa-se, também, que a escolha de uma solução de código

aberto dispensa algumas tarefas, como a negociação de contratos,
de preços, da manutenção e do suporte fornecido por um único
fabricante (NAVICA Inc., 2004-2007, p. 13).

- Vamos à continuidade do estudo? Iniciemos com identificação

do produto.

Seção 1 – Identificação do produto

A identificação da possível solução a ser empregada pode ser
realizada combinando-se várias fontes de pesquisa. A seguir são
apresentadas fontes normalmente utilizadas para tal.

Sítios Especializados!

Levando-se em consideração que o software de código aberto

é um produto que tem o ambiente de produção proveniente da
colaboração que a internet permite, nada melhor do que usar a
própria internet para procurar soluções candidatas.

Veja, na sequência, exemplos de endereços na web que listam ou

hospedam projetos de software de código aberto.

Unidade 4 81

software_livre.indb 81 28/06/11 10:58

 Universidade do Sul de Santa Catarina

„„ <www.freshmeat.net> - Sem dúvida, um dos sítios

mais completos. Este sítio lista soluções para várias
plataformas, apresentando informações sobre a vitalidade
do projeto, popularidade e outros.

„„ <www.icewalkers.com> - Lista soluções para Linux,

onde os visitantes dão uma nota para cada aplicação.
É preciso observar com cautela as informações aqui e
cruzar com outras fontes de informação, pois este tipo de
avaliação é sujeita a distorções causadas pelo entusiasmo
com o software de código aberto.

„„ <www.koders.com> - É interessante para encontrar

componentes a serem utilizados em projetos em
desenvolvimento.

„„ <osswin.sourceforge.net> - Oferece soluções de software

de código aberto para a plataforma MS Windows.

„„ <directory.fsf.org> - Hospeda um projeto da Fundação

Software Livre em parceria com a UNESCO. Este
sítio cataloga programas software de código aberto
para sistemas operacionais também de código aberto,
particularmente GNU/Linux. O próprio sítio funciona
como um projeto de código aberto.

„„ <www.google.com.br/linux> - É possível encontrar

soluções para Linux, assim como <www.google.com.br/
bsd> é customizado para encontrar compatíveis para BSD.

„„ <sourceforge.org> – Trata-se de um enorme repositório

de projetos de software de código aberto.

Consulta a colegas do ramo é importante!

Pode ser interessante consultar conhecidos do ramo sobre

soluções com software de código aberto empregadas por eles.
Desta forma, tem-se uma fonte de consulta sobre o que deu
certo e os problemas e as vantagens apresentados pela escolha.

82

software_livre.indb 82 28/06/11 10:58

 Software Livre

Uma outra possibilidade é entrar em listas de discussão e realizar

perguntas sobre soluções empregadas, lembrando que o gosto
pessoal pode interferir no julgamento.

É preciso ter muito cuidado ao consultar outras pessoas, pois os

aficionados por software de código aberto costumam ter uma
relação de paixão pelas soluções que empregam, e isto pode
distorcer suas avaliações sobre os produtos. Isto acontece também
com gerentes de TI que escolhem soluções proprietárias. Uma
ação de cautela é questionar números e, se possível, realizar
visitas no local para ver como a solução funciona e se realmente
atende às demandas do ambiente de trabalho.

De qualquer forma, este é um campo minado. Há muitos

interesses em jogo, pois algumas empresas de produtos
proprietários costumam distribuir mimos aos gerentes de TI, e
manter soluções proprietárias pode vir de uma decisão baseada
em ganhos pessoais.

Avaliações
Muitas revistas e suas versões eletrônicas contam com avaliadores
de programas. Exemplos de revistas populares que trazem
avaliações de produtos:

„„ Free Software Magazine - www.freesoftwaremagazine.

com

„„ Linux – linux.wordpress.com

„„ PCMAG.COM - www.pcmag.com

„„ ZDNet - www.zdnet.com/reviews

„„ Open Source Gazette - www.opensourcegazette.com

„„ Cnet Reviews - reviews.cnet.com

„„ Baixaki - www.baixaki.com.br

Unidade 4 83

software_livre.indb 83 28/06/11 10:58

 Universidade do Sul de Santa Catarina

Alguns destes sítios apresentam avaliações mais técnicas do

que outros. As ferramentas de procura, como Google e Yahoo,
também retornam bastantes informações.

Lista de soluções comprovadas

É possível compilar uma lista de soluções clássicas na área de
software de código aberto. Muitos destes aplicativos possuem
versões para várias plataformas. Na unidade sobre aplicativos de
código aberto são apresentados detalhes de alguns aplicativos da
lista abaixo, bem como de outros.

Sistemas operacionais
„„ Linux - Algumas distribuições mais conhecidas são
RedHat, SuSU, Unbutu e Kurumin.

„„ BSD - NetBSD, OpenBSD, FreeBSD.

Serviços de Rede
„„ Postfix - servidor de e-mail.

„„ Apache - servidor web.

„„ Samba - servidor de impressão e arquivos.

„„ Mailman - gerenciador de lista de discussões.

„„ Sendmail - servidor de e-mail.

Bancos de dados
„„ PostgreSQL.

„„ MySQL.

84

software_livre.indb 84 28/06/11 10:58

 Software Livre

Aplicações para desktop

„„ Thunderbird - gerenciador de e-mails.

„„ Evolution - clone do MS - Outlook.

„„ OpenOffice.org - aplicativo de escritório, similar ao MS

Office.

„„ Firefox - navegador web.

„„ GIMP - editor gráfico tipo Corel Draw.

„„ KDE - gerenciador de janelas.

„„ GNOME - gerenciador de janelas.

Ambientes de desenvolvimento
„„ Eclipse - ambiente de desenvolvimento com plugins para
muitas outras linguagens e ferramentas.

„„ Perl - linguagem de programação.

„„ PHP - linguagem de programação.

„„ Bugzilla - controle de bugs.

„„ CVS - controle de versões.

„„ GNU Compiler Collection - linguagens C, C++ e outras.

„„ JBoss – J2EE.

Desenvolvimento e gerenciamento de conteúdo para web

„„ PHP-Nuke - gerenciamento de conteúdo

„„ Manbo - gerenciamento de conteúdo

„„ OpenCMS - gerenciamento de conteúdo

Unidade 4 85

software_livre.indb 85 28/06/11 10:58

 Universidade do Sul de Santa Catarina

„„ Wordpress - gerenciamento de blog.

„„ Textpattern - gerenciamento de blog.

„„ Gallery - álbum de fotografias web.

Seção 2 – Análise dos atributos

Uma vez encontradas soluções que possam satisfazer às necessidades,
o próximo passo é realizar uma análise inicial, visando a eliminar
aquelas que certamente não atendem ao mínimo necessário - o que é
mais fácil depois de ler algumas avaliações sobre o produto.

O local mais indicado para encontrar dados sobre suas

funcionalidades é a página WEB do projeto, onde se encontram
a descrição do projeto, que realça os objetivos do projeto e suas
funcionalidades fundamentais, a lista de perguntas frequentes
(FAQ ) e o manual de uso do sistema. Em alguns casos, pode
ser que o projeto tenha um fork (veja nota). Sendo assim, procure
descobrir o motivo da criação do projeto derivado, o que também
pode ajudar na escolha. Os itens a seguir são alguns pontos
importantes a serem analisados e são os mesmos empregados para
software proprietário, apenas vistos de uma dimensão apropriada
ao software de código aberto. É possível, dependendo da aplicação,
que outras dimensões para comparação sejam acrescentadas.

O que é Fork?

Um projeto de software de código aberto geralmente agrupa uma

grande quantidade de colaboradores. Muitas discussões sobre o
futuro do projeto podem gerar divergências. Estas divergências
às vezes podem levar um grupo de desenvolvedores a criar seu
próprio projeto. A isto se dá o nome de “ fork” em inglês - dividir
em um ou mais caminhos.

86

software_livre.indb 86 28/06/11 10:58

 Software Livre

Um exemplo foi a criação da ferramenta de gerenciamento de

conteúdo Post-Nuken, que se originou da ferramenta PHP-Nuke,
quando um grupo de desenvolvedores se desentendeu com o autor
original do projeto PHP-Nuke e resolveu levar o sistema para uma
arquitetura de solução diferente. Há vários outros exemplos e, até
certo ponto, é salutar a prática, uma vez que aumenta a quantidade
de soluções competindo por excelência e pela preferência do
usuário. Por outro lado, ela faz com que os esforços se dispersem,
e um fork nem sempre leva a um produto melhor.

Funcionalidade
Antes de qualquer outra consideração, é importante relacionar
todas as funcionalidades que o programa deve satisfazer. É
necessário pesar bem a questão das funcionalidades realmente
utilizadas, quando comparadas com aquelas presentes em um
software proprietário que esteja sendo utilizado como referência.
Por exemplo, muitos podem argumentar que o OpenOffice.org
não tem suporte aos macros do MS-Office - mas sua organização
realmente usa muitos macros complexos que não possam ser escritos
novamente para o Openoffice.org? Ela pode nem usar macros.

Alguns fatores importantes são a compatibilidade com formatos

de dados em uso na empresa, no caso da integração com outros
sistemas. O sistema operacional que deverá rodar, levando em
consideração a questão do uso híbrido (veja nota).

Uma vez que o preço do hardware continua caindo, enquanto

o custo do software aumenta, é bom estudar se não vale a pena
comprar um novo computador para rodar em separado uma
solução software de código aberto que só tem versão para Linux
ou BSD. Um exemplo pode ser a necessidade de um servidor
web - o preço de um PC rodando BSD é mais barato do que
adquirir uma solução de software proprietário para rodar em uma
máquina existente. E caso seja necessário comprar um servidor
novo, a economia em não comprar um software proprietário
para o servidor pode ser usada para comprar um hardware mais
potente (ou mesmo um disco maior e mais memória).

Unidade 4 87

software_livre.indb 87 28/06/11 10:58

 Universidade do Sul de Santa Catarina

O que é um Macro?

Um macro é uma sequência de comandos que pode ser reutilizada.

É interessante para evitar que operações repetitivas sejam
executadas manualmente muitas vezes. Macros podem ser também
bem complexos, aproximando-se a uma linguagem de programação.

O que constitui o “Uso Híbrido”?

O uso de software de código aberto não impõe uma relação

tudo ou nada. Ou seja, é possível utilizar soluções proprietárias e
software de código aberto simultaneamente. É sempre bom levar
em consideração que muitas soluções software de código aberto
são desenvolvidas para mais de uma plataforma (Windows,
Linux etc.). Isto significa que usar um programa de código aberto
não obriga, na maioria das vezes, o usuário a usar uma outra
plataforma diferente daquela a que está acostumado.

Na verdade, todos usam software de código aberto no seu dia a dia.

Isto acontece principalmente quando a internet é utilizada. Perto
de 48% dos portais na WEB estão hospedados em servidores que
utilizam o APACHE (NETCRAFT, 2007). Outros programas
muito utilizados são Sendmail – servidor para envios de e-mail;
Bind – programa que associa nomes de domínios com endereços
IP. A internet só existe hoje em dia graças aos padrões abertos
utilizados e pela quantidade de softwares de código aberto que
foram escritos em concordância com estes padrões.

O que é o Suporte?

88

software_livre.indb 88 28/06/11 10:58

 Software Livre

Uma das preocupações no uso de qualquer software é se, no

momento de um problema, haverá alguém para ajudar. No caso
do software proprietário, o suporte, como tudo mais, é incluído no
preço do produto, o que quer dizer que a empresa fornece o suporte
por um determinado tempo e limitado em um ponto (em alguns
casos o suporte tem de ser comprado em separado). É sabido que
o suporte oferecido pelas empresas de software proprietário não é
grande coisa e, cada vez mais, a internet é o local onde se procuram
respostas para os mais diversos tipos de problemas.

O mais comum, para qualquer tipo de software, é encontrar uma

comunidade de usuários que mantém um fórum de discussões
sobre o produto. Os próprios fabricantes de software proprietário
estão utilizando este tipo de solução, construindo suas bases de
conhecimento com a ajuda dos usuários e suas dificuldades. Neste
sentido, o software de código aberto leva uma vantagem, já que,
naturalmente, um projeto gira em torno de uma comunidade de
usuários, na qual muitos são também desenvolvedores. Ao relatar um
problema, as chances de se receber ajuda de um dos desenvolvedores
é grande. Se a solução envolve a modificação do programa, é
possível que a comunidade prontamente modifique o software. É
possível dizer que os fóruns de discussão fazem parte do projeto do
software de código aberto, uma vez que a internet é o ambiente de
desenvolvimento do produto. Isto não acontece tão facilmente com
o software proprietário, pois esconder o jogo é parte da vantagem
competitiva da empresa, em que mudanças são contabilizadas no
custo do produto e lançadas como correções ou acrescentadas em
uma nova versão, com um novo investimento para o usuário.

Como suporte, pode ser incluída a disponibilidade de auxílio na

instalação do produto, no treinamento dos usuários e na solução
de problemas de uso.

Em resumo, temos quatro possibilidades de suporte para o

software de código aberto:

„„ o próprio projeto fornece suporte. Esta é uma forma de

manter o projeto, como visto no capítulo que trata de
modelos de negócio em software de código aberto (como
exemplo clássico: a distribuição linux RedHat);

Unidade 4 89

software_livre.indb 89 28/06/11 10:58

 Universidade do Sul de Santa Catarina

„„ a empresa pode se valer da comunidade que desenvolve o

produto;

„„ a empresa pode contar com mão de obra interna

interessada em levar o projeto adiante, recebendo
treinamento, se necessário;

„„ a empresa pode contratar um profissional ou uma

empresa dedicada a fornecer consultoria sobre o sistema.
No Brasil já existem empresas que prestam consultoria
na implantação de software de código aberto. Neste caso,
pode ser estratégico escolher a consultoria que conta com
alguém que participa no desenvolvimento do sistema,
pois a necessidade de alguma modificação no sistema
pode ser mais rapidamente atendida.

No sítio <http://ansol.org/servicos>, é possível encontrar

uma relação de empresas que prestam consultoria em SL.
No sítio <http://sourceforge.net>, também se encontram
profissionais e empresas oferecendo seus serviços
de consultoria, instalação e manutenção. Se você é
fornecedor de soluções, também pode se cadastrar lá.

Documentação
Cada vez mais a documentação que acompanha qualquer produto
diminui ou vai parar na internet. Também cresce a capacidade
de ajuda dinâmica embutida no próprio produto. Você já viu o
cachorrinho do MS-WORD ou se lembra dele?

Também são importantes na documentação do sistema os guias

de referência, a lista de perguntas frequentes (FAQ ), o manual
de instalação, livros, tutoriais etc. Além da disponibilidade, é
importante atentar para a qualidade.

Uma das críticas comuns ao software de código aberto era a sua

falta de documentação. Isto em parte se devia ao fato de que,
como não se vendia o produto, também não se vendia o manual
do usuário. Mas como este manual cada vez mais desaparece no
formato impresso, ele aumenta na forma eletrônica e diminui

90

software_livre.indb 90 28/06/11 10:58

 Software Livre

seu custo de produção. Assim como o software é produzido a

partir da colaboração de várias pessoas, também a documentação
se beneficia, aumentando sua quantidade e qualidade com o
tamanho da comunidade. Muitos projetos estão lançando mão de
wikis para manter a sua documentação.

Um problema com a documentação é geralmente sua existência

apenas em língua inglesa, mas muitos projetos mantêm hoje
em dia documentação alternativa em português. Dependendo
da estratégia da empresa que adota o produto de código aberto,
pode ser que a criação de tutorial, manual do usuário ou mesmo
a tradução para o português esteja dentro do orçamento. Como
todo projeto de software de código aberto, aqui também há uma
oportunidade de recorrer e também de se juntar à comunidade
para a criação de documentação em conjunto, enriquecendo
o produto, aumentando sua base de uso e, consequentemente,
contribuindo para a melhoria do projeto.

De qualquer forma, assim como no software proprietário,

há alguns projetos com boa documentação e outros não. É
comum autores independentes escreverem livros que auxiliam o
aprendizado e o uso dos mais diversos sistemas. No Brasil, muitas
editoras mantêm em seus catálogos livros nesta área.

Conclusão: os melhores projetos contêm muita documentação, o

que deve ser observado na tomada de uma decisão de adoção.

Confiabilidade
Como a geração de lucros não é um dos objetivos do software de
código aberto, ele não sofre com problemas de prazos de entrega.
Cada parte do software de código aberto pode ser trabalhada e
retrabalhada até que o objetivo final seja alcançado, sem que haja
preocupação com os custos que isto possa envolver. Mas, mesmo
assim, o ciclo de lançamento de novas versões tende a ser muito mais
rápido para o software de código aberto. Excetuando-se alguns
sistemas, a maioria dos softwares proprietários só incorpora novas
funcionalidades quando do lançamento de uma nova versão. Como
isto depende de todo um estudo de custo/benefício, orçamento,
estudo de mercado etc., a decisão de incorporar ou melhorar uma
funcionalidade acaba se tornando uma decisão gerencial.

Unidade 4 91

software_livre.indb 91 28/06/11 10:58

 Universidade do Sul de Santa Catarina

O projeto do software de código aberto, por outro lado, é

conduzido pelos desenvolvedores. Isto trás o benefício de não
haver contenção de esforços em funcionalidades que poderiam
não ter relevância mercadológica no software proprietário, mas
também pode levar a um prazo de maturação maior até que uma
nova versão seja considerada estável. É importante realçar que
muitos dos desenvolvedores de software de código aberto estão
interessados em criar algo para solucionar um problema próprio,
envolvendo eventualmente a empresa onde trabalha.

Um outro fator importante é a divulgação do código fonte. Isto

permite que muitas pessoas estudem o código à procura de falhas
de segurança. No processo de produção fechado de um produto
proprietário, um programador pode esconder em uma parte
de um sistema um código para algum propósito escuso. Como
um número restrito de colegas terá acesso ao código ou mesmo
nenhum acesso, este trecho pode ficar dormente por muito
tempo, até ser ativado, quem sabe, pelo próprio programador
quando deixar a empresa. Estes trechos de código são
denominados backdoor, e são utilizados para driblar os métodos
de autenticação que garantem a segurança de acesso a um sistema
computacional. Isto tem uma chance menor de acontecer em
um projeto de software de código aberto, pois geralmente um
número maior de programadores terão acesso e oportunidade de
descobrir o trecho malicioso.

Velocidade de lançamento de versões

Como visto anteriormente, o desenvolvimento do Linux e de
muitos outros softwares de código aberto utiliza o sistema bazar, em
que novas versões são lançadas rapidamente, possibilitando que a
comunidade ajude a levantar seus defeitos, realimentando o processo.

Logicamente isto não tem o intuito de utilizar o usuário final.

Geralmente as últimas versões contêm um aviso de que são
instáveis, e que são direcionadas a desenvolvedores ou usuários
mais “experimentadores”, mas não para serem utilizadas em
“produção”, termo que se usa quando o software entra em serviço.

92

software_livre.indb 92 28/06/11 10:58

 Software Livre

Como também foi visto, o desenvolvimento catedral é aquele em

que o produto só é lançado quando passou por um grande trabalho
de depuração interno, longe dos olhos dos usuários - o que nem
sempre é verdadeiro, pois forças de marketing podem obrigar ao
lançamento prematuro, no caso de software proprietário.

Com isto, o próprio usuário final é utilizado como “cobaia”,

depurando o sistema para o fabricante. Logo em seguida, são
lançados pacotes de correção, contendo consertos para muita
coisa que os usuários levantaram como problema.

As forças do mercado são tão fortes e interferem tanto no

desenvolvimento de um produto proprietário, que um grande
fabricante chega a lançar um produto que ainda não existe.
Ao longo da história do software isto ocorreu muitas vezes, no
que se denominou vaporware, visando matar algum produto
revolucionário de um concorrente menor lançado recentemente no
mercado. Com a promessa de um produto equivalente, os usuários
preferem esperar o lançamento do grande fabricante, matando a
pequena empresa que não consegue vender seu produto.

Para se ter uma ideia de como o software de código aberto

pode ser mais dinâmico, a Microsoft levou 6 anos para lançar
uma nova versão do Windows (Vista). A Apple, mais de 2 anos
para a nova versão do Mac OS X (Leopard). Nestes dois anos,
as maiores distribuições Linux lançaram 3 ou 4 versões cada
(TECHNOLEDGE, 2008).

Instalação e Atualização
No passado, uma das barreiras na aceitação do software de código
aberto era a necessidade de um grande esforço na instalação do
mais simples programa. Como o software de código aberto era
feito por desenvolvedores para solucionar problemas dos próprios
desenvolvedores, o procedimento era baixar um pacote de fontes,
configurar para a execução em sua máquina e finalmente criar
um executável a partir da compilação das fontes na própria
máquina. Para isto, era preciso também instalar ferramentas de
desenvolvimento, pois eram necessárias no processo de compilação,
bem como bibliotecas apropriadas, de onde o código compartilhado
tinha de estar presente para que o novo programa pudesse funcionar.

Unidade 4 93

software_livre.indb 93 28/06/11 10:58

 Universidade do Sul de Santa Catarina

Com o passar do tempo, a popularização dos sistemas

operacionais de código aberto e maturidade das ferramentas de
desenvolvimento fizeram com que a instalação de um sistema ou
programa de código aberto ficasse tão fácil quanto nos sistemas
proprietários. Hoje, além dos programas “clique para instalar”,
existem ainda gerenciadores de instalação que apresentam os
vários programas instalados, não instalados e as atualizações
automáticas, tanto para conserto de problemas (patchs) como
instalação de novas versões.

Um destes gerenciadores é o atp-get - Advanced Packaging Tool.

Este aplicativo de modo texto é nativo de sistemas Linux-Debian.
Usando um endereço na internet, denominado “repositório”, onde
os pacotes de softwares estão armazenados, ele é capaz de trazer
para a máquina o programa que estamos interessados em instalar,
bem como qualquer biblioteca necessária, ou “dependência”. Para
facilitar, existem aplicativos no modo gráfico, como Synaptic Package
Manager para o ambiente GNOME ou Kpackage (Figura 4.1) para
o ambiente KDE que eliminam a necessidade de decorar comandos.

Figura 4.1 - Ferramenta de instalação em Linux

Fonte: Captura de tela do programa em execução.

94

software_livre.indb 94 28/06/11 10:58

 Software Livre

Facilidade de uso
A passagem do modo texto para os ambientes de janela é um dos
fatores que popularizaram o uso do computador. As interfaces
com o usuário dos sistemas operacionais de código aberto,
notadamente GNOME e KDE, têm se aproximado bastante
dos seus equivalentes softwares proprietários. Vale lembrar que,
mesmo entre sistemas proprietários, como Windows e OS X
(sistema operacional da Apple), há discussões sobre a facilidade
de uso e a curva de aprendizado.

Um estudo conduzido em 2003 pela empresa alemã Relevantine

(RELEVENTINE, 2003), especializada em usabilidade de
software, apresentou resultados animadores com relação ao uso
do Linux em desktop. Dois grupos de usuários não técnicos,
sem experiência no uso do Windows XP e da distribuição
Linux SuSE, receberam uma lista de tarefas de um ambiente
de trabalho convencional, como processamento de textos e
troca de e-mails. Ao fim do teste, os usuários de Linux tiveram
88% da produtividade dos usuários de Windows. Atualmente,
os resultados seriam bem diferentes, pois as interfaces das
distribuições Linux evoluíram muito nestes cinco anos.

Recentemente, a distribuição Ubuntu tem recebido muitos

elogios em relação a sua facilidade de instalação e uso.

Gnome e KDE
Diferentemente do Windows, as distribuições Linux
permitem que o usuário escolha o ambiente gráfico
de interação com o usuário. Os dois projetos mais
populares, Gnome e KDE, esforçam-se para alcançar a
melhor usabilidade possível. Tanto uma quanto outra
têm vários aplicativos desenvolvidos especialmente
para elas, mantendo o look and feel (forma com que
os vários elementos da interface são desenhados e se
comportam) correspondente. No entanto é possível
rodar os aplicativos de uma na outra sem problemas.
Além destas, existem outras interfaces, mas não tão
populares e fáceis de usar. Uma delas, Window Maker,
foi desenvolvida por um brasileiro.

Unidade 4 95

software_livre.indb 95 28/06/11 10:58

 Universidade do Sul de Santa Catarina

Manutenção
Quase todos os programas existentes têm de sofrer modificações
com o passar do tempo, tais como correção de problemas,
inclusão de novas demandas dos usuários e aumento natural de
suas funcionalidades. A preferência na escolha é por projetos que
já têm algum tempo e estão continuamente sendo aprimorados.
Isto pode garantir que a adoção de um determinado produto
atenda às necessidades por muito mais tempo. Os portais
de divulgação de software de código aberto (Freshmeat,
SourgeForge etc) contêm dados para avaliar este aspecto – o
grau de vitalidade de um projeto. O exame dos fóruns do
projeto é outra forma de saber se o projeto tem sido modificado
ou corrigido de acordo com as demandas dos usuários. A
documentação, lançada em várias versões ou ativamente mantida
em um wiki, também é sinal de atualização do projeto.

Um projeto de software proprietário nem sempre garante sua

continuidade, em que sistemas são descontinuados e os usuários
“convidados” a adquirir uma nova versão, muitas vezes totalmente
incompatível com a anterior. O projeto de código aberto tem pelo
menos uma vantagem hipotética neste ponto: como é fornecido com
o código fonte, sempre será possível que alguém não deixe “morrer”
o software ou mesmo permita que o usuário mantenha o produto.

Custos
Os custos de adoção da solução sendo analisada é também um dos
fatores a serem considerados. Como já foi visto, o software de código
aberto não é sinônimo de gratuidade, mas, mesmo com economia
de licenças, há outros fatores a serem analisados. Como é um tópico
complexo, deixamos sua apresentação para a próxima unidade.

Experimentação
Há circunstâncias em que fazer uma instalação para ver como
se comporta o produto é uma alternativa, ajudando também a
ter uma noção de funcionalidades e características importantes

96

software_livre.indb 96 28/06/11 10:58

 Software Livre

que o produto deve apresentar. Uma empresa que ainda não

tenha, por exemplo, instalado um servidor web, pode optar por
montar um servidor e tentar configurá-lo para suas necessidades,
avaliando o quanto o produto satisfaz as necessidades da tarefa.
Com os dados levantados, torna-se mais fácil verificar o que
outros produtos devem, ou não, apresentar como características
adequadas ao projeto.

O uso de produtos de código aberto é a maneira mais fácil de

fazer isto, uma vez que evita o comprometimento com gastos em
software, e as experiências podem ser conduzidas geralmente com
hardware inferior àquele necessário para produtos proprietários.
Estes projetos pilotos são importantes para tirar dúvidas também
de como se comportarão os usuários finais.

Segundo Winslow (2004), um projeto piloto em uma empresa

pode ser conduzido iniciando-se com servidores. Com isto, a
equipe de TI ganha experiência com a instalação de sistemas
de código aberto, sem que o usuário final perceba. Um serviço
transparente para o usuário, que é um bom ponto de partida, é
o servidor de e-mail. Um projeto piloto pode ajudar também a
convencer colegas relutantes a experimentar soluções de código
aberto. Um pouco mais ousada é a introdução no Desktop.
Uma forma de fazer isto é designar para um funcionário
recém contratado uma estação de trabalho Linux, munida de
OpenOffice.org como ferramenta de escritório.

Analise, a seguir, um estudo de caso!

Substituição de ferramentas de escritório em grande

organização
Há situações em que a introdução de uma solução com código
aberto deixa de ser satisfatória não por problemas relacionados ao
produto, mas sim por treinamento oferecido e cultura instalada.

Há alguns anos, uma empresa de relativo porte, com

aproximadamente 700 funcionários na parte administrativa,
se viu no meio de um campo de batalha: algumas empresas
de mesmo tamanho na área geográfica de uma de suas filiais
estavam sendo visitadas por representantes de um fabricante de

Unidade 4 97

software_livre.indb 97 28/06/11 10:58

 Universidade do Sul de Santa Catarina

software e recebendo pesadas multas por não terem adquirido

licenças de vários produtos.

A empresa possuía algumas licenças, mas, com o forte

crescimento por que tinha passado e a alta de cultura no controle
de licenças, não teve preocupação em atualizar o número de
cópias regulares. E o alerta foi disparado. Como solução de
emergência, o produto StarOffice, antecessor do OpenOffice.org,
foi instalado em toda uma unidade da empresa, com a aquisição
de uma licença de US 1000 anuais (uma bagatela na época, em
relação ao concorrente).

Praticamente todos os usuários da unidade receberam um

treinamento básico sobre como usar as ferramentas, mais a
apresentação de algumas diferenças existentes em relação ao
produto proprietário. Dentro de pouco tempo, todos estavam
acostumados com a ferramenta e não havia reclamações, pelo
contrário, havia um forte apoio dos empregados.

No entanto, nem as outras unidades nem os dirigentes da

empresa efetuaram a troca para o novo produto. Isto causava,
de vez em quando, reclamações quanto à formatação de alguns
documentos, pois a compatibilidade de formatos não era tão boa
naquela época, sem contar que o StarOffice tinha de ser instruído
a gravar no formato do Word, mas muitos se esqueciam disto.

Durante este período, houve uma mudança na direção de TI da

empresa. Em lugar de ampliar o treinamento, incluindo a direção
e outras unidades, o novo diretor, que vinha de uma empresa
integralmente servida por produtos proprietários, terminou por
abortar o experimento e reservar uma grande parte do orçamento
para a compra de licenças. Isto mostra que, muitas vezes, aspectos
culturais e organizacionais são determinantes para o fracasso de
um experimento com potencial de completo êxito.

Metodologias de seleção
O que foi apresentado até aqui nesta unidade é uma compilação
de itens comuns de análise. Existem, no entanto, metodologias
destinadas à escolha de software de código aberto. As

98

software_livre.indb 98 28/06/11 10:58

 Software Livre

metodologias procuram formalizar o modo como as características

do produto são consideradas, como são analisadas e identificar
pontos em que partes do produto necessitam melhorias.

Exemplos de metodologias criadas especificamente para código

aberto:

„„ Navica/Golden Open Source Maturity Model.

„„ Capgemini Open Source Maturity Model.

„„ Business Readiness Rating.

Como exemplo, a primeira metodologia acima é apresentada em

alguns detalhes (GOLDEN, 2005).

Seção 3 – Modelo de maturidade do produto de código

aberto
Uma destas metodologias é o modelo de maturidade de código
aberto (Open Source Maturity Model - OSMM).

O método OSMM verifica a maturidade de um produto em três

fases:

„„ fase 1 - verifica a maturidade de cada elemento do

produto e associa um valor;

„„ fase 2 - define um peso para cada elemento, baseado nos

requisitos da empresa que vai utilizar o produto;

„„ fase 3 - calcula uma nota geral de maturidade.

Unidade 4 99

software_livre.indb 99 28/06/11 10:58

 Universidade do Sul de Santa Catarina

A tabela 4.1 é utilizada para as anotações e cálculos da

metodologia OSMM.

Tabela 4.1 - Formulário de inspeção OSMM

Fase 1 - verifica a maturidade dos elementos Fase 2 Fase 3

Define os Localiza Verifica as Associa Peso Resultado
requisitos recursos maturidade uma nota
Produto 4
(software)
Suporte 2
Documentação 1
Treinamento 1
Integração 1
Consultoria 1
Fonte - Adaptado do exemplo do template traduzido pelo autor de Navica Inc (2004 - 2007).

Os pesos da fase 2 são determinados em relação à importância do

item na análise do produto. Por exemplo, se o item documentação
é mais importante do que ter disponível um treinamento para
o produto, então ele deve receber um peso maior. No caso da
escolha de um servidor web, que será utilizado por técnicos,
o treinamento pode ser menos importante que uma boa
documentação, e, talvez, mesmo em português. Neste caso,
pode-se aumentar este peso para 3, ajustando o suporte para 1
e os itens treinamento e consultoria para 0,5. O somatório desta
coluna deve ser sempre 10 (Tabela 4.2).

Tabela 4.2 - Ajustes dos pesos

Peso
Produto 4
(software)
Suporte 1
Documentação 3
Treinamento 0.5
Integração 1
Consultoria 0.5
Fonte: Adaptado do exemplo do template traduzido por Navica Inc (2004 - 2007).

100

software_livre.indb 100 28/06/11 10:58

 Software Livre

Segundo Golden (2005), a análise de maturidade utilizando esta

metodologia pode ser conduzida por duas pessoas em não mais
do que três ou cinco dias.

Para cada item de análise, o máximo de pontuação deve ser 10.

Na tabela 4.3 o template está vazio, mas indicando o máximo de
pontuação na avaliação.

Tabela 4.3 - Template para avaliação

Maximo possível Nota atribuída Peso Resultado

Produto 10 4 40
(software)
Suporte 10 1 10
Documentação 10 3 30
Treinamento 10 0.5 5
Integração 10 1 10
Consultoria 10 0.5 5
Grau de maturidade do produto 100

Fonte: Adaptado do exemplo do template traduzido por Navica Inc (2004 - 2007).

Para cada item de avaliação (fase 1), a metodologia fornece um

template. O template apresenta a pontuação máxima do item, que
é 10, e uma subpontuação para características do elemento que
servem de avaliação.

A tabela 4.4 apresenta um exemplo para o item documentação.

Neste caso, três características servem de parâmetros: a
disponibilidade de documentação escrita pelo autor do produto;
se esta é disponível na web; e se também está disponível na forma
de um livro ou tutorial comercial. Para cada característica, há
uma nota que revela sua importância para a escolha do produto.
Logicamente que estes itens podem ser alterados de acordo com o
produto e a importância da característica na avaliação do produto
para determinada utilização. O importante é aplicar os mesmos
parâmetros para produtos de fornecedores diferentes, tornando a
análise significativa.

Unidade 4 101

software_livre.indb 101 28/06/11 10:58

 Universidade do Sul de Santa Catarina

Open Source Maturity Model

Template para avaliação da maturidade da documentação OSMM

Pontuação potencial

Figura 4.4 - Template para avaliação da documentação

Tipo Valor
Criada pelo desenvolvidor 2
Disponível na web 3
Publicado de forma comercial 5

Pontuação máxima 10

Avaliação
Método notas

Criada pelo desenvolvidor

Disponível na Web

Publicado de forma comercial

Fonte: Adaptado de Navica Inc. (2004-2007).

Em relação às notas, é útil descrever mais detalhadamente a

fonte da documentação. Por exemplo: se há um livro publicado
que documenta o produto, é interessante anotar seu título e
nome do autor.

Estas notas são repassadas para o template de avaliação (Nota

Atribuída - Tabela 4.3). Na fase 3, são realizados os cálculos para
determinação do grau da maturidade do produto. Este valor pode
ser comparado às análises conduzidas em outros produtos, a fim
de determinar uma possível escolha.

No endereço <http://www.navicasoft.com> estão disponíveis

os outros templates, bem como alguns exemplos de avaliações
conduzidas.

102

software_livre.indb 102 28/06/11 10:58

 Software Livre

Síntese

Como foi visto nesta unidade, a seleção do software de código

aberto requer a análise de vários fatores. Como ponto de
partida, é essencial levantar as necessidades que o sistema deve
suprir e identificar soluções candidatas, realizando uma análise
superficial. Para este garimpo, podem ser utilizados sítios
especializados em software de código aberto, a consulta a colegas
de profissão sobre o que usam e o que recomendam, e também
recorrer a avaliações na imprensa técnica, tanto divulgadas pela
internet como revistas. Uma lista de soluções clássicas e já muito
testadas também pode conter o que se procura.

A seguir é necessário fazer uma avaliação mais detalhada,

comparando as soluções candidatas em relação às suas
funcionalidades, ao suporte disponível, à documentação, à
confiabilidade, à facilidade de instalação, à facilidade de uso,
à manutenção e, por fim, aos custos envolvidos na adoção ou
migração de uma solução proprietária para uma solução software
de código aberto.

Também existem metodologias mais formais de análise que se

utilizam dos mesmos itens abordados, mas que quantificam estes
itens, segundo pesos associados às necessidades do utilizador do
produto. O OSMM - modelo de maturidade de código aberto é
uma destas metodologias.

Na próxima unidade, o item custos será mais explorado, pois

se trata de um dos pontos que mais impactam a adoção de uma
solução, tanto de código aberto como proprietário.

Unidade 4 103

software_livre.indb 103 28/06/11 10:58

 Universidade do Sul de Santa Catarina

Atividades de autoavaliação

1.) Escolha um software qualquer em uso em sua empresa e construa uma

tabela com pelo menos três colunas. Na primeira, disponha em linhas
funcionalidades desejadas e/ou presentes no programa utilizado hoje
em dia. Nas outras duas ou mais colunas, indique a existência, ou não,
das funcionalidades, ou o quanto este item é bem feito.
Exemplo:

Audium Messenger Miranda

Áudio Não Sim Não

Vídeo Não Sim Não

Ícones costumizáveis Sim Limitado Sim

Cores costumizáveis Sim Limitado Não

Suscetível a vírus Pouco Muito Nenhum

Inserção indesejada de propaganda Não Sim Não

2.) Entre em um dos sítios que hospeda software de código aberto e

pesquise a existência de alternativas para o Outlook Express. Para cada
produto identificado, anote há quanto tempo o projeto existe.

104

software_livre.indb 104 28/06/11 10:58

 Software Livre

3.) Identifique na internet um projeto que mantém sua documentação em

uma ferramenta wiki. Este projeto tem uma boa taxa de atualização?

Saiba mais

Para aprofundar seus conhecimentos:

No endereço a seguir estará disponível em português um artigo
de apresentação do Modelo de Levantamento para Avaliação de
Preparo para Negócios (Business Readiness Rating).

<http://www.openbrr.org/wiki/images/5/59/BRR_
whitepaper_2005RFC1-pt-BR.pdf>.

Entre no endereço a seguir para baixar um documento sobre a

metodologia de seleção de produtos de código aberto Capgemini:

<http://pascal.case.unibz.it/retrieve/1097/GB_Expert_Letter_
Open_Source_Maturity_Model_1.5.31.pdf>.

Outra metodologia é a Qualification and Selection of Open

Source software (QSOS). Visite o endereço <http://www.
qsos.org/> para conhecê-la. Esta metodologia é protegida pela
licença GNU Free Documentation GFDL - uma licença para
documentação irmã da GPL.

Unidade 4 105

software_livre.indb 105 28/06/11 10:58