Como você efetivamente compete com um projeto de código aberto?

Uma empresa com um sólido projeto de código aberto concorrendo com um produto tradicional de código fechado parece impossível de vencer.

Eu li este artigo em que o autor apresenta esse cenário:

Suponha que se possa dividir um mercado de software - digamos, gerenciamento de rede - entre dois produtos. Um fez todo o possível e custou US $ 1 milhão, e o outro apenas 10%, mas foi gratuito e aberto.

O preço da solução comercial filtraria automaticamente um grande número de usuários, e essas pessoas teriam que recorrer ao código aberto. Mas alguns usuários ficariam satisfeitos com a funcionalidade de 10% e a escolheriam totalmente.

Por exemplo, tenho um computador Macintosh original em minha mesa. Ele roda um processador de texto chamado MacWrite. Faz tudo, com exceção da verificação ortográfica, que eu preciso de um processador de texto. Posso formatar parágrafos, escolher fontes, deixar o texto em negrito ou itálico e até colar em imagens e gráficos. Tudo na interface do usuário "o que você vê é o que você obtém".

Ele ocupa 76K de espaço em disco. Isso é "K" como em "kilobyte".

Compare isso com o Microsoft Word. Acho que a última vez que instalei apenas o Word, foi cerca de 30 MB, muitas vezes maior que o MacWrite, mas não o uso por muito mais tempo do que o MacWrite. Como eu, muitos usuários estão satisfeitos com a funcionalidade básica. Eles não precisam de todos os sinos e assobios.

Mas voltando à minha analogia. No começo, a empresa comercial provavelmente ignoraria o projeto de código aberto. Como não representa ameaça ao fluxo de receita, por que eles deveriam prestar atenção a um iniciante?

Se esse projeto for saudável e sustentável, no entanto, em um ano ou mais, talvez ele faça de 15% a 20% do que o produto comercial faz. Isso deve sangrar mais alguns usuários de seus negócios e talvez agora eles comecem a prestar atenção.

Muito provavelmente, essa atenção tomaria a forma de marketing contra o projeto. Eles alegariam que é muito pequeno ou muito fraco para levar a sério. E, a curto prazo, isso provavelmente funcionaria. Mas o simples fato de reconhecerem o projeto despertaria interesse. Algumas pessoas determinariam por si mesmas que não era nem muito pequena nem muito fraca e começariam a usá-la.

Mais um ano ou dois se passa e agora o projeto representa até 50% da funcionalidade do produto comercial. As pessoas começam a ingressar no projeto em massa. A empresa comercial agora tem que fazer alguma coisa. O que eles fazem? Eles adicionam mais recursos.

Lembre-se, o produto comercial já fez 100% do que as pessoas precisavam. Então, que tipo de recursos eles poderiam adicionar? Desnecessários. Eles podem alterar a aparência da interface do usuário ou adicionar recursos fora do gerenciamento de rede. De qualquer forma, esse desenvolvimento custará dinheiro, e isso começará a afetar as margens da empresa.

Finalmente, com uma comunidade saudável e esse afluxo de novos usuários, o projeto de código aberto acabará se aproximando de 80% a 90% do que o produto comercial faz. Tendo esgotado todos os caminhos para gerar receita, a empresa comercial ainda tem uma opção final: aparafusar os demais clientes. Encontre maneiras de cobrar mais, e aproveitar o que eles podem com seus investimentos, o que acabará afastando seus clientes.

Farfetched? Acho que não. Existem apenas dois requisitos principais:

Primeiro, encontre um mercado em que o código aberto ofereça uma alternativa atraente, como gerenciamento de rede.

Segundo, construa uma comunidade sustentável em torno do projeto de código aberto.

Parece muito plausível. Se você fosse a empresa de código fechado, como competiria?

Como você não pode competir no preço, concorra com todos os outros pontos de venda que o software possui:

• características
• qualidade
• eficácia
• integração com outro software
• serviço
• Apoio, suporte
• venda direta

Basicamente, você faz o que todas as outras empresas fazem quando estão em concorrência de preços: mantenha o ritmo ou mude o jogo.

