Ótima pergunta e ótimas respostas, mas acho que nenhuma aborda adequadamente a questão da persistência, se o objetivo é atingir o mesmo padrão concedido à própria publicação. (Que pode ser bobo devido às chances de o código ainda ser executado , mas ainda assim ser pelo menos tão útil quanto a publicação).
Os suplementos de periódicos de sites da universidade não são persistentes
É improvável que os sites da universidade forneçam estabilidade ou redundância para preservar o conteúdo hospedado. O conteúdo é mais difícil de citar e geralmente não possui metadados legíveis por máquina.
Infelizmente, parece que os periódicos não estão se saindo muito melhor na manutenção de seus materiais suplementares (ver Anderson et al. 2006 ) e podem não aceitar os formatos necessários, ou até mesmo aceitar material suplementar (veja um exemplo notável ).
Por esses motivos, as pessoas preocupadas com o arquivamento de dados a longo prazo voltaram-se por unanimidade à defesa do uso de repositórios dedicados, em vez de sites ou materiais complementares, e muitos periódicos agora exigem essa prática . Parece justo que o código seja mantido com esse padrão.
A solução de muitas cópias?
O Github e sites relacionados ainda não comprovaram a longevidade na escala de cem anos alcançada pelas bibliotecas universitárias e pelos editores estabelecidos. Ao facilitar a distribuição ampla, ele pode fornecer uma solução que outros ecoaram nos comentários, incluindo um colega que não pôde comentar sobre a troca de pilha,
... vamos salvar o que resta: não por cofres e fechaduras que os cercam dos olhos do público e os consignam ao desperdício de tempo, mas por uma multiplicação de cópias, que os colocará fora do alcance do acidente.
- Thomas Jefferson, 18 de fevereiro de 1791
Figshare e o padrão CLOCKSS
O único padrão de arquivamento que conheço é o figshare , que pode aceitar repositórios de código completos (como "conjuntos de arquivos" no momento, mas acredito que em breve terá a opção de ser listado como tipo "código"). A peça chave para o figshare não é apenas o DOI citável com metadados programáticos, mas o suporte do serviço de arquivamento CLOCKSS , que mantém cópias de todo o seu conteúdo em 12 nós geograficamente e geopoliticamente distribuídos em todo o mundo. Caso o figshare saia do negócio ou deixe de existir, isso fará com que todo o seu conteúdo seja disponibilizado gratuitamente no CLOCKSS.
Consequentemente, sugiro usar o Github para distribuição de código, mas também fornecer uma cópia de arquivo para o figshare no momento da publicação.