Journals and funding agencies are increasingly requesting a statement regarding the software and code used for analysis.  Nature has published articles and opinion pieces since 2012 arguing for open computer programs in the interest of reproducibility. For code and software, impact is highly conflated with use.

Scientific Data, PLOS Computational Biology, and Journal of Open Research Software have published tips for sharing code including recommendations to:

• Providing licensing information for how others may or may not use your code
• Provide any source code used for your manuscript as a supplementary files
• Include locations for source code such as a control version repository (e.g. Github) or a DOI minting repository (e.g. Figshare) that can be used for future citations
• Use version control and documentation to describe the process and increase its usability by others

Khodiyar, V. (2012). Code sharing - read our tips and share your own. Scientific Data blog. http://blogs.nature.com/scientificdata/2015/02/19/code-sharing-tips/

Sandve GK, Nekrutenko A, Taylor J, Hovig E (2013) Ten Simple Rules for Reproducible Computational Research. PLOS Computational Biology 9(10): e1003285. https://doi.org/10.1371/journal.pcbi.1003285

Stodden, V. & Miguez, S., (2014). Best Practices for Computational Science: Software Infrastructure and Environments for Reproducible and Extensible Research . Journal of Open Research Software . 2 ( 1 ) , p . e21 . DOI: http://doi.org/10.5334/jors.ay

While much code and software is created for analysis supporting research that can be published in traditional venues, there are an increasing number of places for the code or software to be published for its own sake outside of the project's specific context. Examples include the Journal of Open Research Software:  and the Journal of Open Source Software.

These utilize a combination of journal platforms and data repositories.  The Journal of Open Source Software, for instance, houses software in Zenodo, a DOI minting repository that also functions as a cloud-based research workspace.

GitHub is a web-based hosting service for version control using git.  It can be used to host software, code, and even websites. For each repository, it includes an Insights panel that provides information on interactions with your repository.  For discussing GitHub metrics with peers unfamiliar with the terms, it can be helpful to talk about terms such as issues, forks, contributors, in relation to the traditional publication and peer review process.  Github also has a glossary of terms available here: https://help.github.com/articles/github-glossary/

• Pull Requests - proposed changes submitted by a user to be accepted or rejected by the owner(s) of the repository. This process can be construed as similar to editing a work.
• Issues - suggested improvements by other users, can be construed as peer review as appropriate.
• Collaborators - users with read and write access to a repository, can also be construed as co-authors as appropriate
• Commits - revisions to a file, demonstrative of active updates, maintenance, and development.
• Contributors - anyone who has contributed to the project by having a pull request merged, but is not a collaborator. This can be construed as editing as appropriate.
• Forks - personal copies of the repository that live on another user's account.  Forks allow users to contribute to a project, as well as make use of it for their own project.  This can be construed as uses by others.