Tornando seu produto melhor que a oferta de código aberto. É assim que o Photoshop pode competir com o GIMP.

Acho que a peça que você mencionou é muito enganadora, pois desconsidera completamente a qualidade da oferta de código aberto. Faça a si mesmo uma pergunta um pouco diferente, mas relacionada:

Como uma empresa pode sobreviver sobrevivendo à venda de software de código aberto?

Como colaborador frequente de alguns projetos de código aberto, sinto-me razoavelmente autorizado a jogar algumas voltas de lama onde ela merece.

Nada do que se segue se aplica a projetos principais de OSS , como Linux, Firefox, MySQL ou PostgreSQL, lembre-se. Eles são atípicos, pois são apoiados por empresas e / ou codificadores experientes.

De qualquer forma, quanto aos motivos pelos quais o cliente pagará pelo software:

OSS é propenso a apresentar fluência / Clientes pagarão por software mais simples

Todos os colaboradores do OSS têm seu recurso de estimação. Eles acabarão encontrando o caminho para a base de código. É preciso uma liderança extremamente experiente, firme e carismática para evitar o problema e, como qualquer outro cara, muitos desenvolvedores principais da OSS carecem de pelo menos uma dessas características.

Adicionando insulto à lesão, para cada recurso não essencial que aparece, outro não o deseja e isso resultará na adição de opções. Os programadores tendem a gostar de opções, mas do ponto de vista da interface do usuário, eles são um caminho seguro para uma morte lenta e dolorosa em mil cortes.

Os usuários finais querem ferramentas simples. Eles precisam fazer seu trabalho sem nenhuma curva de aprendizado ou barulho. Eles querem que suas ferramentas tomem as decisões certas para eles; não opções. Se você puder oferecer algo mais simples do que a implementação autônoma do OSS, receberá clientes pagantes.

OSS tende a ser de baixa qualidade / os clientes pagam por uma qualidade mais alta

Não há nada inerentemente errado em aprender a codificar contribuindo para o OSS, lembre-se.

Deve-se dizer, no entanto, que para cada OSS ou biblioteca de alta qualidade que é suportada por todos os tipos de razões por empresas e codificadores experientes, há um oceano de código espaguete propenso a erros, escrito por codificadores inexperientes que estão contribuindo com o OSS para aprender programação e que têm pouca ou nenhuma idéia do que estão fazendo.

O WordPress, por exemplo, foi bifurcado do B2 (ele próprio projetado por um aluno) por um aluno. Várias versões e quantidades incontáveis ​​de fita adesiva posteriormente, fazem o trabalho. Mas, sob o capô, é um dilúvio de bugs com pouco ou nenhum controle de qualidade. (A última vez que tentei, ele não passou com êxito em seu próprio conjunto de testes.)

Os clientes pagarão por software bem conservado e testado. Quase todos tentam coisas gratuitas, lembre-se, e muitos até toleram bugs até certo ponto. Mas se a receita deles depender disso, eles eventualmente procurarão software de melhor qualidade e pagarão por ele.

O OSS tende a ter um ciclo de desenvolvimento muito curto / os clientes pagam para evitar aborrecimentos

Isso é inerente ao processo de desenvolvimento. Os recursos de animais de estimação que são inseridos na base de código precisam ser liberados em uma escala de tempo razoável. Caso contrário, o risco é que o projeto OSS perca alguns de seus colaboradores.

A longo prazo, no entanto, as empresas preferem ciclos de liberação longos; quanto mais, melhor. É menos planejamento e menos trabalho para o departamento de TI. Não é grande coisa se os usuários finais atualizarem seu navegador a cada três meses aproximadamente. É uma história completamente diferente se você estiver atualizando aplicativos de missão crítica.

Houve uma discussão recente sobre a aceleração do ciclo de lançamento na lista de hackers do PostgreSQL. O argumento de fechamento não era sobre o controle de qualidade e a necessidade de longos períodos de teste beta. Algumas empresas já estavam pulando todos os outros lançamentos, porque o atual ciclo de lançamentos (1 ano) já era rápido demais para eles.

