OSSDrop: a generated list where the README is a build artifact

README.md is generated, and editing it changes nothing

The first two lines of README.md are an instruction aimed at contributors rather than readers, and they invert the usual workflow. The file is marked as generated, with a note not to edit it directly, and the actual source is `data/tools.json`; the change is made there and `scripts/build_readme.py` is run, which CI does nightly. That single fact explains most of what the repository looks like. The category table, the star figures, the trending section and the badge artwork are all outputs, so a pull request that hand-edits the table will be overwritten on the next run. It also means the repository is a data pipeline that happens to publish as Markdown: the interesting files are the JSON, the script and the templates, and the README is the build log you happen to be reading.

Submission is one pull request, and placement is not sold

The contribution model is deliberately thin. A maker drops their own project with a single pull request, and CONTRIBUTING.md at the root is where that process is written down, linked from the README both as a badge and as a drop your tool call to action. Three conditions are stated for what lands on the list: a public repository, an OSI licence, and an honest one-line description. Those three are the entire editorial policy, and they are checkable from the repository itself rather than a judgement call, which is why a curation project with no staff can still claim to be curated. The other half of the pitch is the negative claim: no placement on the list is paid. Star counts, icons and the trending ranking update automatically, so the ordering is a function of the upstream numbers rather than of a commercial relationship.

Trending this week and most starred are two different recomputations

The README carries two ranking blocks above the categories, and they answer different questions. Trending this week is defined as the biggest star gains among listed tools over the last 7 days, and the subheading insists the measurement is not editorialized, which is the useful part: a tool can appear there having gained stars this week without being large. Most starred is the heavy hitters, recomputed nightly on raw totals, and it changes slowly between runs because cumulative star counts move slowly for established projects. Both are recomputed, so the gap between the two blocks is itself a signal: a project in the trending row and absent from the starred row is new and moving, and the daily SVG card assets under `assets/cards/` exist so those rows can carry a dark-mode aware badge per project rather than plain text.

Fourteen categories, and the AI bucket is not incidental

The catalogue is split into fourteen categories, navigable from a single subheading row at the top of the file: AI and Coding Agents, Developer Tools and CLI, Web and APIs, Data and Databases, DevOps and Self-Hosted, Files and Sync, Security and Privacy, Productivity, Notes and Knowledge, Communication and Social, Automation and IoT, Finance and Business, Science and Education, and Creator and Media. The first category is also the densest in the rendered output, and its contents show what the project considers the current centre of gravity: Ollama for running models locally, Hugging Face Transformers as the pretrained model library, LangChain and vLLM for application and serving layers, llama.cpp for local CPU and GPU inference, and a run of coding agents including Codex CLI, Cline, OpenHands and Open Interpreter. Storage and memory tools sit in the same bucket, Mem0 among them, described as a memory layer giving agents persistent recall across sessions.

The site and the subreddit split the audience

The repository is one of three surfaces, and they have different jobs. `ossdrop.com` is the homepage and hosts the same tools ranked, which is where you go to browse rather than to read a diff. A Reddit community at r/OSSDrop is where the discussion happens, and the README treats browsing, discussing and submitting as three separate actions rather than one flow. The consequence for a reader is that the ranked views on the site can move independently of the file in the repository, since the site is not the generated README even when it carries the same entries. For a maker, that means a listing is a three-part commitment: a pull request for the data, a presence on the site, and a place to answer questions. The repository itself stays small, with `data/`, `scripts/` and `assets/` doing the work and no application code at the top level.

llms.txt is the file to point a model at, not the README

There is a file called `llms.txt` at the repository root, and for a project whose entire output is a list of tools and links that is a deliberate choice rather than an oddity. The README is a rendered artefact with HTML blocks, badge markup and image sources, none of which is useful to a language model parsing text. A plain text index of the same catalogue is, and putting it beside the data means a model can be pointed at a stable path instead of at Markdown that a nightly job rewrites underneath it. The same reasoning explains why the tables are kept in the README at all rather than only on the site: the Markdown is what a human browsing GitHub reads, and `llms.txt` is what a machine reads. Neither is the source of truth, and `data/tools.json` is.

Licence metadata is unasserted even though a LICENSE file exists

Two details are worth checking before you build anything on this. First, the repository's licence field is not asserted by GitHub, so the LICENSE file at the root is the only licence text available and it should be read directly rather than inferred from the badge in the README. Second, the catalogue's own terms and the listed projects' terms are different questions: an entry's OSI licence is the requirement for inclusion, while the directory's own licence governs the README, the JSON and the card assets. The project also states a review policy on pull requests, accepting contributions that keep the scope of the directory rather than adding features, which is the same boundary style used by binding libraries: the curation stays narrow so the automated nightly run stays predictable. There are no GitHub releases, so the history of what changed when lives in commits, and the last push was on 2026-09-30.

Editorial conclusion

OSSDrop is worth a look if you want a directory that is not pay to play, or if you want a worked example of a repository whose README is a compiled artifact rather than prose: the data lives in `data/tools.json`, the generator is `scripts/build_readme.py`, and the schedule is nightly. What you should not do is treat the rendered table as a review, since the entries are self-submitted through a pull request and the star figures in the file are whatever the last run read. Before adding your own project, read CONTRIBUTING.md for the one-PR process, and check what LICENSE actually permits, because the repository's licence metadata is not asserted even though a LICENSE file sits at the root. The list also publishes `llms.txt` at the root, which is the file to point a language model at rather than scraping the README. The last push was on 2026-09-30 and there are no GitHub releases.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository