Modelos de negócios de código aberto considerados nocivos

John Mark Blocked Desbloquear Seguir Seguindo 4 de janeiro

Não deixe a cauda abanar o cachorro

Software grátis! Obtenha seu software livre! Super barato!

Nos últimos meses, o debate sobre os chamados “modelos de negócios de código aberto” começou a se enfurecer novamente, graças aos movimentos recentes de Mongo, Redis Labs e Confluent. Tomada individualmente, cada situação apresenta características únicas que garantem uma análise mais aprofundada, sem tirar conclusões precipitadas sobre cada entidade. Em conjunto, no entanto, a soma total de seus atos individuais apresenta uma tendência clara: movimento de empresas que constroem produtos em software de código aberto em direção a uma abordagem mais proprietária. Embora cada caso seja diferente, eles declararam, em essência, que uma abordagem de código aberto é inadequada para gerar receita suficiente para gerar retorno sobre o investimento buscado por seus investidores. Acredito que isso se deva ao fato de o surgimento do modelo de negócios de código aberto como uma classe distinta empurrar as empresas que o adotam para uma matriz de decisão de faixas estreitas que apresenta opções limitadas para mudanças futuras, caso surja a necessidade de pivô.

Para ser claro, há uma variedade de maneiras de aproveitar o software de código aberto em um cenário comercial, mas não há um modelo de negócios de código aberto separado, e buscar isso é possivelmente limitar seu sucesso futuro.

Open Core 1.0

Para investigar o movimento em direção a soluções proprietárias, vamos ver como chegamos aqui. De volta à histeria original de código aberto do começo ao meio dos anos 2000, havia uma maneira de criar uma comunidade de código aberto, que chamaremos de open core 1.0:

  1. Tome um projeto de código aberto bem sucedido
  2. Contrate seus desenvolvedores principais
  3. Crie um produto em cima dele, muitas vezes proprietário
  4. Converta os teimosos freeloaders em comprar as melhores coisas proprietárias
  5. Lucro!

Como já referi anteriormente , há várias razões pelas quais essa abordagem era falha. Para começar, supunha-se que as pessoas que usavam o material gratuito eram clientes em potencial. Também assumiu que não havia valor inerente ao fornecimento da versão gratuita além de um meio de estimular o apetite de um cliente em potencial. Para conseguir isso, essas empresas costumavam manter o controle total sobre o código, impondo a atribuição de direitos autorais à empresa para que elas pudessem emitir licenças comerciais para código aberto e código proprietário para clientes pagantes. Esta abordagem falhou espetacularmente, com uma notável exceção: o MySQL, que foi basicamente socorrido por uma Sun Microsystems desesperada antes de se tornar rentável. Aqui estão as razões que se revelaram um modelo não confiável:

  • As comunidades de software foram permanentemente relegadas ao status de segundo nível e claramente não tão importantes quanto os produtos comerciais
  • As comunidades limitaram-se ao âmbito da bolha fornecida pela empresa-mãe, incapaz de desenvolver abordagens inovadoras independentes da empresa-mãe
  • Comunidades nunca foram autorizados a desenvolver uma identidade separada da da empresa-mãe.

O Open Core 1.0 foi uma ótima maneira de silenciar uma comunidade de desenvolvedores e impedir a inovação. Em troca de desistir de uma abordagem mais aberta, essas startups deveriam poder lucrar com a comercialização do software para criar um relacionamento autossustentável entre a comunidade e a empresa. Mas uma coisa engraçada aconteceu: ao tratar a comunidade como um meio de fazer a transição de aproveitadores para clientes pagantes, essas comunidades frequentemente murcharam. E como essas empresas muitas vezes construíam todo o seu modelo de negócios em comunidades prósperas e em crescimento, a falta de sucesso da comunidade se traduzia em vendas e receitas decepcionantes. Se você conseguisse construir uma marca o suficiente e vender a empresa dentro de alguns anos, seria capaz de recompensar seus investidores. Se você não foi capaz de fazer isso, você enfrentou um caminho difícil pela frente. Os investidores que esperavam 10x ficaram desapontados com o seu portfólio de código aberto, parcialmente devido ao fato de que as empresas de código aberto foram julgadas mais duramente em comparação a outras, mas também porque uma abordagem de código aberto parece limitar o crescimento do "taco de hóquei" investidores. Eu diria que os bastões de hóquei são efêmeros e quase impossíveis de serem alcançados em qualquer situação, independentemente da licença de software, mas essas pessoas não me ouvem, então…