Contraste com o WordPress, que está debatendo um ciclo de lançamento de três meses de vez em quando, apesar de um ciclo já muito curto. (Seus betas são, para todos os efeitos, a versão xy0 de cada versão.)

Tendo alguns clientes que usam o WordPress, posso garantir que eles estão mais do que satisfeitos por eu estar cuidando deles para garantir que seus sites não explodam quando eles atualizam. Os clientes pagarão por não precisarem se preocupar com esse tipo de aborrecimento.

O OSS tende a adotar padrões abertos / os clientes precisam apenas de coisas para funcionar

A tag de vídeo HTML5 é um exemplo aqui.

O caso da Mozilla de rejeitar o h.264 é que eles querem um codec de código aberto. E eles estão absolutamente corretos nesse sentido: a última coisa que eles querem é estar na lista dos trolls de patentes; então eles pressionam pelo Ogg.

O argumento da Apple de adotar o h.264, por outro lado, é prático: ele já é amplamente suportado e existe uma aceleração de hardware (permitindo prolongar a vida útil da bateria dos iPhones); não existe tal coisa para Ogg.

Milhões de dispositivos iOS vendidos posteriormente, sites preocupados em fornecer vídeo para esses usuários iOS suportam html5 / h.264. Em outras palavras, os clientes falaram: eles não se importam com formatos abertos.

A única empresa que está feliz com o resultado dessa batalha venenosa sobre codecs é a Adobe: os usuários do Firefox, de fato, continuarão precisando do Flash se quiserem reproduzir vídeos. Se um site importante mudar para vídeos somente html5 / h.264, um codificador surgirá rapidamente com uma extensão ou plug-in para converter as tags de vídeo necessárias em players de vídeo flash. (Pode até já existir.) Em nome do suporte a padrões abertos (que, por acaso, não piscam).

Ninguém nunca foi demitido por escolher a IBM

É uma piada antiga da indústria, mas há verdade: ao usar um orçamento de TI, você não será demitido por escolher o que os colegas consideram o melhor da raça.

Os grandes compradores corporativos que não desejam correr riscos continuarão a comprar desktops baseados na Microsoft, Office, SAP e outros; mesmo se houver alternativas de código aberto. Muito parecido com merda acontece .

Quando o OSS entra em grandes ambientes corporativos, geralmente não é porque o CTO viu a luz e decidiu usar ferramentas gratuitas; ao contrário, está sendo canalizado por terceiros que oferecem serviços (caros) no topo.

Eu acho que o ponto crucial do argumento, de que "o produto comercial já fez 100% do que as pessoas precisavam" é onde o argumento se desintegra. Nenhum produto pode afirmar fazer 100% do que as pessoas precisam e certamente não da maneira mais eficiente (em termos de eficiência do operador), fácil de usar e "melhor" universalmente aceita.

Se tal coisa era possível, é claro que a única coisa que resta para competir é o preço. Mas como uma aplicação "melhor" e universalmente "mais eficiente" é impossível, sempre haverá mais coisas do que apenas preço para competir.

Existem alguns pontos bons nesse artigo, mas, novamente, o mundo real parece muitos exemplos em que as empresas de código-fonte estão indo bem. Aqui estão apenas alguns

1. Linux vs. Windows
2. PHP vs. ASP.NET
3. [uma coisa ou outra] vs. Visual Studio
4. GIMP vs. Photoshop (foi respondido antes de mim, mas eu realmente precisava de um exemplo que não fosse o MS :))
5. vBulletin vs. mais de 30 pacotes de boletins

O problema com o código aberto é que ele está aberto. Se você possui esse código, produz o produto A. Todos os seus concorrentes têm o mesmo código. Assim, você gasta todo esse tempo escrevendo softwares, dos quais uma parte pode ser feita por outros colaboradores, mas se você administra uma empresa, está gastando recursos e, no entanto, qualquer um pode aparecer e começar a vender exatamente o mesmo que passou anos em desenvolvimento. Portanto, a maior ameaça para uma empresa de código aberto pode não ser necessária, mas as outras 5 empresas de código aberto.

