Executando verificação de segurança...
5

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.

Carregando publicação patrocinada...
1

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

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

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

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

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.