Recompensas de código-fonte aberto


11

Eu tenho uma biblioteca para R (pacote de estatísticas de código aberto) mapeada no papel. Comecei a codificar as diferentes funções, mas percebo que não tenho o tempo necessário para concluir isso em um período de tempo razoável. Eu sei que posso simplesmente vomitar o código em um repositório e chamar outras pessoas para ajudar a preencher os espaços em branco. Mas gostaria de incentivar um pouco as coisas. Estou pensando em colocar uma recompensa em cada função de, digamos, US $ 5 a US $ 20. Não há como US $ 20 ser um retorno justo no tempo para um desenvolvedor codificar cada função. Mas meu pensamento é que o dinheiro (ou vale-presente da Amazon) seria uma invenção para as pessoas realmente trabalharem no projeto. E isso me permitiria oferecer prêmios mais altos nas funções nas quais estou mais interessado.

Eu tenho algumas perguntas relacionadas a isso:

  1. Boa ideia?
  2. Vou fazer o desenvolvimento funcionar mais rápido ou mais devagar? Eu li Previsivelmente Irracional e estou preocupado que, ao oferecer um pagamento menor por funções, eu possa realmente desestimular os desenvolvedores.
  3. Existem sites dedicados a esse tipo de atividade? Você pode recomendar um baseado na experiência pessoal?
  4. Você recomendaria uma abordagem totalmente diferente? Estou aberto a idéias!


Acontece que uma pergunta mais recente era uma duplicata desta: programmers.stackexchange.com/questions/79561/…
user16764

Respostas:


10

Não é uma boa ideia, na minha cabeça. Nenhum dos programadores de OSS que conheço responderia a essa recompensa.

Então, o que incentiva as pessoas? De acordo com Dan Pink, as pessoas são motivadas por:

  • Autonomia
  • Domínio
  • Objetivo

Depois, para atrair bons programadores, encontre uma maneira de fornecer alguns ou todos esses itens.

Uma segunda abordagem que pode ser feita simultaneamente à primeira é exibir uma home page que rastreia o andamento do projeto, mostrando o status de cada uma das funções junto com a pessoa que forneceu a função que passou nos testes de unidade (você deve tem testes, certo?).

Por fim, foi minha experiência que um projeto atraente não precisa de muita ajuda para atrair colaboradores. Dê uma olhada no que você está fazendo e, se estiver com dificuldades para atrair e manter os programadores trabalhando nisso, pense no que isso está lhe dizendo sobre a utilidade do seu projeto.


isso parece ser uma entrada muito boa. Eu li-de-rosa bem e suas idéias são parte da voz irritante na parte de trás da minha cabeça que continua me dizendo "isso pode não ser uma boa idéia"
JD Longo

youtube.com/watch?v=u6XAPnuFjJc <- Conheço Dan Pink neste vídeo.
Joe Z.

7

https://www.bountysource.com

Na página sobre:

O BountySource foi originalmente criado em 2004 com a esperança de aumentar e melhorar o desenvolvimento em comunidades de software de código aberto. A primeira iteração do BountySource forneceu uma variedade de ferramentas que permitiram o gerenciamento fácil de projetos de código aberto. Algumas dessas ferramentas incluem um rastreador de tarefas, um repositório de códigos SVN e um sistema de gerenciamento de conteúdo.

O BountySource estava muito à frente de seu tempo ... gostaríamos de pensar nele como um antecessor do GitHub.

Após um longo hiato, estamos de volta com a mesma visão - melhoria geral no desenvolvimento de software de código aberto - mas com um sistema completamente diferente.

Estamos mudando nosso foco da hospedagem de projetos - repositórios, rastreamento de problemas e tudo - para o aspecto de crowdfunding da idéia original do BountySource.


3

Lembro-me de ver alguns sites durante os dias pontocom que eram basicamente exatamente o que você descreve. As pessoas publicavam pequenas tarefas de codificação que desejavam realizar, uma quantia de $ e as pessoas podiam se registrar para executar a tarefa mencionada - havia algumas variações sobre esse tema, mas essa era a ideia básica. Recém saído da escola e procurando um moolah extra, eu costumava bisbilhotar e procurar um bom para fazer. O resultado? Eu nunca fiz um único. Invariavelmente, eu olhava para as tarefas (que eu poderia fazer) e fazia um preço / desempenho em minha cabeça e percebia que realmente não valia a pena me preocupar (exatamente o que você faz no item 2). O outro problema era que quase todos eles não eram problemas convincentes - havia uma razão pela qual estavam sendo criados :)

Concordo com o KevDog que se você tiver um projeto interessante e um PR decente (divulgando a notícia), as pessoas o encontrarão e farão o trabalho de graça. Embora eu nunca tenha percorrido a rota mercenária, certamente contribuí com código aqui e ali para projetos de OSS que me impressionam.


obrigado pela sua opinião, Jeff. Isso faz todo o sentido.
JD Longo

0

Eu não acho que a idéia esteja completamente fora do campo de possibilidade, no entanto, o paradigma de custo por tarefa não funciona, pois não é econômico para o desenvolvedor nem escalável proporcionalmente.

Eu acho que um sistema melhor pode ser $ / Line Of Code, onde o referido local reside no controle de versão por x quantidade de tempo e não é comprometido por razões de incompetência (por exemplo, bug).


3
Posso inserir linhas de código se tiver um incentivo.
David Thornley

De fato. A resposta foi a representação de 176 caracteres de uma idéia básica, no entanto. Qualquer idéia que entra em produção precisaria de muitas, muito mais regras e salvaguardas.
Craige

1
Mas suas três primeiras linhas são totalmente desnecessárias, ou seja, são preenchimentos inúteis. Se você é pago pela linha, provavelmente você pode esticá-la em pelo menos um par de mais linhas ...
jmoreno
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.