Por outro lado, se eu desenvolver software de código fechado, sim, você pode copiar minhas idéias, mas eu ainda poderia estar anos à sua frente no desenvolvimento de software e, quando entrar no mercado, eu já poderia possuir 90% dele.

Por fim, em geral, as empresas que não compartilham código, mas cobram por seu software, geram mais receita do que projetos de código aberto. Assim que essa receita é gerada, uma parte dela é reinvestida não em engenharia (que você poderia argumentar que poderia ser gratuita se você tiver muitos colaboradores de código aberto), mas em marketing e promoção do produto e agora você está falando milhões de dólares por que não existe trabalho livre.

No final do dia, esta é a fórmula para o seu sucesso: [inovação em engenharia] x [marketing] = lucro. Você pode ter o melhor produto, mas se ninguém souber, ninguém o usa. E claramente, se você criar algo ruim, nenhuma quantidade de publicidade será salva. Acredito que muitos projetos de código aberto sempre tiveram problemas com [marketing] quando se trata de penetrar nos mercados de consumo em geral.

Uma área em que a maioria dos softwares de código aberto não pode competir com o software proprietário está na curva de aprendizado.

Historicamente, tive dificuldade em incorporar todos os softwares de código aberto mais populares, exceto alguns, ao meu conjunto de ferramentas. Eles geralmente são ótimos quando eu os entendo, mas normalmente não sinto essa frustração inicial com o software proprietário.

Não sei por que esse é o caso. Posso dizer, no entanto, que estou mais do que disposto a pagar pelo software que realiza o trabalho com o mínimo esforço da minha parte. Esse é o objetivo do software, afinal.

Facilite a implementação do que a concorrência de código aberto e as pessoas pagarão.

Usabilidade e recursos - a única coisa que um projeto comercial de código fechado terá que a maioria dos projetos de código aberto não é a capacidade de controlar uma forte visão do que o produto deve ser e fazer.

Tudo depende do tamanho / complexidade, mas um produto de software de equipe única menor poderá se concentrar no mercado para o qual está tentando atrair. (Esse outro exemplo - como o BBEdit e o TextMate podem atrair um grupo de pessoas dispostas a pagar por um editor de texto, dada a disponibilidade do jEdit, gEdit, etc. O que o TextMate oferece que é atraente o suficiente para levar as pessoas a gastar mais de US $ 20 - $ 30?)

Concentrando-se em problemas específicos do cliente. Muitas vezes, vi organizações gastarem milhares de dólares em "esse recurso".

Como um produto de código aberto, eles precisam se concentrar em massas (infelizmente, as massas não compram esses softwares de mais de 10 mil), como uma fonte próxima para a organização de lucros, se você puder satisfazer a necessidade de seus clientes-chave / críticos que mais negócios seguiriam.

Como o @SnOrfus já mencionou, serviço e suporte são críticos. Já vi zilhões de vezes, organizações preferindo código fechado a código aberto (e até pagando extra) para obter o conforto de poder se apossar de alguém just_in_case!

(isso pode ser um pouco para o cliente corporativo)

A solução comercial pode afirmar, com razão, que sua fortuna está alinhada com o sucesso de seus clientes. É disso que trata o posicionamento do produto. Com algumas exceções, as ferramentas de código aberto geralmente são vistas como o paraíso dos hackers, e não exatamente uma solução pontual focada no cliente.

Se seu cliente precisar de algum recurso, você terá a força financeira para entregá-lo no prazo. Você tem a capacidade de fornecer suporte 24x7 (e cobrar por isso), correção garantida de problemas críticos de nível 0, acesso a novas tecnologias de geração muito mais cedo que a comunidade de código aberto, se você trabalha com OEMs.

Use-os para sua vantagem. Deixe o produto gratuito também estar no mercado, não seja hostil. De qualquer forma, isso expande o mercado - em algum momento, os usuários do produto gratuito podem querer experimentar os sinos e os assobios da sua solução comercial.

