biotools: a hand-curated list of bioinformatics software and data

One author's reading list, openly marked as untested

The description of this repository is short: a list of useful bioinformatics resources. What makes it interesting is the honesty attached to it. The author writes that the collection is sourced from recent literature and organized by topic, and then adds that he has not used most of these tools.

That sentence changes how you should read every entry. This is not a benchmark suite, not a comparison table and not a set of house recommendations. It is a reading list built from papers, which means the inclusion criterion is that a tool was worth writing about, not that it survived evaluation by the list's owner.

That also tells you what to expect from the entries themselves. Each one is a name, often a short description, and a URL. There is no version pinned, no licence recorded per tool, no star count, no line about what the tool is bad at. If you need those, you have to go to the project itself.

For a reader deciding whether a tool is worth an afternoon, a broad, cheaply maintained index is still useful. It is a map of where tools exist, written by someone who reads the literature, and the taxonomic structure means you can drill into a niche without scanning everything.

The repository is MIT licensed and consists of four files: README.md, DEAD.md, UNMAINTAINED.md, a LICENSE file and a gitignore.

DEAD.md and UNMAINTAINED.md are the list's own quality control

The curation policy is the most useful feature here, and it is easy to miss because it lives in a single paragraph near the top.

Tools whose links are dead, whether from a 404 or a DNS failure, are moved to DEAD.md. Tools hosted in repositories with no activity for two or more years are moved to UNMAINTAINED.md. The author asks that if a tool has been moved by mistake, an issue should be opened through the repository's issue tracker.

So the main file is, by construction, the list of things currently worth a look, and the two side files hold the residue. That is a real service: link rot in bioinformatics is common because academic projects get hosted on personal pages and lab servers that disappear when a grant ends, and a plain link list would rot quietly without anyone noticing.

Two limitations sit alongside that. The dead link check is a one-time observation, so an entry can go bad the day after the check. And the two year inactivity rule says nothing about whether a project is abandoned or merely quiet. Plenty of sound software sits untouched for years between releases, and it would land in UNMAINTAINED.md on the strength of repository activity alone.

For a reader, the practical routine is to check both side files before spending time on an entry, and to check the linked project rather than the list entry.

A topic tree deep enough to hold most of bioinformatics

The organization is a Markdown table of contents with several levels of nesting, and it reads like a taxonomy of the field rather than a flat tag list.

The top level covers clinical data with an EHR subsection, data management, data sets, discovery, AI, genomics, proteomics, general programming resources, statistics and machine learning, visualization, publication and archiving, and a closing category for promising methods that have no software implementation.

The genomics branch is the deepest and most granular. It splits into general information, algorithms with a pairwise alignment subsection, assay design, candidate prioritization, databases, data formats, functional enrichment and ontology, GWAS and QTL, microarray, motif and TFBS, network analysis, population genetics, prediction, security, sequencing protocols, simulation, variant annotation, and a sequence analysis branch that itself splits by assay: general-purpose, QC, peak-based with ChIP-seq and chromatin accessibility, chromatin interactions, DNA, footprinting, gene editing, metagenomics, methylation, MNase-seq, Nanopore and PacBio, RNA, single-cell, somatic, and multi-omics integration.

The programming section goes further into languages, splitting into C and C++, R with find packages, database, data cleaning, reporting and misc subsections, Python, HPC, command line work on OSX and Linux, and reproducibility and containerization with pipeline building and software distribution. Visualization has its own genome browser, network, phylogenetic tree, ggplot2, plot type, data type and interactive branches.

The anchor list shows the level of nesting directly:

- [General Programming Resources](#general-programming-resources)
  - [C/C++](#cc)
  - [R](#r)
    - [Find packages](#find-packages)
    - [Database](#database)
    - [Data Cleaning](#data-cleaning)
  - [HPC](#hpc)

A tree this fine is navigable in the rendered Markdown but painful to read as raw text, so treat the anchor names as the search index rather than scrolling the file.

The data sets section is the part with the most specific provenance

Alongside tools, the list includes public data sources, and these entries carry the kind of detail that makes a dataset useful: sample counts, consortium names and file locations.

The 1000 Genomes entry gives three access routes, a Gerstein lab archive page, an S3 bucket, and the EBI accession for 2500 Phase 3 samples at 30X. The FANTOM entry describes CAGE data from about 1000 human cell, tissue and cell line samples drawn from roughly 300 cell and tissue types. The Simons Genome Diversity Project, PGP UK, ICGC, the Genome Aggregation Program, the Haplotype Reference Consortium and a reference panel of about 250 Dutch families each get their own entry with a direct link.

Other entries state what makes a resource different. The Public RNA-Seq entry points to recount and to a Bioconductor package offering phenotype predictions, plus an ARCHS4 listing for human and mouse. The gnomAD entry specifies SNV, small InDels, MNV, SV and LoF metrics from large numbers of exomes and whole genomes, and is followed by a link to a blog post on lessons and tools for filtering gnomAD annotations. A separate line points to orthogonally validated TP and FP copy number variants.

One entry points at plain FTP rather than a web interface, the full text of all PMC papers from 2008 onwards, which shows the list is not limited to curated portals.

These are public reference resources, so a citation-aware tool will be the right way to consume them. The list gives you the coordinates; it does not wrap them.

Reading a tool entry: what you get and what is missing

The entries are terse by design. A typical line names a tool or project and gives the URL, sometimes with a short parenthetical. The clinical data section is a good example of the minimal form:

- BlueButton related tools https://github.com/amida-tech

And the data management section shows the same pattern:

- Data version control https://github.com/vsbuffalo/scidataflow

That brevity is the tradeoff of the whole project. You get breadth and a sensible grouping, and you get a one-line description at best. You do not get, for any entry, the language it is written in, the install method, whether it is command line or a web service, the licence, the input formats it accepts, whether it has a maintained release, or whether it scales to your data volume.

Several entries are also named at the level of a category rather than a tool. Cell line resources are grouped under a Cancer Cell Lines heading, and one entry covers deep sequencing of three cancer cell lines with a biorxiv link. A reader looking for a specific tool may find that the list gives them a topic to search in rather than the tool itself.

The categories where this matters most are the programming and visualization sections, where dozens of entries sit under a language heading. Treat the tree as a filter, not as an index of specific implementations.

One more limit is worth stating plainly. The list was assembled from literature, and literature favors tools that were used in a published study. Niche methods, tools used mainly in industry, and anything that never made it into a paper are structurally unlikely to appear.

A promising-methods category with no software attached

The last heading in the table of contents is Promising methods without software implementation. It is a small category, and an unusual one, because it collects ideas rather than tools.

Most curated lists are assembled around software that runs. This one keeps a section for methods that are described in a paper and have no implementation to point at. For a reader deciding what to watch, that section is arguably the most forward-looking part of the repository, and it is also the part most likely to be stale, since a method with no implementation today may have a working tool tomorrow.

The category also reframes the rest of the list. Some entries are in the list because the method is real and useful today, some because the underlying idea matters even if the current implementation does not. The line between those two categories is where a research group spends most of its evaluation time, and having a list that separates implementation from idea makes that distinction visible.

A reader using the list for project selection would do well to read this section first, because it points at the questions that the software sections have not caught up with yet.

Maintenance reality of a personal reading list

The repository is not archived. The last push was on 2026-05-04, and there are no GitHub releases, so there is no version to install and no release history to consult. The licence is MIT.

A list like this ages differently from code. The tools it points at move on, get rewritten or disappear, and the taxonomy drifts as the field changes. The curation files absorb some of that churn, but only when someone checks, and checking is manual work with no automation behind it.

That makes the last push date a fact worth stating rather than a complaint. It tells you how recently the author did a pass over the entries, and it tells you nothing about how often the links are revalidated afterwards.

There is no API, no schema and no machine-readable output either. The file is Markdown, so anything you build on top of it means parsing a nested list, and there is no stable identifier for an entry beyond its position and its URL.

The most reliable way to use this repository is as a periodic sweep rather than a one-time download. Work through a branch of the tree, check the two side files, open the candidate projects, and confirm each one is alive and still relevant before you commit time to it.

Editorial conclusion

Use biotools as a discovery index when you need to find a tool or a public dataset for a genomics task, and treat every entry as a lead to verify rather than a recommendation, since the author states he has not used most of them. Do not treat it as a curated benchmark or a validated comparison, and do not rely on it for anything security related. Before you adopt a tool from the list, check whether it has since moved to DEAD.md or UNMAINTAINED.md, and confirm the project is still active, because the last push to the repository was on 2026-05-04 and entries can go stale faster than the list does.

Frequently asked questions

Official sources

1. Issues
2. jdidion/biotools on GitHub
3. License: MIT
4. README