Economia de Software Livre

UFCG / CCT / DSC© J. Antão B. Moura

antao@dsc.ufcg.edu.br

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.