[discussão] como criar uma comunidade ao redor de um produto open source com algum viés comercial?
fala, pessoal.
há poucos dias atrás postei aqui sobre o lançamento do nosso repositório aberto do midaz, uma stack de banco de dados transacional para bancos/fintechs em geral, com integrações para pix, processamento de cartão de débito, crédito, processamento de pagamentos (via gateways de pagamentos), etc.
agora o nosso grande desafio começa. sei que a comunidade open source muito pouco contribui com código em produtos que tem um viés comercial que seja (como o nosso, que é open source em distribuição, mas possuirá plugins que terão custo, além de ofertar a possibilidade de hosting na nossa infraestrutura também com um custo). a maioria dos projetos open source com viés comercial possuem pouca contribuição da comunidade em código, mas vários deles possui muita, bastante interação da comunidade em críticas, sugestões, discussões sobre features, arquitetura, etc.
e é justamente aí que eu gostaria do apoio da comunidade. para construirmos um produto que sim, pode ser utilizado por qualquer empresa/indíviduo, pelo seu caráter open source (inclusive com stack de infra up and running helm/docker), mas que mais do que isso, tem um diferencial competitivo importantíssimo frente às opções do mercado como ledgers closed-source (pismo, matera, temenos, mambu, dock, cmsw, swap, pomelo, entre outros).
e aí entra minha dúvida. como incentivar a comunidade a construir junto conosco sob a perspectiva de produto (e não de código)? como incentivar a comunidade a entrar em discussão conosco sobre temáticas profundas de design pattern (ie. race condition, circuit break, sincronismo de dbs acid em múltiplas instâncias etc.), ou seja, desafios intelectuais realmente.
tenho pensado seriamente em nem sequer oferecer a via de hosting deste ledger, dado que seria algo "pago" (por motivos óbvios, custos de infra do nosso lado), para que não haja conflito entre construção do produto x viés comercial, e sim cobrar efetivamente sobre plugins diversos que criaremos do nosso lado (e que espero que o mercado também construa).
thoughts? divagações aqui, mas adoraria ouvir vocês.
links: https://github.com/LerianStudio/midaz https://docs.midaz.io/midaz/overview/introduction/getting-started https://docs.midaz.io/midaz
Uma documentação clara, completa e acessível é o básico. Ela deve fornecer tudo o que é necessário para começar rapidamente, desde configurações iniciais até exemplos de uso complexos, abrangendo todos os aspectos e capacidades do produto. Há vários estudos e pesquisas que apontam a qualidade da documentação como um dos fatores mais críticos na adoção de projetos de software open source. E, obviamente, para fomentar a colaboração, toda a documentação deve estar disponível diretamente no repositório. Não se esqueça dos "design docs" que são a ferramenta para construir o que você chamou de "desafios intelectuais realmente" colaborativamente. Exemplo relevante.
Patrocinar meetups e conferências é uma estratégia eficaz para fortalecer sua marca e cultivar uma comunidade. Participar ativamente desses encontros não só aumenta a visibilidade do seu projeto, mas também facilita a intereção direta com os usuários.
Além disso, a distribuição de brindes, como camisetas e adesivos,desempenha um papel crucial na construção de um sentimento de pertencimento e engajamento comunitário. Esses itens são poderosos em transformar participantes casuais em divulgadores do seu projeto. Eles também podem ser usados como recompensas por contribuições significativas.
No entanto, é importante ter expectativas realistas sobre as contribuições de código no contexto de projetos open source com viés comercial: as contribuições são na realidade bastante escassas, ainda assim o esforco com estas práticas essenciais é grande: revisões de pull requests de maneira precoce e frequente, discutições exaustivas de problemas nas issues e até mesmo ajudar as pessoas a resolverem questões por conta própria.
Dito isso, acredito que ter no time um gerente de comunidade (community manager) experiente em projetos de software aberto é essencial. Se não for possível contratar um,considere uma consultoria especializada para ajudar a criar estratégias eficazes e treinar sua equipe para implementá-las.
Você realmente precisa pensar cuidadosamente sobre o seu modelo de negócios, considerando o que é aberto e o que é fechado. Eu pessoalmente gosto muito do modelo da Red Hat de vender apenas suporte e implantação. Mas o que vejo como mais viável é manter a maior parte do código de infraestrutura aberto, e vender apenas a "cereja do bolo", que é construída por cima. Isso é realmente difícil de determinar, de encontrar o que é essa "cereja do bolo" e desenhar essa linha. Não é só uma questão de vender o serviço e deixar o código disponível para quem quiser hospedar por conta própria. E claro, tem o modelo do Qt também, que também é bem interessante. Você pode deixar o código aberto para qualquer um usar sem fins comerciais e vender uma licença para as fintechs que quiserem usar. Acho que isso pode ser muito mais atrativo do que o modelo de assinatura que tomou conta da web.
Eu, como usuário de projetos neste estilo e, inclusive, em busca de um financeiro, me interessei por saber mais quando foi feito o primeiro anúncio. Confesso que desanimei ao não ver nada na documentação. Eu simplesmente não consegui entender o real propósito. Então, além do que ja foi dito acima, deixo aqui meus 2 centavos:
- A contribuição não necessariamente vai ser com código. Reportar bug, comentar, divulgar... tudo isso é válido.
- Às vezes eu vejo em comunidades vários pull requests, às vezes feitos há meses ou até mesmo há anos atrás que nunca foi implementado ou analisado. Isso desmotiva quem quer contribuir. Pois você tem um trabalho do cão pra estudar o código de outra pessoa, achar um erro, corrigir, enviar de volta de todo bom grado e ser ignorado. Eu, sinceramente, nem inicio.
- Educação: às vezes vejo em comunidades onde o membro da equipe trata super mal as pessoas que abrem issues. Deixam aquela impressão de "eu que mando nessa oorra, se achou ruim, procure outro ou faça um pra você". Isso é bem comum. Eu acho que, primeiramente você precisa definir se você quer ajuda da comunidade pra tocar seu projeto, ou se você quer tocar um projeto junto da comunidade. A comunidade vai opinar ou quem manda é você e pronto? Eu acho que essa é um bom ponto de partida. Dizer logo a que veio.
- Eu acho que a ideia de deixar o código aberto e vender a assinatura para quem não quer ou não tem conhecimento de implementar sozinho é excelente ideia. Você está passando para a comunidade que você realmente tem foco naquele projeto. Nao é algo de fim de semana. A gente terá confiança que aquele negócio estará evoluindo.
Do mais... não tem muito mais para onde correr: divulgue, crie um blog com postagens relevantes sobre algo da moda e mostre como isso se aplica no sistema, postagens no tabnews, dev.to. medium etc... A comunidade vai surgindo conforme for ficando famoso e as oessoas forem se interessando em usar. Quanto mais gente usar, mais gente estará sentindo a dor dele ou tendo ideias. Projetos open source, às vezes, demoram anos até bombar. Às vezes nunca bombam. Mas se você está conseguindo gerar lucro vendendo acesso ao seu próprio servidor, é um ótimo indício que a comunidade vai adotar em breve.