Nota especial sobre o MySQL: eles eram um outlier. Eles construíram um grande produto freemium antes mesmo de se tornarem código aberto, e nunca perderam suas raízes freemium. Isso foi a seu favor. Considerando que outras startups tentaram pegar as comunidades de código aberto existentes e transformá-las em produtos freemium, o MySQL apenas abriu seu software como um meio para reforçar o suporte depois que o licenciamento de código aberto começou a ganhar força. Ele não precisou converter sua comunidade para uma abordagem freemium – ela sempre esteve lá e incorporou seu modelo. Mesmo assim, eles tiveram muita dificuldade em converter usuários, mas o sucesso deles é um tanto quanto estranho.

Vale a pena notar que o MongoDB começou no final da era do open core 1.0, e você pode ver isso em seu modelo básico de negócios. Mais sobre isso depois.

O Surgimento do Núcleo Aberto 2.0

Com o fracasso espetacular do Open Core 1.0, surgiram novas abordagens que eram muito mais realistas. Como mencionei na minha série “ Como Ganhar Dinheiro a partir de Plataformas de Código Aberto ”, a abordagem de núcleo aberto se transformou no que eu chamo de “abordagem híbrida”: usando plataformas de código aberto desenvolvidas colaborativamente como base para construir estruturas de gerenciamento de sistemas proprietárias para empreendimentos. Cloudera é provavelmente o melhor exemplo disso, usando a extensa comunidade do Hadoop como sua base de software, mas há muitos outros. O Apache Spark gerou Databricks. Apache Kafka gerou Confluente. Uma coisa sobre esses novos modelos híbridos é que é difícil determinar o que veio primeiro, o projeto de software ou a empresa. O RedisLabs é uma empresa que tenta acompanhar de perto o antigo modelo de núcleo aberto, mas também fez uma tentativa de executar seu projeto Redis da maneira mais independente possível, tendo aprendido com os antipadrões de esforços anteriores. Entre as empresas que ainda existem e prosperam, Mongo é provavelmente o analógico mais próximo hoje em dia para abrir a governança do core 1.0.

Mas muitas dessas empresas enfrentam dificuldades em relação a seus modelos de negócios, como pode ser visto em vários esquemas recentes de licenciamento que tentam ultrapassar a linha entre código aberto e proprietário. O Mongo está tentando capturar usuários de seu software, determinando que qualquer pessoa que crie o Mongo-as-a-Service deve liberar todo o código sob a “Licença Pública do Servidor” ( SSPL ). A Confluent alterou a licença para alguns de seus componentes de plataforma para a CCL (Confluent Community License), que impede que outras pessoas executem o KSQL como um serviço sem a permissão do Confluent. E, é claro, a empresa que deu início a toda essa controvérsia foi a RedisLabs, que mudou a licença de alguns dos seus Redis Plugins para adicionar a Cláusula Commons, semelhante à CCL, impedindo que empresas não autorizadas usassem seu software como serviço. O que leva essas empresas no caminho de tirar alguns de seus softwares do ecossistema de código aberto e colocá-los em seus próprios proprietários? Acredito que a árvore de decisão é desencadeada por uma crença defeituosa em modelos de negócios de código aberto.

Não há um modelo de negócios de código aberto.

Uma vez que você começa com a premissa de "Preciso de um modelo de negócios de código aberto", isso leva você ao caminho "Preciso monetizar meu projeto" em vez de "Preciso construir um produto que agregue valor". Estes podem não parecer muito diferentes à primeira vista, mas isso o leva a uma direção em que as mudanças de licenciamento são uma conclusão lógica. Descendo este caminho, restringe sua capacidade de girar em seus objetivos de negócios e produtos. Acredito que, se você se concentrar em criar um produto que agregue valor aos principais casos de uso de seus clientes, a escolha da licença para seu software se tornará menos relevante, se não irrelevante. Se você ainda não leu o comentário de Stephen Walli ou VM Brasseur sobre este assunto , eu recomendo que você faça isso, e então continue abaixo. Também escrevi um pouco sobre por que os projetos não são produtos e mais sobre como criar produtos de código aberto (uma série de quatro partes sobre "Como ganhar dinheiro com plataformas de código aberto")

