Economia de Software Livre
UFCG / CCT / DSC
© J. Antão B. Moura
[email protected]
Alguns dados de mercado
• Projeções da IDC:
– A taxa de crescimento do Linux tem sido maior
que a somas das taxas dos outros S.Os.
– Apache (webserver desenvolvido por grupo de
webmasters na Internet) tem 61% do mercado
Alguns pacotes de SL populares
• Para o servidor
–
–
–
–
–
Linux
Apache
Samba
Sendmail
MySQL
• Para o desktop
– KDE
– Gnome
• Outras ferramentas (principalmente AE – como
OpenOffice) continuam pouco acessíveis para
leigos em Informática
Características naturais de software
• Software
– Bem durável (não se desgasta) e
– de uso concorrente (uso por um usuário não
impede uso por outro, simultaneamente – ao
contrário do hardware, um PC desktop, por
exemplo).
• Software proprietário (como MS-Office)
não tem respeitado estas características
Software Livre (SL)
•
•
Software Livre ou (de Código) Fonte-Aberto respeita
características naturais do software
3 liberdades no licenciamento de SL
1. Adquirir o software gratuitamente para uso próprio;
2. Fazer cópias e distribuir estas cópias à vontade
internamente ou para terceiros, desde que grátis e
informando sobre os direitos autorais dos seus
desenvolvedores (iniciais e contribuintes de
aperfeiçoamentos);
3. Ter acesso ao código fonte do software para estudá-lo ou
modificá-lo, com vistas à correção ou aperfeiçoamento
funcional ou de desempenho e (re)distribuir o código
modificado para quem estiver interessado, gratuitamente
(Debian Free Software Guidelines, 1997 – www.opensource.org).
“Costumes” de SL
• Regras não escritas para “posse”
– Definem quem pode modificar um software, em quais
condições e quem tem o direito de re-distribuição
– Dono é que tem direito de distribuir versões modificadas
• Tabu contra “forking” de projetos (só em casos de
necessidade extrema, com explicações públicas e
transferência de posse)
• Tabu contra menosprezar trabalhos dos outros
• Violadores dos costumes são acusados e condenados
em público e passam a ser recusados para
cooperação
Desenvolvimento de SL
• Grande número de voluntários
• Internet como veículo de comunicação /
sincronização
• Qualidade atingida por releases e testes e
feedback freqüentes, na rede
– Ex: Linux de Linus Torvalds (Finlândia)
Processo distribuído de
desenvolvimento de SL
“I’m basically a very lazy person who likes to
get credit for things other people actually do”
Linus Torvalds
“Too lazy to fail”
Robert Heinlein, escritor
Engenharia de Software Livre
• Existência de gerente (coordenador) – responsável pela
seleção / adoção de contribuições de design, código,
detecção de bugs, para oficialização de release(s)
– “Dono” do projeto (quem o iniciou)
• “Sem” prazo – apenas pressão / concorrência dos pares
– Linux experimental: lista de funcionalidades desejadas
implementadas eventualmente (prazo: quando acabar)
– Linux estável: releases em intervalos regulares, mas sem
prazo para consertar bugs ou quais funcionalidades serão
incorporadas do experimental
• “Sem” orçamento – tempo (recurso econômico) dos
“hackers”
Engenharia de Software Livre
• Competência + “Lei dos Grandes Números”
• Boas práticas ao “extremo”
– Especificação, codificação e testes por usuários-especialistas
(software básico, ferramentas, ...)
– Modularização (interesse em módulo particular)
– Múltiplas implementações de um módulo
– Vários processos de desenvolvimento individuais
• Programadores fazem o que gostam (e bem!)
– Releases freeqüentes
• Release vira “protótipo” para depurar inclusive, especificação
– Revisão e escolha descentralizadas por pares (gerente e
outros “hackers”)
– Testes por “milhares de usuários” (mundo todo)
Testes em ESL
• Grande número de usuários detecta defeitos mais
rapidamente, mesmo os mais “estranhos”
– Efeito Delfi em Sociologia: a opinião média de uma massa
de especialistas (ou ignorantes) é um previsor mais confiável
do que a opinião de um observador escolhido
aleatoriamente.
– Duplicação de trabalho não é “custosa” (tempo de
voluntários que terão benefício do uso do software)
– LGN aumenta probabilidade de localização de defeitos
– Testador de SL (com fontes) é “mais especialista” do que
usuário típico de SP
Pré-condições para o sucesso
E. Raymond em “The Cathedral & The Bazaar”
• Promessa plausível: Programa inicial pode ter
bugs, incompleto e mal documentado; mas,
deve rodar e convencer seus potenciais
colaboradores que ele evoluirá para algo
arrumado e útil em futuro próximo.
• Coordenador deve ser capaz de reconhecer
“boas idéias de design dos outros”
SL X SP
• SL aloca mais recursos a um problema do que SP
• Recursos de SL mais motivados – são voluntários
(gerente tem que motivar pessoal de SP)
• SP com prazos e consumo de orçamento críticos
• Comunidade SL prospera na glória / reputação (gift
culture)
– Não se menospreza contribuição; escolhe-se a melhor
• Contraste com academia onde a fama é alcançada às vezes, com
“exposição de deficiências em trabalhos dos outros”
• Você alcança reputação através de reconhecimento dos outros
• Comunidade SP prospera na grana (cultura comercial)
Evolução dos tipos de projetos SL
• Década de 70: demos, jogos
• Década 80: Ferramentas para Internet
• Década 90: S.O. (atualmente com atividades de
desenvolvimento para drivers de dispositivos e extensões)
• Agora + futuro: Aplicações para não-técnicos em
Informática
– Ex: GIMP (gimp.org), um pacote tipo Photoshop com GUI
amigável
• Medida de intensidade de interesse
– Número de submissões / anúncios de novas releases em
www.freshmeat.net
– Preocupação da Microsoft: Documentos Halloween
(opensource.org/halloween/)
Negócios com Software
• Decisão de compra influenciada pela percepção
futura de (continuidade de) prestação de serviços
– Ex: Conversão para GNV (no único fornecedor em
Campina Grande) no posto Dallas
• Serviços em SL: instalação, treinamento,
melhorias (upgrades), suporte técnico e projetos
complementares
– Ex: Linux
• A indústria de software é de serviços (e não
“fábrica”)
– Pagamento de ISS
Tendências nos negócios com SW
• Desenvolver tecnologia é lento e caro
• Fluxo contínuo de valores / serviços e
receita entre fornecedor e cliente
– Crescimento do setor “serviços” com custo de
aquisição baixando (maior base instalada)
– Continuação de tendência de preços de software
(contrato -> pacote -> aluguel -> gratuito)
• Aumento de demanda por especialistas em
desenvolvimento
Economia de SL
• Maioria dos artigos sobre SL destaca o “bem” (ou
“mal”) de SL – P&B.
• Do ponto de vista econômico – Cinza
– SL pode ser bom para certas coisas e menos bom para
outras
• Empresas estão de alguma forma, envolvidas com
SL (muitas vezes como fornecedoras de pacotes)
– Dependendo da origem, pessoas evitam falar bem ou
mal
– Ter gente que entenda de licenças de SL para evitar
problemas legais na comercialização
Como ganhar $ com SL?
• No final da década de 90, algumas
fornecedoras de GNU/Linux
– Red Hat, VA Linux, Slackware, ...
– Apesar de vendas de ações bem sucedidas,
maioria fechou por falta de receitas suficientes
para suportar operações (exceto RedHat)
• Linux é bom no servidor, para
desenvolvimento Web, mas não tão bom no
dsktop
Software Livre no / como negócio
1. Quais as principais diferenças de Software
Comercial (proprietário)
2. Como usar SL para montar um negócio
(agregação de valor + prestação de
serviços)
Características SL
• Download e (re-)instalação de múltiplas cópias gratuitas
– Atrativo de baixo custo de aquisição
– Considerar porém, o custo de posse
• Treinamento
• Perda de produtividade
• Suporte
• Características do desenvolvimento já discutidas...
– Inicialmente desenvolvido por um único programador ou
pequeno grupo de programadores
– Sucesso atrai outros desenvolvedores
• Criação e funcionamento de “comunidade”
Características SL
• Equipe trabalha de forma distribuída, com as mais
diversas filiações
– Tempo cedido voluntariamente ou pago
– Funcionalidade evolui em função dos interesses dos
desenvolvedores (e não, dos “usuários”)
• Evolução direcionada por quem tem mais tempo a dedicar (a
desenvolvimento, discussões nas listas, ...)
• Possíveis desvios da “arquitetura” definida por autor(es)
• Perigo de inserir código com © de terceiros
– “SAC” pode ser demorado ou até, inexistir
Características SP
• Desenvolvido de forma centralizada, sob controle
de uma empresa, facilitando:
–
–
–
–
–
definir e seguir roadmap para evolução
aderência à arquitetura
pressão para cumprir prazos e orçamento
documentação / help / usabilidade (para aliviar suporte)
distribuição por cópias binárias
• evita compilação
• simplifica configuração, integração, testes
Diferença importante: Licenciamento
• “Software Livre” ≠ “Software Grátis”
• Cuidado!
– Consulte advogado / empresa que já adota SL
• Para informações sobre várias formas de
licenças de SL
– www.opensource.org
Tipos de Licenças
• SL no domínio público: não há restrições de uso
• GNU General Public License (GPL)
– Richard Stallman da Free Software Foundation
– Permite (re-)distribuição e qualquer alteração / evolução desde que
novo código-fonte seja disponibilizado sem restrições caso cópias
binárias sejam liberadas ou vendidas
– OBS: Apesar de GPL não restringir modificações para uso próprio,
pode ser complicado vender software que inclua ou que seja derivado
de software GPL.
• Bibliotecas com licença GNU Lesser General Public License (LGPL)
• Licença BSD
– © por (organização) autor(a) do código-fonte
– Permite modificações e redistribuição fonte / binário
– Algumas limitações (sem nenhuma garantia, ...)
Tipos de Licenças
• “Pílula de veneno” (poisson pill)
– Licença mista
– Fornecedor disponibiliza software (um BD, p.ex) sob
um tipo de licença (GPL, ...)
– Programa (p.ex., aplicação) desenvolvido a partir do
software (ou que use o software de alguma maneira)
deve:
• [disponibilizar todo código-fonte E ceder os direitos para
o fornecedor] OU então,
• [pagar pela licença], caso contrário
– Ex.: Berkeley BD (GPL) da Sleepy Cat Software
– Possível se autor detém direitos sobre o software ou se
software é uma evolução de SL sem GPL
Tipos de Licenças
• Netscape Public License (NPL)
– Aplicada ao browser Mozilla contra a Microsoft
– Distingue entre modificações e novo código
• Modificações, consertos de bugs e melhorias em código já
existente devem distribuir os fontes livremente
• Código novo pode ser (ou não) reservado como proprietário
• IBM PL
– Semelhante à NPL
Negócios com $L
• Clientes corporativos acostumados com
“facilidades” características de SP (vs. $)
• Modelos de negócios com SL oferecem
conveniência e/ou agregam valor esperados
pelo mercado para geração de (fluxos de)
receitas
Negócios possíveis com SL
• Distribuição (cópias binárias, já compiladas para
certas plataformas)
– Walnut Creek: CD-ROM com binários de SL em domínio
público ou “freeware”
– Downloads da Web reduziu interesse no CD
• Integração
– Software: Núcleo SO + drivers + utilitários
interessantes + BD + ...
• CD é atraente para guardar backup, re-instalar, etc
• Red Hat, Sleepy Cat Software (Berkeley DB)
– Hardware: SO + BD + Aplicações já no servidor
• IBM com Linux em toda a sua linha de hardware (U$1.5B em
2002)
Negócios possíveis com SL
• Suporte
– Suporte de linha-de-frente é suportado por suporte
de retaguarda (Engenharia)
– Se fornecedor não controlar software que suporta
pode não ter como consertar defeitos (inexistência
de Engenharia)
• Documentação
– Livros, manuais, tutoriais
– Ex.: O´Reilly Associates
• Treinamento
– Cursos presenciais, EaD, Conferências
Negócios possíveis com SL
• Outsourcing
– Contratos de desenvolvimento de software (com SL como
base)
– Contratos podem ser exclusivos ou permitir contribuição para
o código-fonte do SL base ou (re-)distribuição
• Base com GPL e se produto contrato for para venda, fontes devem ser
disponibilizados
• Venda de pacotes (bundling)
– Linux (que continua livre) + Aplicações pagas
• Ex: Red Hat
• Venda de Extensões de SL
– Extensões em termos de desempenho, capacidade, segurança,
...
– OBS: Fornecedor deve ter © sobre o SL base
– Open Office da Sun
Oportunidades ...
• SL pode acelerar criação do negócio
– Perfil técnico de autores polarizam ofertas SL para
software básico (SO, BD, ferramentas, ...)
• Ex: Linux, PostgreSQL, Jakarta Tomcat (Web/app
server)
• Oportunidades em substituição de máquinas Unix-RISC
por Linux-Intel
• Oportunidades em serviços de migração WINTEL para
LINTEL
– Oportunidades em aplicações
... e ameaças
• SL torna a barreira de entrada (concorrência)
no novo negócio criado, mais baixa
• Restrições legais / contratuais da licença
– Cuidado para código protegido por propriedade
intelectual não acabar dentro do código-fonte do
SL
• SCO x Linux (2003)
O Valor de SL
• Tema de investigação
– Ex: Projeto Free ROI (UFCG/DSC – CHESF)
• Medida freqüente é TCO (Total Cost of Ownership)
– Levantamento de TCO depende da situação e de vários
fatores
– Cuidado com interesses nos “estudos”
• Estudo da IDC em 2002 encomendado pela Microsoft deu
vantagem ao Windows (x Linux)
– Valor dos profissionais Windows treinados pela Microsoft mais
“baratos” e podendo cuidar de “mais servidores”
– Estudos independentes posteriores demonstraram o contrário!
O Valor de SL
• Fatores que afetam TCO:
–
–
–
–
–
–
–
–
–
–
Tamanho da rede corporativa e número servidores
Mix de aplicações
Tipos de processadores
Necessidades de upgrade
Treinamento
Custo de administração
Custo de Licenças
Suporte
(Perda de) produtividade
Sistemas e arquivos herdados
Comparação Linux, Windows
• Cybersource (2002): TCO (US$)
SO
Ano1
Ano2
Ano3
Linux
49.931
62.203
74.475
Windows
91.724
141.193
190.662
Bibliografia
• Eric. S. Raymond - “The Cathedral & The Bazaar
– Musings on Linux and Open Source by na
Accidental Revolutionary”, O’Reilly, 2001, 241
pp.
• ACM Queue Magazine – “The business of Open
Source – When two worlds collide”, Vol. 1 No. 5,
July / August 2005
• Cutter Information LLC – “Open Source – Moving
into the Enterprise”, Special Report, Cutter
Consortium (www.cutter.com), 2003, 96 pp.