O open source não vence por ser mais barato

• Uma empresa comercial de open source dificilmente se sustenta por muito tempo apenas com uma alternativa que pega um produto pago existente e adiciona a licença MIT; ela precisa ter um motivo claro para ser open source ou um produto superior
• Diferentemente de projetos sem fins lucrativos ou baseados em patrocínio, um negócio open source precisa ter receita para contratar, crescer e continuar desenvolvendo
• Empresas em estágio inicial tendem a escolher tiers gratuitos ou versões open source, enquanto grandes empresas tratam custos de SaaS como itens de orçamento; portanto, é difícil reverter uma decisão de compra apenas por ser mais barato
• O open source se fortalece quando há um problema de transparência em que o código fechado abala a confiança do cliente, ou um problema de extensibilidade que exige muitas integrações e plugins
• Casos como PostHog, Medplum, SuperTokens, TableFlow, Minio, Airbyte e Elastic mostram que o open source pode evoluir para um produto melhor por meio de auditabilidade, self-hosting e contribuições da comunidade

---

Só uma alternativa open source não basta

• Descrições como “a versão open source do Stripe Billing” ou “a versão open source do Chargebee” são úteis para fazer as pessoas entenderem rapidamente o produto, mas são fracas como base para sustentar um negócio
• Ferramentas comerciais de open source dificilmente podem depender apenas do posicionamento de alternativa open source a um produto pago que já teve sucesso
• Não basta um desenvolvedor imitar um produto e adicionar uma licença MIT; o open source por si só também não garante sucesso
• O foco da discussão são projetos comerciais de open source que competem com soluções pagas populares
  • Produtos centrados na comunidade ou financiados por patrocínio, como React, TypeORM e VSCode, têm prioridades diferentes
  • React recebe apoio de uma organização maior como a Meta, e TypeORM financia seu desenvolvimento por meio de doações
  • Esses projetos não são, em essência, empresas
• Para uma empresa open source ter sucesso, precisa haver uma razão clara para ela ser open source, ou ela precisa superar seus concorrentes

O critério de sucesso é receita, não uso

• Com exceção de projetos sem fins lucrativos que recebem doações ou apoio de uma empresa-mãe, o critério final de um negócio open source típico é receita
• Empresas com fins lucrativos usam a receita para financiar contratação de funcionários, crescimento, sustentabilidade e desenvolvimento contínuo
• Empresas que criam software gratuito e ainda assim geram receita são exemplos positivos; empresas open source não estão necessariamente tentando explorar demais os clientes, mas sim continuar operando
• O MongoDB cresceu e se tornou uma grande empresa de banco de dados, com mais de 4.600 funcionários
  • Depois, mudou para a licença SSPL para impedir que Cloud Providers distribuíssem o serviço sem contribuir com o projeto
  • A SSPL não foi aprovada pela OSI, mas é descrita como, na prática, próxima de open source
• Ao medir sucesso de longo prazo, é preciso diferenciar adoção de receita
  • Mesmo com alta adoção, um projeto pode desaparecer se não conseguir gerar receita
  • A expectativa de que a comunidade assumirá o projeto é vista como tendo pouca evidência de suporte

Ser barato não é uma vantagem sustentável

• Uma estratégia voltada apenas a clientes sensíveis a preço é quase uma batalha perdida
• Em um exemplo hipotético de criação de uma versão open source do Amplitude, seria possível argumentar que o Amplitude é caro, pesa para empresas em estágio inicial e também permitiria que grandes empresas economizassem
• No entanto, empresas em estágio inicial são sensíveis a preço e, por isso, tendem a escolher uma versão open source ou um tier gratuito; isso não é suficiente para sustentar o negócio
• A estratégia de criar uma alternativa mais barata geralmente se parece com um bilhete para uma falência futura
• Grandes empresas também normalmente não se preocupam que os custos com Amplitude possam levá-las à falência
  • Em negociações de contrato, podem discutir preço dentro do orçamento
  • Mas a maioria dos SaaS acaba sendo apenas mais um item de custo
  • Condições mais importantes são se a solução é boa, se continuará existindo no longo prazo e se é fácil de administrar
  • Implantar uma solução open source pode ser trabalhoso de administrar