Por uma questão de simplicidade, vamos resumir os fatores de sucesso de um software em três "investimentos":

(Aqui, "investimento" é um termo coletivo para atividades nas quais você precisa pagar agora, para receber receitas posteriormente.)

• vendas e Marketing
• desenvolvimento (inclui código fonte, design de produto / interface do usuário, documentação e materiais de treinamento. Quantidade multiplicada pela qualidade. Qualquer produto de trabalho produzido aqui pode ser replicado a um custo baixo para um número ilimitado de usuários)
• serviços (especialização em software e domínio e capacidade de fornecer aprimoramentos de valor agregado por cliente)

O KPI para desenvolvimento é simples: você pode desenvolver a mesma coisa melhor e mais barata que outras. Parte disso é puro investimento em recursos e a outra parte é a sabedoria do arquiteto e dos designers.

Para os serviços, ter acesso ao código fonte do produto é um grande bônus. Uma empresa que não tem acesso ao código-fonte geralmente não pode fornecer o mesmo nível de serviço que outra empresa que tem acesso.

Agora voltando à pergunta do OP: uma empresa de código fechado tem uma estratégia de sobrevivência?

O artigo citado pelo OP parece autolimitado porque considera apenas dois extremos:

• Uma empresa de código fechado desenvolve todo o código-fonte do seu bolso e possui zero linhas de código-fonte aberto.
• Uma empresa de código aberto adota totalmente o princípio e abre todas as linhas de código já desenvolvidas.

E o meio termo?

• Várias empresas de software assinam acordos de licenciamento cruzado para compartilhar parte do código-fonte e / ou API? (Na qual uma das partes é orientada a serviços.)
• Empresas que fazem bom uso de componentes ou bibliotecas de código aberto licenciados no estilo BSD (e fazem contribuições em espécie), sem abrir o código fonte do produto principal?
• Empresas que fornecem código fonte de software em andamento por meio de um acordo de "visualização da comunidade" por tempo limitado?
• "Fonte disponível": empresas que fornecem código-fonte para clientes pagantes?

Meu ponto de vista é que as empresas podem sobreviver se adotarem uma estratégia de código-fonte parcialmente aberta e parcialmente fechada e se saírem bem em todas as três frentes (marketing, desenvolvimento e serviços). As empresas que adotam uma filosofia verdadeira e aberta também podem sobreviver e também terão que se sair bem nas mesmas três frentes.

Porém, existe uma ressalva: se um software é gratuito, os clientes o escolherão em vez de alternativas, mesmo que o software tenha se saído mal em algumas das métricas?

• vendas e marketing: você pode promover um produto quase sem custo, através do marketing viral?
• desenvolvimento: um projeto de código aberto pode obter a maior parte de seu design / desenvolvimento / documentação de voluntários não remunerados? Uma empresa pode colher benefícios desse projeto?
• serviços: um projeto de software pode revolucionar seu domínio de software para torná-lo muito simples, para que todos possam se tornar um especialista instantâneo, reduzindo a barreira de entrada a zero?

O projeto de código aberto está perseguindo o projeto comercial em termos de recursos. Isso deixa uma espécie de arbitragem temporal para a empresa comercial competir por recursos. Eles precisam correr para implementar recursos constantemente para manter uma vantagem sobre a empresa de código aberto. É caro, mas pode funcionar.

Como outras pessoas mencionaram, os recursos podem incluir documentação e facilidade de uso.

A corporação pode tentar instigar o aprisionamento do fornecedor, mas isso apenas diminui a perda; não ganha nenhum cliente.

Isso deixa duas maneiras principais de manter participação de mercado: suporte e exploração da desconfiança gerencial do software de código aberto. Infelizmente, o último vai levar você muito longe. Porém, a venda de suporte funcionará, e mesmo quando o projeto de código aberto pegar o suficiente para obter uma empresa que vende o suporte, a solução comercial terá uma vantagem por ser o titular e ter mais experiência, além da impressão de que eles são mais familiarizado com o seu produto.

A longo prazo, é provável que você seja ferrado, mas isso pode transformar "o curto prazo" em "o futuro previsível".

