Fechar o código não é o mesmo que entregar a diferença🔥😵 Muita gente vê o repositório do projeto Grant entrar no ar e já começa a comemorar, achando que “deu certo”.
Mas quando eu leio os requisitos do programa @Dusk Grants, minha atenção fica pregada no último milestone: o candidato precisa incluir no plano de manutenção de um ano.
Um ano. Não é “se houver problema, abra um issue”; é uma exigência rígida, escrita a preto no branco na lista de entrega.
A Dusk ainda exige documentação complementar, testes e passos de instalação/execução reproduzíveis. Traduzindo para português claro: você consegue um time de suporte, mas não pode só acender os recursos no dia da demonstração — precisa deixar as pessoas que vierem depois conseguirem assumir, consertar e manter.
demo é fácil, manutenção é que custa
Para quem se candidata, fazer um demo que roda no curto prazo não é difícil. O código sai e “acende”, o dia da demo passa e pronto.
Só que o que realmente custa vem depois de um ano: a dependência atualiza, alguém abre um issue, e os comandos na documentação não funcionam mais. Nessa hora, o time ainda vai querer voltar para resolver? Se quiser, quem faz? Há horas de trabalho para isso no orçamento?
Muitos projetos, depois de a primeira versão ficar pronta, os membros centrais vão cuidar de outras coisas. O repositório continua lá, os usuários chegam, mas não conseguem instalar. Pergunta ninguém responde. O custo não some; ele só é repassado para o próximo desenvolvedor do ecossistema — e essa pessoa pode ser você, ou pode ser eu.
Essa exigência é uma peneira
Eu não acho que, tendo essa exigência, a Dusk consiga garantir que cada projeto vai ficar ativo por muito tempo. Sinceramente, só uma carta de solicitação não garante nada.
Mas ela acerta pelo menos uma coisa: colocar o custo de “manutenção” com antecedência na solicitação.
Times que aceitam escrever a manutenção de um ano no orçamento parecem mais interessados em entregar infraestrutura do que em concluir uma tarefa única. Essa diferença não dá para ver na hora de se candidatar; um ano depois, ao olhar o status do repositório, fica claro na hora.
O que vale observar depois de <c-1/>$DUSK é se @Dusk vai divulgar o andamento da manutenção desses projetos e o status dos repositórios — dados visíveis são mais honestos do que qualquer promessa. Para o crescimento do ecossistema de #dusk , que haja evidências e continuidade, e não só uma pilha de repositórios que entram no ar e depois entram em silêncio😖.
Mas quando eu leio os requisitos do programa @Dusk Grants, minha atenção fica pregada no último milestone: o candidato precisa incluir no plano de manutenção de um ano.
Um ano. Não é “se houver problema, abra um issue”; é uma exigência rígida, escrita a preto no branco na lista de entrega.
A Dusk ainda exige documentação complementar, testes e passos de instalação/execução reproduzíveis. Traduzindo para português claro: você consegue um time de suporte, mas não pode só acender os recursos no dia da demonstração — precisa deixar as pessoas que vierem depois conseguirem assumir, consertar e manter.
demo é fácil, manutenção é que custa
Para quem se candidata, fazer um demo que roda no curto prazo não é difícil. O código sai e “acende”, o dia da demo passa e pronto.
Só que o que realmente custa vem depois de um ano: a dependência atualiza, alguém abre um issue, e os comandos na documentação não funcionam mais. Nessa hora, o time ainda vai querer voltar para resolver? Se quiser, quem faz? Há horas de trabalho para isso no orçamento?
Muitos projetos, depois de a primeira versão ficar pronta, os membros centrais vão cuidar de outras coisas. O repositório continua lá, os usuários chegam, mas não conseguem instalar. Pergunta ninguém responde. O custo não some; ele só é repassado para o próximo desenvolvedor do ecossistema — e essa pessoa pode ser você, ou pode ser eu.
Essa exigência é uma peneira
Eu não acho que, tendo essa exigência, a Dusk consiga garantir que cada projeto vai ficar ativo por muito tempo. Sinceramente, só uma carta de solicitação não garante nada.
Mas ela acerta pelo menos uma coisa: colocar o custo de “manutenção” com antecedência na solicitação.
Times que aceitam escrever a manutenção de um ano no orçamento parecem mais interessados em entregar infraestrutura do que em concluir uma tarefa única. Essa diferença não dá para ver na hora de se candidatar; um ano depois, ao olhar o status do repositório, fica claro na hora.
O que vale observar depois de <c-1/>$DUSK é se @Dusk vai divulgar o andamento da manutenção desses projetos e o status dos repositórios — dados visíveis são mais honestos do que qualquer promessa. Para o crescimento do ecossistema de #dusk , que haja evidências e continuidade, e não só uma pilha de repositórios que entram no ar e depois entram em silêncio😖.