Modelo de negócios
A primeira avaliação a ser feita nesta análise é sobre o modelo de negócios de sua empresa.
O modelo de "venda de caixinhas" já está visivelmente em decadência.
Praticamente, só os líderes estabelecidos em seus respectivos mercados
ainda têm condições econômicas e ecossistêmicas, e lutam
desesperadamente, para manter tal modelo. Progressivamente está ficando
cada vez menos lucrativo, mais desgastante em termos de imagem de
mercado, juridicamente, politicamente até, mantê-lo. Leia as notícias
deste blog e esta
série de artigos para acompanhar este assunto.
Atualmente, em junho 2008, e enfatizo o aspecto temporal, o ambiente
está mostrando como dos mais exitosos modelos de negócios em software
livre e proprietário, a prestação de serviços. Não é o único a ter
resultados positivos, mas é o que está resultando mais rápido e mais
lucrativo.
Software como Serviço, serviços agregados, e demais variações sobre o tema básico:
serviços.
Serviços são mais difíceis de copiar, envolvem um contexto personalizado e têm elevada barreira de substituição,
desde que o cliente seja suficientemente bem atendido em suas necessidades.
É mais difícil "piratear" serviços.
Mas também exige permanente evolução, aprimoramento e,
talvez, diversificação, SEMPRE à frente da concorrência, para manter uma "distância", uma vantagem segura para os negócios.
Algumas empresas, públicas ou privadas, estão num contexto
excepcional para alavancar a prestação de serviços, devido ao porte,
abrangência geográfica ou de áreas econômicas, até mesmo jurídicas, e
podem implicitamente "cativar" o cliente de tal forma que um concorrente
teria enormes dificuldades em atender melhor o cliente.
Tipo de software a abrir
A segunda avaliação é sobre o tipo de software que poderia ser aberto.
Atualmente, junho 2008, programas de infra-estrutura, algum middleware, frameworks. Basicamente,
o que NÂO seja diferencial de negócio. Mas nem sempre.
Para exemplificar, vamos imaginar a seguinte situação:
Sua empresa fechou um contrato de terceirização de toda a área de Tecnologia da Informação de um grande cliente.
Você se dirige ao corpo funcional e anuncia: "Vamos inventar o nosso
próprio sistema operacional, ou pesada adaptação de algum, nosso próprio
sistema de arquivos, nosso próprio sistema gerenciador de banco de
dados relacional, nosso próprio servidor web, nossa própria suíte de
automação de escritórios, nosso próprio formato de arquivos, para
começar. Depois veremos as particularidades de negócio do nosso
cliente." "Ah, e também vamos inventar nossos próprios computadores,
dispositivos de rede e protocolos de comunicação".
Percebeu como muito dificilmente haveria um contexto onde tais afirmações não constituissem um absurdo inviável?
Alguns momentos de ponderação e você perceberá que há alternativas
estabelecidas e suficientes para atender as necessidades, que não são
diferencial de negócio.
Muitos projetos
de código livre incorporam milhares de homens hora de altíssima
qualificação em esforço significando bilhões de dólares em
investimentos. Não há mais oportunidades de bons lucros aí. Sua empresa
precisa minimizar os custos, repartindo o risco, o esforço de elaboração
e manutenção destes programas de infra-estrutura.
Mas e os outros programas voltados ao negócio do cliente?
Agora entra a habilidade da engenharia de software em criar boas
arquiteturas e métodos que viabilizem tornar a maior parte do esforço e
risco necessários em algo que
NÃO seja diferencial de negócios.
Resumindo:
frameworks, middlewares, desenvolvimento declarativo.
Alguns exemplos são: Java
Spring framework, Php
Zend framework,
Pentaho, JBoss Rules (
Drools).
Deslocando o máximo possível de esforço para código que não seja
diferencial de negócios, sua empresa pode repartir os elevados riscos de
desenvolvimento, os custos, o tempo, agregar mais conhecimento,
aprimorar o programa, obter melhoria de conceito até. Leia mais no
artigo
aqui.
Qual a hora certa de abrir o código?
Depende da situação do seu modelo de negócios atual, do seu próximo
modelo de negócios, da sua cultura interna, da maturidade de seu código
disponível e de seu conceito (respeitabilidade) na comunidade.
Antes de mais nada, estude a seguinte leitura obrigatória:
Agora que você já estudou os artigos citados, considere na sua análise o seguinte:
- Qual a cultura interna da sua empresa? É alinhada com os valores
básicos do software livre: qualidade e excelência, conhecimento e
compartilhamento, fluxo de informações, aprendizado, honestidade
cristalina?
- O modelo de negócios é ou será de serviços?
- Sua empresa é respeitada em que grau na comunidade de software livre?
- Qual a importância, o valor percebido, pela comunidade de software
livre, para o programa que você pretende abrir o código, no estado atual
e quando estiver pronto?
- O que sua empresa pretende ganhar / poupar abrindo o código do programa?
- O que sua empresa pretende doar / colaborar antes, durante e depois de abrir o código do programa?
- O programa ainda é, ou será, diferencial de negócio? Em que modelo? Em qual licença?
- Qual a análise da concorrência?
Cultura interna
O desalinhamento de valores trará custos, atrasos, atritos, guerras
de poder e controle internas e, após aberto o código, externas com a
comunidade. Haverá a tentativa de controlar à força uma comunidade livre
por natureza, que só pode ser motivada, impulsionada, nunca controlada.
Nesse caso, a primeira providência é estabelecer um cristalino programa
de incentivos corporativos para resultados alinhados com os valores da
comunidade de software livre. Sem isso, os custos e atritos serão
insustentáveis.
Todos os escalões da empresa precisam perceber que os novos valores
darão resultados e que haverá benefícios para as carreiras individuais
se adotados, pois haverá um novo critério de avaliação cristalino e
objetivo. Tal assunto já foi abordado em outros artigos desta série.
Modelo de negócios: serviços
Atualmente, junho de 2008, é o mais lucrativo. E acelerando.
O modelo de venda de produtos está em decadência e perdendo
lucratividade. Só ainda se sustenta para quem já tem elevados volumes.
Conceito na comunidade de software livre
Se sua empresa possui elevado conceito na comunidade de software
livre, teria condições de conclamar colaboradores ainda na fase de
concepção e arquitetura.
Quanto menor a respeitabilidade atual, teria de estar mais próximo de
produto acabado finalizado, inclusive com documentação farta, site
completo com ferramentas de desenvolvimento comunitário (como GForge,
Savanah, SourceForge) populadas.
Qual a importância do código gerado?
O código disponibilizado é percebido como solucionador de uma necessidade premente pela comunidade de software livre?
Se ninguém perceber como importante, ninguém será atraído a colaborar. Simples assim.
Se existirem alternativas melhores disponíveis (qualidade,
desempenho, documentação, massa crítica de desenvolvedores e usuários),
poucos irão colaborar.
O que sua empresa pretende ganhar?
Se a idéia é só arranjar um grupo dos mais brilhantes desenvolvedores trabalhando de graça para sua empresa, já está condenado.
A comunidade de software livre reúne também os mais brilhantes desenvolvedores. E você não conseguirá enganar muitos deles.
A fase ingênua e idealista juvenil já passou.
Tem de ser uma relação ganha ganha.
Estabeleça suas metas para sua empresa mensurar a viabilidade.
Estime quais serão e como medir os benefícios de ter aberto o código. Até alguns como qualificação do corpo técnico da empresa.
O que você irá colaborar?
Estime os homens hora aplicados ao código, às necessidades de evolução e manutenção, passadas e futuras também.
Estime os recursos necessários para viabilizar a participação na
comunidade, em homens hora, máquinas, viagens, patrocínios de eventos e
desenvolvedores, largura de banda, e o que mais você identificar.
Manter e impulsionar uma comunidade até que ela atinja massa crítica
de desenvolvedores e usuários, reduzindo o "bus factor", não é trivial.
Exige habilidade, dedicação, tempo, energia e talento para motivar pessoas.
Quanto mais sua empresa colaborar, principalmente com código,
documentação e homens hora, maior voz ativa terá dentro da comunidade.
Um pedido terá maior chance de ser atendido.
Simplesmente colocar um código num site não garante nada sobre sustentabilidade do projeto.
Nesta fase, sua empresa já está apta a definir o ponto de equilíbrio da abertura de código.
Diferencial de negócio, modelo, licença
Abrir código de diferencial de negócio é mais crítico e depende muito
do modelo de negócios e licença adotada, por isso citados na mesma
frase.
Como regra geral, NÃO abra o código do diferencial de negócios, mas
desloque o máximo possível de esforço necessário para frameworks e
middlewares, também adotando a programação declarativa.
Em casos muito especiais, atualmente em junho de 2008, de situação da
empresa, código, ambiente empresarial e de produtos, e concorrência,
PODERIA ser aberto tal código. Mas se você ainda está tentando entender o
assunto, é melhor não fazê-lo. Deixe para mais tarde, com maior
entendimento e adequação.
Se o fim da vida útil do programa se aproxima ou até já esgotou, nem é mais problema, inicialmente.
A licença adotada precisa proteger seu investimento, fomentar
comunidade e evolução do projeto, inibir "espertezas" e golpes da
concorrência.
Atualmente, as melhores que conheço para isso são a
GPL 3 e
LGPL 3. Mantém todo mundo honesto por força da lei, inclusive sua própria empresa, e
parecem cobrir todas as brechas.
Existem
outras, mas analise com MUITO cuidado, com assessoria jurídica, pois uma má escolha pode condenar seu negócio.
Concorrência
Você precisa proteger seu negócio da concorrência, com adequado
licenciamento. E até colaborar com os concorrentes, por meio do correto
licenciamento.
Quando não é diferencial de negócio, fica mais fácil.
Ainda assim, precisará manter a vantagem competitiva à frente SEMPRE, evoluindo e se adaptando.
Tanto empresa quanto código.
Portanto, o diferencial competitivo deve ser a capacidade de se
manter à frente da concorrência, devido à inteligência e habilidade
incorporadas no grupo funcional.
Não é o conhecimento que detém.
É a capacidade de gerar novos conhecimentos e colaborar.
Quando o projeto atingir massa crítica de desenvolvedores e usuários,
capazes até de prescindir a colaboração da sua empresa na continuidade e
sustentabilidade, os custos irão ser reduzidos ao mínimo.
O lucro está disponível para quem mantém a vantagem competitiva.
Comentários
Postar um comentário