Uma coisa que ninguém mais mencionou é documentação. Muitos programas realmente não precisam de muito para serem utilizáveis ​​(Firefox, Openoffice), mas se você escrever uma biblioteca, algum tipo de servidor, uma linguagem de programação ou apenas um programa realmente complicado, a documentação poderá se destacar.

Melhorar a documentação pode reduzir a frustração de seus usuários (aumentando a probabilidade de eles continuarem usando seu produto e sugeri-lo no futuro), e você pode anunciar que o dinheiro é bem gasto porque seus clientes não gastam tanto tempo codificando (e tempo == dinheiro).

Porém, isso não é necessariamente código aberto versus código fechado - praticamente tudo está mal documentado. Pode ser que seu concorrente esteja nesse 1% dos projetos que documentam bem as coisas, mas é improvável;)

Muito simplesmente, o truque é manter a redefinição de 100%. O FOSS simplesmente não possui a mesma escala e mão-de-obra de um projeto comercial, e há limites para o quanto você pode competir com um produto existente. Empresas de código fechado usam ganchos de interface do usuário, para que o uso de um produto concorrente pareça impossível devido a diferentes, por exemplo, atalhos de teclado. Além disso, eles continuam adicionando os principais recursos que um concorrente de software livre nunca poderia considerar. Por exemplo, considere o Visual Studio. Era apenas um IDE C ++, mas eles começaram a agrupar linguagens e estruturas completamente novas, como o .NET. Ou o Visual Studio 2010, que empacota uma biblioteca de threads de nível comercial (como a Intel vende um equivalente independente) para C ++. O FOSS simplesmente não consegue acompanhar esse tipo de desenvolvimento e, freqüentemente, a confiabilidade.

Segmente os mercados corporativos tradicionais e fique popular.

Para muitas grandes empresas tradicionais, tudo se resume a três coisas:

• um fornecedor com o qual eles podem firmar um contrato vinculativo com (recursos e confiabilidade)
• um fornecedor com o qual eles podem impor contratualmente um contrato de nível de serviço específico com (agilizar a qualidade do suporte)
• revisões do gartner (este é o equivalente moderno de "ninguém é demitido por escolher a IBM)

Todos os três são seguidos sem pensar, e não são particularmente válidos. Os problemas de capacidade são sempre vendidos em excesso, os SLAs sempre têm uma desculpa e o gartner pesquisa apenas o tipo de pessoa que ouve o gartner, mas quando você é gerente intermediário em uma corporação que possui um monte de gerentes intermediários e intermediários que se metem em problemas com a gerência superior Quando a gerência sênior ouve finalmente que houve uma decisão complicada que custou uma grande pilha de dinheiro, você precisa de alguma documentação de terceiros que apóie sua posição, se você quiser salvar seu emprego. Mesmo que você saiba muito bem que, do ponto de vista técnico, você está jogando grandes pilhas de dinheiro no vaso sanitário, não vale a pena arriscar tentar fazer a coisa certa.

Quantos usos ruins do SAP ou SharePoint você já viu na indústria? Quantas delas teriam sido melhores se tivessem sido feitas em outra coisa que se encaixasse melhor, mas que não fosse um grande nome da indústria?

Uso muitas ferramentas da Microsoft e tenho uma conta no MSDN, mas sinceramente recebo melhor ajuda do pessoal da MS no Twitter do que através da central telefônica do MSDN. Não consigo imaginar que eu recebesse uma ajuda pior do pessoal por trás e do projeto de código aberto do que dos que não apoiam twittam em seu tempo livre, mas isso não entra na equação Liability / Gartner.

Como SnOrfus disse, vendemos os recursos que fazemos.

Por exemplo: Desenvolvemos plugins com alguns recursos comuns e o disponibilizamos gratuitamente para download no site do Wordpress. Ao mesmo tempo, temos o nosso plugin de versão paga, que possui recursos profissionais.

Isso ajuda você a apresentar seu produto para pessoas massivas, ou seja, o poder do código aberto e das pessoas.