Consegui? Isso foi divertido, sim? Está bem…

O exemplo Cloudera

Vamos usar o Cloudera como um exemplo primário. Ao mesmo tempo, eles podem ter começado com a premissa de “vamos monetizar o Hadoop”. Felizmente para eles, porque eles confiaram seus negócios a uma das pessoas mais inteligentes do negócio, Mike Olson , eles rapidamente percorreram o caminho de “o que podemos oferecer de valor para os clientes” e depois construíram. É quase esquisito lembrar que, quando a Cloudera começou, eles eram “a empresa Hadoop”. Isso simplesmente não é mais o caso. Agora eles são o "Enterprise Data Cloud", com muitas análises de dados e soluções de ciência de dados. Você não verá nenhuma mensagem no site cloudera.com indicando que está tentando "gerar receita com o Hadoop". Ou faísca. Ou Kafka. Ou qualquer outro projeto de código aberto. A Cloudera é uma empresa de produtos e soluções e vende coisas de valor para seus clientes, que não se importam com a origem do software. Você pode achar que isso é ofensivo ou ofensivo à sua sensibilidade de fonte aberta. Eu não.

Vamos supor que Cloudera tenha decidido, muito tempo atrás, continuar sendo “a empresa Hadoop”. Vamos estalar os dedos e imaginar que é o que a Cloudera está fazendo hoje: eles compraram o domínio hadoop.com e se autodenominaram “Hadoop, Inc.” (Sim, eu sei: o Apache Hadoop é governado pela ASF e nunca permitiria que seus projetos ser cooptado assim. Trabalhe comigo neste hipotético, para o bem de Pete.) De uma só vez, Cloudera passou de se concentrar em entregar valor aos seus clientes para também carregar simultaneamente a bandeira do Hadoop. Como isso se manifesta na árvore de decisão da Hadoop, Inc.?

Para começar, agora que seu sucesso está atrelado ao destino do projeto Hadoop, eles estão muito ligados ao sucesso ou fracasso do Hadoop, com pouca margem de manobra para futuras manobras, caso o sucesso do Hadoop seja plano . Isso também leva a outras perguntas e decisões desconfortáveis: o que acontece se o Hadoop for “muito bem-sucedido” e ofuscar o Hadoop, Inc? A Hadoop, Inc. não é incentivada a garantir que o projeto Hadoop não seja fácil de usar? E se outras empresas quiserem criar produtos no Hadoop? Eles devem pagar o Hadoop, Inc? E se eles não querem ou não podem pagar? Isso significa que a Hadoop, Inc. agora vai desconfiar de qualquer “freeloader” que não pague pelos produtos da empresa? “Aha! Eu consegui! ”, Exclama um novo MBA recém-contratado. “Vamos pegar alguns dos componentes mais populares do Hadoop e torná-los proprietários! Dessa forma, os aproveitadores terão * que nos pagar! ”E assim começa o ciclo de dor pelo qual cada novo recurso ou projeto de tecnologia é executado através da árvore de decisão sobre se esta tecnologia é“ essencial ”ou“ complementar ”e se deve ser open source ou proprietário. É um ciclo sem fim marcado por mudanças e arrependimentos. O que antes era considerado “essencial” pode se tornar “complementar” e vice-versa, resultando em estagnação e prioridades mal direcionadas, onde a cauda agora abana o cachorro, com a cauda sendo “devemos monetizar o Hadoop”.

Neste ponto, você pode estar pensando – os produtos de gerenciamento da Cloudera não são proprietários? Sim, eles são, e eu tenho duas coisas a dizer sobre isso:

  1. Como há uma separação clara entre o projeto de código aberto e os reinos de produtos da Cloudera, há pouca confusão. Ao criar soluções Cloudera, não há um debate cansativo sobre se é o núcleo e parte do lado de código aberto da casa. Tudo desenvolvido para a Cloudera é um espaço de produto e os gerentes de produto podem se concentrar em agregar valor. Feito.
  2. A Cloudera optou por tornar sua gestão “topping” proprietária. Eu diria que é irrelevante como o software subjacente é licenciado, e é aí que eu luto com o Sr. Olson.

