Tornamos código aberto algo que vale milhões. De propósito.

Vamos ser sinceros. A maior parte do software que move equipes modernas — seu CMS, suas ferramentas de design, seus apps de comunicação — é de código fechado. E, por muito tempo, isso pareceu нормально. Desenvolver software era caro, e quem o criava merecia ganhar dinheiro.

Mas algo mudou. A qualidade do software está indo visivelmente para o buraco em câmera lenta, e a parte mais frustrante é: você não pode fazer nada a respeito.

Cada atualização é um jogo de azar. Vai ficar melhor? Pior? Será que a funcionalidade da qual seu fluxo de trabalho depende vai quebrar silenciosamente? Você não sabe, porque não pode ver o código. Não consegue consertar. Não consegue fazer um fork. Você só fica preso, torcendo para que a equipe se importe o suficiente para fazer direito.

A era da IA piorou isso drasticamente. As equipes estão entregando mais rápido do que nunca — mas mais rápido não é melhor se ninguém é responsabilizado pela qualidade do que é entregue. Código fechado na era da IA significa que a bagunça se acumula em silêncio, e você só descobre quando a coisa para de funcionar.

Nós nos recusamos a construir esse tipo de produto.

Algo muda quando você torna algo importante open source. De repente, você não pode se esconder atrás de roadmaps vagos nem de um "estamos trabalhando nisso". O código está ali. Seus usuários podem lê-lo, fazer um fork e te chamar publicamente quando ele seguir na direção errada.

Essa responsabilidade é exatamente o que queremos.

Quando o b10cks toma o rumo errado — e todo projeto acaba fazendo isso em algum momento — você não fica esperando a gente priorizar o seu problema em algum backlog interno. Você pode olhar o código, entender o que está acontecendo e consertar. Pode enviar um PR. Pode fazer um fork e seguir seu próprio caminho. Ou pode simplesmente nos mostrar código funcionando que prove que a sua solução é melhor.

É assim que o software deveria funcionar. É assim que o b10cks funciona.

Existe uma mudança de mentalidade que separa os grandes engenheiros dos bons. Grandes engenheiros não aceitam limites arbitrários nos sistemas com que trabalham. Quando algo não funciona como precisam, eles não inventam gambiarras. Eles vão à fonte e consertam.

Software de código fechado torna isso impossível. Você bate numa parede, e a parede é real. Não dá para contorná-la. Você tem que conviver com ela, improvisar em cima dela ou abandonar a ferramenta por completo.

Open source remove as paredes. Quando o b10cks faz algo que não encaixa nas suas necessidades, você não fica à mercê do nosso planejamento de sprints. Você tem o código-fonte. Pode entendê-lo, modificá-lo, aplicar um patch e executar sua versão corrigida em produção hoje mesmo.

Eu criei o b10cks como open source porque acreditamos que os desenvolvedores que o usam merecem trabalhar assim — e porque eu queria viver com a mesma responsabilidade.

Já vi o que "open source" às vezes significa na prática: uma versão gratuita que não cobre nada, um repositório público sem código de verdade, ou uma licença que é open source até alguém realmente querer usar o produto comercialmente.

O b10cks é licenciado sob a GNU Affero General Public License v3. Veja o que isso realmente significa para você:

Você pode hospedar por conta própria. Para sempre. Sem precisar de permissão, sem chave de licença, sem ligação com o time de vendas. Faça o clone do repositório, rode o Docker, pronto.

Você pode ler cada linha de código. O produto inteiro. Sem bundles ofuscados, sem núcleo fechado com uma casca open source. A coisa que você usa é a mesma que está no GitHub.

Você pode fazer um fork. Se tomarmos decisões com as quais você discorda, você pode levar o projeto para a direção que quiser. Se melhorar algo, você contribui de volta com essas melhorias. Esse é o acordo — e é um acordo justo.

A AGPL fecha a brecha da nuvem. Algumas empresas tornam o código open source sabendo que, de qualquer forma, ninguém consegue competir de verdade com o serviço gerenciado delas. A AGPL significa que, se alguém construir um negócio em cima do b10cks, essas modificações continuam abertas. A comunidade que construiu isso fica protegida.

Ganhamos dinheiro operando um ótimo produto hospedado. Não te prendendo a ele.

Aqui vai a verdade desconfortável sobre o desenvolvimento assistido por IA: ele amplifica os incentivos existentes. Equipes que priorizam qualidade entregam qualidade melhor e mais rápido. Equipes que priorizam entregar rápido entregam bagunça mais rápido.

Em um ambiente de código fechado, você não tem como saber com qual dos dois está lidando até o estrago já estar feito. Você não consegue auditar a base de código. Não consegue ver o que foi mesclado sem revisão. Não consegue acompanhar a proporção entre arquitetura bem pensada e patches gerados por IA que ninguém entendeu por completo.

Open source é a resposta para isso. O código é visível. O histórico de commits é visível. Os PRs, as revisões, as discussões — tudo isso está aberto. Se o b10cks algum dia começar a entregar bagunça, você vai ver antes de sentir. E vai ter as ferramentas para fazer algo a respeito.

Na Coders Cantina, apostamos nossa reputação em construir tecnologia que realmente serve às pessoas que a usam — e não tecnologia que otimiza métricas de retenção à custa da qualidade. Open source é como provamos esse compromisso, em vez de apenas afirmá-lo.

Algumas pessoas ouvem "open source" e assumem que isso significa algo insustentável, ou um presente financiado por capital de risco que acaba, mais cedo ou mais tarde, em uma guinada ou mudança de licença. Já vimos essa história também.

O b10cks é construído sobre um modelo direto: o software é livre e aberto. A hospedagem gerenciada — a conveniência de não precisar operar infraestrutura — é o que cobramos. Só isso. Armazenamento e tráfego. Sem cobrança por usuário. Sem níveis de recursos. Sem upsell.

Isso funciona porque quem quer operar a própria infraestrutura vai fazer exatamente isso. E quem quer um produto hospedado confiável e bem mantido vai pagar um preço justo por ele. E a qualidade do produto hospedado se mantém honesta pelo fato de que a alternativa de auto-hospedagem está sempre a um git clone de distância.

Não somos os primeiros a tentar esse modelo. Somos só os que estão construindo o CMS de que o seu time realmente precisa — com a convicção de que a forma certa de fazer software é a única forma como queremos fazê-lo.