• A exceção ocorre quando o custo da solução representa uma fatia muito grande do orçamento total
  • Isso inclui empresas que precisaram reduzir o uso de Oracle porque os custos cresceram muito devido ao volume de uso do banco de dados
  • Porém, como a maioria das soluções open source não substitui um dos 3 maiores itens de custo, é difícil que preço seja o principal critério de decisão

A primeira forma de o open source vencer: transparência

• Um caso representativo em que uma solução open source se torna forte é quando há um problema de transparência, no qual o código fechado cria desconfiança entre cliente e fornecedor
• Uma alternativa open source ao Amplitude é o PostHog
  • O PostHog cresceu tendo Airbus, DHL e Staples como clientes
  • Ele combina várias soluções SaaS de produto e é oferecido como open source
  • Até o código-fonte do blog e o roadmap são públicos
• O PostHog se posiciona como um produto melhor que concorrentes pelo fato de ferramentas de analytics lidarem com dados sensíveis de clientes, como endereços IP, nomes e gravações de sessão
• Em um ambiente com cada vez mais regulações de dados, como GDPR e CCPA, pode ser incômodo permitir que terceiros armazenem esses dados
• O PostHog oferece duas opções
  • Fazer self-hosting da solução de analytics
  • Contratar o PostHog como terceiro, mas com transparência sobre como os dados são armazenados e como migrar para self-hosting no futuro
• Mesmo que o método mais favorável à privacidade seja o self-hosting, muitas empresas ainda podem escolher o modelo hospedado
  • Mesmo nesse caso, é possível ver como o software funciona linha por linha
  • É possível saber o processo para migrar para o modelo self-hosted quando necessário
• Empresas open source não vencem eliminando a necessidade de terceiros, mas conquistando confiança ao permitir auditoria pública de seu funcionamento

Exemplos de produtos em que transparência importa

• Medplum é uma plataforma de prontuário eletrônico de saúde open source que compete com fornecedores tradicionais de código fechado
  • Por ser open source, os usuários podem verificar exatamente o que a plataforma suporta e o que ela não suporta
• SuperTokens é uma alternativa open source a soluções de autenticação como Auth0
  • Login envolve dados sensíveis como nome, e-mail e senha
  • O fato de ser open source ajuda a conquistar mais confiança
• TableFlow é uma alternativa open source a plataformas de importação de CSV como Flatfile
  • O ponto importante é que os dados importados podem ser sensíveis
• Minio é uma alternativa open source ao armazenamento AWS S3
  • No S3, PII de clientes pode ser armazenada em capturas de tela ou arquivos JSON estruturados
  • Minio pode ser uma alternativa para empresas que se preocupam com quem tem acesso aos dados dos usuários
  • A AWS afirma que funcionários da AWS não acessam diretamente os dados dos clientes, mas, em código fechado, essa afirmação continua sendo uma questão de confiança
• Lago também lida com informações de cobrança e uso do produto, e essas informações são próximas de conteúdo sensível; por isso, considera-se que o open source pode gerar melhor confiança dos usuários

A segunda forma de o open source vencer: extensibilidade

• Uma das grandes vantagens do open source é abrir o desenvolvimento de funcionalidades de nicho para a comunidade
• O produto principal costuma ser mantido por uma equipe central de engenharia, mas integrações e plugins são criados por desenvolvedores da comunidade e, às vezes, incorporados ao branch principal
• Soluções de código fechado precisam depender de suas próprias equipes de engenharia, por isso é difícil escalar da mesma forma
• Isso é especialmente vantajoso para empresas open source que criam sistemas que precisam se conectar a muitas bibliotecas, frameworks e aplicações
• Airbyte é uma plataforma ELT open source que cresceu muito graças aos conectores adicionados pela comunidade
• Elastic também é uma empresa maior que originalmente era open source e oferece várias integrações de dados
• SuperTokens colocou extensibilidade como proposta de valor central, e a possibilidade de membros da comunidade criarem integrações com provedores de autenticação pouco comuns beneficia todos

A terceira forma de o open source vencer: um produto melhor

• Transparência e extensibilidade ajudam o open source comercial a se tornar, no longo prazo, um produto melhor
• Projetos open source podem evoluir mais rapidamente que soluções de código fechado ao aproveitar o feedback e a ajuda da comunidade
• O PostHog começou como alternativa ao Amplitude e ao FullStory, mas depois cresceu e se tornou uma solução ampla que também compete com LaunchDarkly e Pendo
  • O PostHog captou uma rodada Series B de US$ 15 milhões
  • Esse crescimento aconteceu nos últimos anos, e o PostHog vê a comunidade como um dos principais motivos
• Projetos open source, não apenas os comerciais, vêm servindo há décadas como uma força importante para a melhoria de produtos
• Alguns softwares podem permanecer fechados devido às características do efeito de pioneirismo
• Mas, em áreas onde transparência e extensibilidade são problemas, entrantes open source podem se tornar uma ameaça real

[guarder]

Encontrei isso por acaso enquanto pesquisava, e fiquei me perguntando quando a IA vai corrigir traduções literais do inglês como essa ("por ser barato").

[savvykang]

Resultado da execução do Claude 4.5 Sonnet hoje (2026-01-12)

---

"Open Source does not win by being cheaper"

Prompt

Traduzir "Open Source does not win by being cheaper" para coreano  

---

O código aberto não vence simplesmente por ser barato.
O fator de sucesso do código aberto está em outro lugar, não no baixo custo.
O código aberto não ganha vantagem por causa do preço baixo.

O código aberto não vence por ter preço baixo  
  
Paraphrase  

[GN⁺]

Opiniões no Hacker News

• O termo lucro (profit) aqui é estranho e ambíguo
  Operei projetos de software livre e de código aberto por quase 24 anos e, em cerca de 17 deles, também gerei receita, mas nunca tive “lucro”; havia apenas receita (revenue)
  Normalmente, como empresas ou contadores veriam, lucro é o dinheiro que sobra depois de subtrair a remuneração e os custos das pessoas envolvidas no projeto
  Projetos open source que precisam de lucro nesse sentido são apenas aqueles que receberam investimento de capital de investidores que esperam uma “taxa de retorno”; esses projetos existem, mas não são a maioria
  Além disso, como costuma acontecer em textos que aparecem no HN, o texto como um todo é muito enviesado para Web/SaaS. Por incrível que pareça, existem outros tipos de projetos open source

  • Este texto não fala de inúmeros projetos open source em geral, mas de negócios baseados em open source
    Nesse contexto, o que sobra depois de receber receita e pagar custos é lucro, e esses custos incluem coisas como salários fixos, contratos de trabalho e holerites
    Um negócio pode usar o lucro de várias maneiras. Pode acumulá-lo como reserva de caixa para pagar custos mesmo em meses de baixa receita, comprar ativos como novo hardware, ou viabilizar contratações adicionais. Embora não seja tão comum quanto se imagina, também pode pagá-lo aos proprietários como dividendos
    Sem muitos detalhes sobre a sua situação, só dá para supor, mas, se você opera sozinho e o projeto é pequeno a ponto de não haver necessidade nem vontade de aumentar a equipe, a receita é, na prática, quase renda pessoal. Como em alguns meses você recebe mais e em outros menos, nesse contexto faz sentido chamar isso de receita, não de “lucro”
    Isso vale ainda mais se for software com quase nenhum outro custo indireto e se o acompanhamento de despesas para fins tributários não fizer muito sentido; talvez você nem mantenha uma contabilidade propriamente dita. Se essa for a situação, entendo por que o texto não ressoa com você. Ele trata de uma situação bem diferente
  • Acho meio engraçado ver alguém no HN, ainda por cima dizendo que toca um negócio, colocar aspas assustadas em torno da palavra profit e falar como se ela fosse ambígua
  • Mesmo sem venture capital, é possível operar como pessoa jurídica ou ter uma mentalidade voltada a crescimento e lucro
    Se investidores puramente financeiros não exigem retornos contínuos, a pressão cai bastante, e fica mais fácil fazer o que combina com o projeto
    Mas, em áreas de produto em que se compete com empresas ambiciosas, crescimento também pode ser necessário e provavelmente razoável
    Manter lucro para se preparar para recessões, oportunidades e grandes despesas não é apenas algo razoável. Quanto mais pessoas e clientes participam, mais fortes ficam os motivos para não queimar toda a receita que entra
  • Se você paga remuneração a si mesmo, no fim das contas está dependendo do lucro. Na contabilidade, o lucro vira zero, mas, na prática, não é diferente de usar o lucro para pagar dividendos
  • Lucro é um termo contábil, portanto é ambíguo. Para ser realmente claro, é útil delimitá-lo, por exemplo, como “lucro tributável” ou “lucro na visão do investidor”
    Na prática, em empresas grandes, esses dois números muitas vezes não têm relação entre si, e cada um é definido conforme a quem é comunicado e quais regras se aplicam a essa comunicação
    Também pode haver algo como “lucro gerencial”, um termo genérico para métricas não padronizadas nem reguladas. Por exemplo, mesmo que um negócio tenha deixado a contabilidade pelo regime de caixa para fins fiscais e de reporte a investidores, pode continuar sendo útil para a gestão existente acompanhar a antiga definição de lucro. Pode ser por hábito, ou porque ela mostra bem o fluxo de caixa, ou porque é útil de alguma outra forma
    Esse é um desses problemas pós-modernos. A SEC, o IRS e o gerente do banco não aceitam expressões como “lucro da SEC” e exigem o lucro “de verdade”. É parecido com um político local perguntando ingenuamente a um hospital quanto ele custou “de verdade” para a construtora
    De todo modo, o autor também está usando termos a partir de sua própria perspectiva, como a SEC ou o IRS. Quando ele diz que “open source não vence por ser mais barato”, “open source” se refere a negócios open source em modelos como o da MongoDB. Por isso, coisas como investidores e metas de crescimento estão pressupostas
    Como o próprio texto deixou isso claro, não há muita necessidade de partir para rosnados semânticos