O importante sobre o # 2, acima, é que é escolha do Cloudera fazer, livre do impacto que causou no Hadoop. Se eles usam código proprietário ou de código aberto para seus produtos de gerenciamento, o impacto sobre a comunidade do Hadoop é muito pequeno, um grande ecossistema de desenvolvedores e empresas que criam vários projetos de código aberto. Posso entender por que as pessoas de negócios podem recusar o código-fonte aberto de todo o código, mas pense nisso: se você é um cliente e precisa de uma solução confiável que funcione, vai realmente desafiar sua equipe uma solução caseira em que você constrói seu negócio? Como eu sei disso? Acontece que existe outra empresa que ganha a vida vendendo produtos de código aberto com soluções de gerenciamento construídas no topo e constroem todos os seus produtos usando componentes de código aberto. E eles ganham dinheiro. Quem é essa empresa unicórnio? Chapéu vermelho. Como eu disse, repetidamente, ninguém jamais fez engenharia reversa e reimplementou o modelo da Red Hat. Cloudera chega perto em conceito, mas, como descrevi, sua implementação difere de maneiras importantes. A Red Hat, como a Cloudera, ganha dinheiro vendendo assinaturas de licenças para clientes que precisam de soluções prontas. Ao contrário de Cloudera, a Red Hat decidiu que todos os seus softwares seriam de código aberto, porque eles queriam derivar o valor que vem da inovação acelerada por meio da colaboração de software, e isso não os impediu. Por quê? Como a Red Hat entendeu antes, antes de mais, que o valor para os clientes não está vinculado à licença do software subjacente, mas sim ao valor inerente das soluções totais, isto é. funciona realmente como prometido.

O “problema” amazônico

Hoje em dia, é muito comum usar a Amazon e o Google como exemplos de empresas que usam seu software de código aberto e criam produtos sem pagar, mas vamos levar a sério por um momento: a Amazon e o Google não usarão seu software, particularmente seu software de gerenciamento, “out of the box”, proprietário ou não. Eles vão construir seu próprio gerenciamento UX e UI, porque eles têm seus próprios requisitos para atender às suas necessidades, e eles vão construí-los usando APIs de plataforma existentes. Suas demandas de escalabilidade são tão fora dos gráficos em comparação com seu cliente corporativo típico que seria imprudente para a grande maioria dos fornecedores até mesmo tentar atender aos seus requisitos. É por isso que a introdução de truques de licenciamento para resolver o “problema da AWS” é uma solução não-inicial, uma solução que procura um problema. Você não vai resolver seus próprios erros de negócios por meio de engenharia reversa de uma solução de licenciamento para o que era essencialmente um problema de modelo de negócios. Você acredita honestamente que a Amazon iria usar as implementações de gerenciamento do RedisLabs ao introduzir seus serviços de banco de dados na memória? O fato é que, seja você Mongo, RedisLabs, Confluent ou qualquer outra pessoa, você está livre para vender suas soluções como um serviço para clientes usando qualquer plataforma IaaS, incluindo a da Amazon ou a do Google. Na verdade, Mongo fez exatamente isso e, na maioria dos casos, com bastante sucesso.

Se você está pensando em começar uma empresa, não deixe a cauda abanar o cachorro. Comece com a pergunta "como posso entregar valor para os clientes" e trabalhe de trás para frente. Em seguida, junte os componentes de código aberto que você precisará para suas soluções definitivas que agregam valor e constroem sua cadeia de suprimentos de software . Neste ponto, você pode decidir, como a Red Hat, que deseja os benefícios do desenvolvimento colaborativo, ou pode decidir, como o Cloudera, que deseja que pelo menos alguns deles estejam inteiramente sob seu controle. O ponto é que você pode fazer essa escolha sem a bagagem de “vamos monetizar 'X'”. Você ficará muito mais feliz com sua escolha.