Most of the methods I want to use reach me as a GitHub link. The paper tells me why something should work. The repository is where I find out whether it runs.
We tried to put a number on that shift. In Scopus, English language records from 2013 to 2024 that mention GitHub alongside drug discovery terms such as virtual screening, docking, QSAR, cheminformatics, ADMET and pharmacophore modeling grew by roughly 60 percent in 2024 over 2023. Read that as a count of how often people say they used GitHub, not of how often they did: anyone who used it quietly is invisible to the query. The direction is still hard to miss.
The full analysis is in a report I wrote with Lana Bustanji, Richard Bryce and Mohammad Ghattas, now out in Expert Opinion on Drug Discovery.
A public link is not the same as a reproducible result. Cheminformatics stacks are version sensitive in a way that punishes casual sharing: one RDKit build, one PyTorch, a docking engine compiled against something you do not have. Code with no pinned environment runs on the author's machine and nowhere else. Add the randomness inside model training and the same repository can hand you two different answers on two different afternoons.
What I look at before I rely on a repo
A README that says what the tool is for and where it fails. A license, because without one you cannot legally reuse the code however friendly the README sounds. A pinned environment: a conda file, a lockfile, a Docker or Singularity image. Tests that run on every commit, so a silent break shows up as a red badge instead of as a wrong number in your table. A tagged release, archived with a DOI where possible, so the paper points at one state of the code rather than at a branch that keeps moving. And some statement of how the model was validated: which benchmark, which split, what was tried and dropped.
Stars and forks tell you a project is popular. They say nothing about whether it was validated outside the data it was trained on. Public benchmarks in this field lean heavily on well studied target classes, kinases and GPCRs above all, so an impressive reported metric can mean the model learned that neighborhood rather than the chemistry.
How far in you need to go
That depends on what the project ships. If there is a web server, start there: no install, and ten minutes tells you whether the tool answers your question at all. If not, look for a package on PyPI or conda, a versioned release, or a container image you can pull straight into your environment. If none of that exists you are reading source code, and the example notebook is the fastest way in, because it shows the input shapes the author actually tested.
The argument we make in the report is that a repository should be treated as a research output a reviewer can assess, not as supplementary material stapled to a PDF. That sounds like more work than it is. Intended use and limits written down, an environment someone else can install, a license, tests, a versioned release with a DOI: that is an afternoon of effort for code you already wrote.
The first repository I ever opened made no sense to me and I assumed the problem was me. Often enough it was the repository. If you are starting out, take one tool you already cite and try to run it on a molecule of your own. Where it breaks is the useful part, and it usually tells you something the paper left out.