• O problema desse modelo de negócio é que ele cria uma tensão entre a versão OSS e a versão paga.
  Querem que a versão OSS seja boa, mas não tão boa a ponto de ninguém sentir necessidade de pagar por SaaS, consultoria etc.
  Essa tensão acaba, ao que parece, levando à ausência de recursos claramente necessários, ou a recursos e conhecimentos necessários para operar em escala sendo escondidos como código fechado para a monetização da empresa patrocinadora.
  Se o produto tem natureza de infraestrutura, também já se consolidou o padrão de mudar para uma licença que permite ver, mas não tocar, para impedir que grandes provedores de nuvem, como Elastic e Hashicorp, o engulam como um serviço de um clique.
  Não estou dizendo que o texto esteja errado, mas gostaria que o OSS patrocinado comercialmente não fingisse ser um ganha-ganha kumbaya bom para todo mundo. Na prática, a estrutura é mais parecida com uma startup usando isso como growth hack para aumentar a confiança e, quando chega a hora de gerar receita, apertando de alguma forma a comunidade que ajudou no crescimento.

  • Não vejo nenhum problema na parte de “o patrocinador esconde como código fechado recursos óbvios ou recursos e conhecimentos necessários para operar em escala para ganhar dinheiro”.
    Mantendo um módulo pequeno, recebi muitos pedidos de recursos e de suporte ao longo de anos. Até ganhar o suficiente para pagar o aluguel, não sinto a menor culpa em cobrar por esse tipo de coisa.
    Até para apertar o botão de mesclar um Pull Request eu cobro, se isso tomar um único segundo do meu tempo. Passei meses, anos no código e disponibilizei esse código ao mundo de graça.
    Se você precisa de recursos adicionais ou do meu tempo, tem que pagar.
  • É verdade que essa tensão existe, mas ela não é, de forma alguma, inevitável. Há empresas que conseguem fazer isso direito, satisfazendo tanto usuários de OSS quanto clientes comerciais.
    O fato de muitas empresas não conseguirem não significa que esse modelo de negócio não funcione; significa mais que fazê-lo direito é muito difícil.
  • Tirar o tapete debaixo dos pés dos usuários certamente parece desagradável.
    Ainda assim, se partirmos do pressuposto de que a maioria das pessoas é, em geral, bem-intencionada, vale considerar a possibilidade de que essas empresas ou pessoas tenham abordado o mercado da forma errada. Pode ser incompetência, não má-fé.
    Se, desde o primeiro dia, deixarem transparente o que será gratuito para sempre e o que acabará se tornando pago, eu não veria isso como uma traição à comunidade.
    Claro, isso pressupõe cumprir o roadmap e fazer ajustes com base em feedback e contribuições.
  • Há uma separação muito simples que muitos projetos usam: dividir usuários corporativos e usuários individuais.
    Suporte pago ou funcionalidades de extensão podem ficar na esfera comercial, onde o software ganha a maior parte do dinheiro de qualquer forma.
    Isso não serve para todos os casos de uso, mas também não precisa servir. A maior parte da computação deveria ser pessoal.
  • Fiquei curioso sobre que padrão você está falando. Quero saber como esses projetos de infraestrutura fazem para não morrer nas mãos da AWS ou do GCP.

• Há quem diga que “o MinIO é uma boa alternativa para empresas que se preocupam com quem acessa os dados dos usuários”, mas uma empresa não poderia afirmar que hospeda com software open source e, na prática, usar um software interno de código fechado que imita o mesmo endpoint de API?
  Nesse caso, ainda seria necessário o mesmo tipo de confiança que se tem na AWS.

  • Uma empresa pode dizer sinceramente que mantém os dados de clientes on-premises para protegê-los das assustadoras grandes nuvens, mas pode omitir que todo tipo de gente do ecossistema local de consultoria de TI tem privilégios de administrador de domínio e que metade do bairro acessa o KeepassX no drive de rede.
    Não se deve presumir que auto-hospedagem significa alta consciência de segurança. Na maioria das empresas, TI on-premises é tratada como HVAC ou instalações elétricas, só que mais irritante.
    Qualquer pessoa de uniforme de trabalho poderia enganar a recepção e conseguir a chave da sala de servidores.
  • Exato. Esse argumento é surpreendentemente comum, mas não faz sentido. Em SaaS, a expressão open source não significa muita coisa.
    Significa apenas que o fornecedor compartilha o código-fonte que diz estar rodando por trás do serviço.
    Mesmo que esse código esteja exatamente correto, é improvável que seja o único código rodando por trás do serviço “oficial”. E o usuário também não pode compilá-lo por conta própria e implantá-lo nos servidores deles.
    Open source só tem significado real quando você faz auto-hospedagem; caso contrário, na prática, não difere de software proprietário. Tudo depende da confiança no fornecedor e, se possível, do contrato.
  • Se for “confiança” em um sentido puramente técnico, sim, mas nós vivemos em sociedade. Se, por causa de uma cláusula que o fornecedor colocou no contrato, ele puder ser responsabilizado por fraude caso aquilo seja mentira, o cliente normalmente não se preocupa se consegue verificar isso de forma independente.
    Por exemplo, se o contrato diz que os dados entram e saem por este código open source e não vão para outro lugar, e enumera procedimentos para garantir isso, mas tudo isso for uma mentira descarada, vira um grande problema de forma clara e executável.
    Também seria difícil esconder dos funcionários internos, e pessoas entram e saem. Se não fosse verdade, é pouco provável que fizessem esse tipo de alegação.
  • Só o fato de ex-funcionários saberem disso já cria uma ótima oportunidade de processo.
  • Não é bem assim. Se uma empresa faz uma afirmação e, na prática, faz outra coisa, isso é enganação, e é possível tomar medidas legais. Isso é uma questão separada da confiança.

