Executando verificação de segurança...
6
fredamaral
2 min de leitura ·

[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

Carregando publicação patrocinada...
5
clacerda

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.

1
valterpatrick

Concordo com você.
Um bom exemplo é a comunidade do ACBr que é gigantesca e está crescendo cada vez mais.
Todo mundo ajuda por que é ajudado.
Eu já criei componentes e compartilhei, fiz alterações em códigos.

Faça um forum, a sua equipe tem de ser bem ativa no fórum para ajudar o pessoal, além da documentação simples e bem acessível.

1
fredamaral
Autor
Autor

e vcs acham que o forum do proprio github (discussions) eh um bom lugar? alem disso, a nossa documentacao hoje esta no gitbook. seri legal migrar para o wiki do github e concentrar tudo la?

2
valterpatrick

Eu recomendo você a analisar a situação do Projeto ACBr (https://www.projetoacbr.com.br/forum/).
Crie um site com documentações bem claras e um forum igual eles, algo a parte e de vocês não o github por exemplo, agora a documentação no gitbook não teria problema.
Faça também videos e mostre funcionando.

Manda os seus links ai para a gente acompanhar, estou interessado na sua solução.

2
rafael

Acredito que seja uma situação bem diferente. O ACBr usa SVN, e o projeto surgiu antes mesmo do Git, então precisou utilizar outras formas de comunicação na época e provavelmente manteve até hoje, com poucas adaptações, e os fóruns eram bem populares naquela época, hoje já não são. É um raciocínio similar para entender os projetos em que a comunicação ainda ocorre por listas de e-mail.

Além disso, os projetos que utilizam ACBr também, muitas vezes, acabam utilizando o SVN por serem antigos e às vezes as pessoas que trabalham nesses projetos não tem familiaridade com o GitHub. Seu meio de comunicação precisa estar alinhado com seu público.

Particularmente, acho que faz zero sentido criar um fórum para tentar se comunicar com uma comunidade sendo que o projeto está surgindo hoje, direto no GitHub. Ter que criar a conta no fórum para se comunicar e entender como ele funciona seria um atrito extra. Muitos projetos grandes estão apenas no GitHub, alguns estão também no Discord (eu não gosto e tem vários pontos que considero negativo, mas pode fazer sentido para a empresa). Ah, o ACBr também está no Discord, por exemplo.

1
1
clacerda

Existe documentação de usuário e de desenvolvimento, manter a documentação de usuário no gitbook não é um problema, mas se você quer incentivar a coloboração dos tais desafios intelectuais, mantenha todos os design docs, dentro do repositorio e não no wiki. A boa e velha pasta docs/

O Github funciona bem como ponto de encontro da comunidade, mas não acho que deva ser o único. Nunca é inteligente colocar todos seus ovos na mesma cesta. E falta principalmente mensagem instanea, pra isso tem muito projeto que usa o irc até hoje, e o discord entrou na moda, mas existem alternativas melhores como o Zulip.

2
klawdyo

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.

1
1