Várias razões vêm à mente.
- O código é muito grande para artigos. Por um curto período de tempo, projetos interessantes foram curtos o suficiente para serem publicados com o artigo que os descreveu. Isso ainda pode acontecer, mas muitos projetos de tamanho suficientemente grande para serem interessantes cresceram demais para serem publicados com os artigos que os descrevem.
- Os hosts públicos não são gratuitos nem duráveis. Até recentemente, hosts públicos baratos, duráveis e fáceis de acessar não estavam disponíveis.
- Publicar um artigo é mais fácil do que publicar um projeto. Algumas pessoas têm tempo para publicar um trabalho ou um projeto, mas não os dois.
- Incentivos ligados ao papel. Muitos anos atrás, perguntei a um colega sobre desenvolvimento de produtos e patentes e recebi a notícia de que a maioria das pessoas de lá fazia praticamente um ou outro. Tal como acontece com escritores de papel (think academia) e desenvolvedores de código aberto, as recompensas são voltadas para um produto de trabalho ou o outro.
- Auto motivação. O desejo de descrever idéias ou implementar código nem sempre está presente em partes iguais na mesma pessoa. Muitos de meus professores admitiram abertamente que ou nunca codificaram muito, ou que estavam muitos anos longe de terem sido codificados fluentemente. Da mesma forma, muitos desenvolvedores mal querem escrever comentários em seu código ou quando se comprometem com o controle de origem.
- A durabilidade da hospedagem do projeto e do produto de trabalho também é um problema. Quem quiser ligar em algum lugar que possa ter desaparecido daqui a alguns anos e, como resultado, diminuir o valor do papel.
-
Tradição. Os editores são orientados a revisar e publicar trabalhos, mas podem não estar prontos para fazer a mesma avaliação de projetos.
Também as visões tradicionais sobre o que é um nível razoável de reprodutibilidade varia entre os campos. Espera-se que um químico que publique um artigo sobre um novo método de síntese anote detalhes suficientes para que outro químico realize a síntese. Não se esperaria que ela enviasse os produtos e o material para o periódico. Espera-se que os leitores que queiram usar / reproduzir o trabalho comprem seus próprios estudos e façam a síntese em seus laboratórios (embora possam pedir para entrar e visitar o laboratório para ver como isso é feito na prática). Nem seria esperado que um biólogo ligasse seus novos camundongos transgênicos ao papel. Esta vista na reprodutibilidade corresponde a e. dando uma descrição (pseudo-código) do algoritmo em oposição ao envio da implementação real. - O código nu pode ser chocante . É preciso muito menos polimento para revisar um documento de comprimento de papel do que para inspecionar código, revisão de código e qualidade para garantir um projeto. Eu tenho um monte de código que eu ficaria mais à vontade para contar do que mostrar a você. Espero que as coisas estejam avançando a um ponto em que todos nós iremos escrever um código bonito, mas se seu código foi apressado, mal ou não funciona completamente, você pode estar mais confortável em não compartilhar os executáveis ou a fonte.
- Fonte fechada. Nem todos adotaram o código aberto. Muitos trabalhos são escritos sobre o trabalho para o DoD, projetos comerciais ou projetos financiados pelo setor privado, onde há benefícios da exposição do projeto ao público, mas ainda há segredos comerciais ou vantagens de mercado que poderiam ser corroídas pelo fornecimento aberto do código ou outros produtos de trabalho.
- Publique trabalhos adicionais com base neste código. Se o código não for publicado, poderá dar ao autor uma vantagem na publicação do trabalho de acompanhamento. Outros pesquisadores concorrentes podem precisar reimplementar o trabalho, o que pode levar um tempo precioso.