• O autor deixa claro que está falando especificamente de soluções open source que competem com produtos pagos.
  Pessoalmente, acho que, nesse contexto, ainda não há uma conclusão sobre se o open source “vence”.
  Nos últimos 10 anos, os produtos open source aumentaram muito, e nos últimos 5 anos mais ou menos também vimos muitos deles se afastando do open source. MongoDB, a stack da Hashicorp, Elastic, Red Hat, MinIO etc. são exemplos disso.
  Não restam muitos produtos que sejam genuinamente open source e comercialmente competitivos, e muitos deles estão se esforçando para provar que isso é um modelo de negócio viável.

  • O projeto Caddy está lutando para mostrar que esse modelo é possível, e tem tido algum sucesso.
    Algumas semanas atrás, fiz uma apresentação sobre esse tema em um evento interno da empresa, e daqui a algumas semanas vou apresentá-lo novamente na GoWest.
    A premissa central é que uma licença open source literalmente concede liberdade, mas não oferece outras coisas pelas quais uma empresa estaria disposta a pagar. Uma licença proprietária oferece aquilo de que a empresa precisa, mas sacrifica a liberdade.
    Acredito que exista um terceiro modelo que funcione no meio-termo sem comprometer liberdade nem confiabilidade. Permanecendo open source e preenchendo, por meio de patrocínio, as lacunas de que as empresas precisam, isso pode ser possível para alguns projetos.
    No momento estamos redesenhando o site do Caddy em torno dessa mensagem, e espero que funcione bem.
  • Não é esse o ponto do texto? Não que o open source necessariamente vença, mas que, se vencer, não será por derrubar os concorrentes pelo preço, e sim pelas forças que o autor enumerou.
  • Olhando o repositório do MinIO, parece que eles trocaram de APL2 para AGPL3.
    Quando você diz que o MinIO “se afastou do open source”, é a isso que está se referindo?
  • Como será que VLC e Blender são operados?

• O título é idiota. É óbvio que open source vence por ser mais barato.
  O que o autor quer dizer é que negócios de open source não vencem por serem mais baratos.
  Bases de código open source sempre vencem por serem mais baratas. Ninguém paga por algoritmo de compressão, daemon de tempo de rede ou transcodificador de mídia. O open source eliminou completamente esses mercados.

  • Na verdade, parece um texto bem interessante sobre o negócio de produzir código open source.
    Só irrita que o título esteja literalmente errado por causa de uma única palavra.
  • No título “a métrica de sucesso não é uso, é receita”, a mudança de contexto de falar de ferramentas open source para falar de negócios open source foi tão brusca que pareceu um tranco no pescoço.
    Reli os parágrafos anteriores achando que eu tinha deixado passar alguma coisa.

• Do ponto de vista de um engenheiro que influencia a adoção de tecnologia, open source vence por ser compreensível.
  Se meus colegas e eu conseguimos ver o código-fonte, podemos avaliar se o produto vai cumprir as funcionalidades que afirma ter.
  Se encontrarmos um bug ou um caso de uso inesperado durante o uso, no mínimo podemos investigar uma solução e sugeri-la no relatório de bug, ou então abrir um PR.

  • Isso com certeza tem valor. Quase toda semana leio código-fonte para ver o que uma dependência faz.
    Com isso, consigo criar um workaround rápido e, em geral, também relatar o bug.

• Empresas não se importam tanto assim com o código em si. Mesmo quando se importam, cláusulas de continuidade de negócios podem reduzir a maior parte das preocupações com software fechado.
  No fim das contas, quantas instituições financeiras trocaram Excel por OpenOffice Calc?
  A estratégia de entrada no mercado da AWS dependia de atrair startups e desenvolvedores individuais oferecendo serviços pay-as-you-go de baixo custo, e essa parte se encaixou muito bem. Afinal, Airbnb, Stripe, Twitch e outras cresceram até virar grandes empresas junto com a AWS.
  Pouca coisa consegue competir com baixo custo ou gratuidade. Depois é só subir para o mercado enterprise. Pergunte à ARM e à Intel.
  Para startups de ferramentas de desenvolvimento, o open source virou praticamente a estratégia padrão de entrada no mercado. Como o texto aponta corretamente, porém, isso não é um modelo de negócio.
  Portanto, a menos que você seja excepcional no nível da Snowflake e também consiga enfrentar o campo livre e open source de empresas como a Databricks, o modelo open core é melhor.

  • Isso faz sentido para ferramentas como o Excel, mas em coisas como infraestrutura de servidor, especialmente grandes empresas de tecnologia têm muita resistência a colocar algo em produção sem acesso ao código-fonte.
    Se puderem compilar por conta própria, preferem muito mais.
  • Ainda não participei de uma startup em estágio inicial que realmente se preocupasse com custos. Em geral, se preocupavam mais com tempo do que com custo, e consideravam que comprar Amplitude, Segment, AWS, Heroku etc. era mais rápido do que as alternativas. Esse julgamento estava certo ou errado, mas era assim.
    Se você estiver rodando Postgres por conta própria em servidores físicos, os investidores ou não vão se importar, ou vão fazer perguntas difíceis sobre quanto tempo você desperdiçou. Nessa hora, você precisa ter uma resposta bem boa ou um investidor que simpatize com a ideia.

• É surpreendente não mencionarem lock-in de fornecedor. É um argumento de venda claro do open source.

  • Concordo. E isso nem é um ponto pequeno. Do ponto de vista de quem toma decisões, é uma das principais considerações.
    Claro que varia conforme a organização e as pessoas, e muita gente não se importa com lock-in se for uma empresa em que confia, mas isso definitivamente não é zero.
    Quando eu trabalhava na Red Hat como consultor de OpenShift, encontrei muitos executivos preocupados com lock-in de fornecedor. Para eles, escolher OpenShift era uma decisão óbvia.
  • Na prática, o texto dá a entender a ausência de lock-in de fornecedor quando fala que é possível migrar para self-hosting.

• Isso só é tangencialmente relacionado à venda de software, mas muito tempo atrás vendi uma atualização de interface de usuário para um jogo com um design péssimo.
  Cobrei o dobro do preço do próprio jogo, e mesmo assim as pessoas compraram. Porque tinha sido projetada profissionalmente.
  Eu, como designer profissional, tirei tempo do meu trabalho principal para fazer algo que aquele desenvolvedor provavelmente não conseguiria fazer.
  Nos comentários da plataforma de distribuição digital onde eu vendia, a reclamação mais evidente era que a atualização era cara demais, e as pessoas obviamente comentavam sobre o posicionamento de preço.
  Mas uma coisa era clara: o jogo em si era barato demais.
  Se as pessoas só reclamam do preço e continuam comprando, isso significa que não têm outra coisa da qual reclamar.
  Pássaros sempre querem comida de graça. Não se deve tentar agradar aos pássaros.
  Além disso, a atualização também foi distribuída ilegalmente e se espalhou bastante entre usuários de cópias piratas. Fiquei até feliz, porque a maioria dos clientes pagou.
  Também ficou claro que eu estava atendendo a um conjunto de funcionalidades que as pessoas queriam e que não estava disponível em outro lugar. Esse tipo de problema é um sintoma até bem bom de que você criou algo que as pessoas querem.

• Muitos projetos de código aberto se tornam código aberto por necessidade, não por escolha
  Alguns produtos só têm alguma chance de adoção se forem criados como código aberto
  O autor está se concentrando em uma minoria de projetos de código aberto de elite, e eles não representam a maioria dos projetos de código aberto
  Algumas empresas têm as conexões certas nos negócios e no governo, então conseguem vender facilmente licenças de produto por valores altos, mas esses casos são minoria
  A maioria das pessoas e pequenas empresas não tem esse tipo de rede. Sem a rede de negócios adequada, é difícil ganhar qualquer dinheiro que seja
  Não importa quão bom seja o produto, nem quanto ele possa reduzir os custos de alguém. Ninguém acredita, ninguém sequer testa. Mesmo que os ganhos de longo prazo possam ser enormes, a barreira de adoção é alta demais
  Tornar o produto de código aberto é a única forma de ao menos colocar o pé na porta. Porque dá ao produto uma chance mínima de ser notado e, às vezes, isso é tudo