How this site collects and ranks its data

Where the data comes from

How tools get selected

A tool enters the directory only if it meets all of these criteria:

• Genuinely open-source — a public repository under a recognized open-source license. "Source available" or trial software doesn't qualify.
• Actively maintained — recent commits and a responsive project, not an abandoned repo.
• Actually usable — it must install and do what it claims. We record whether it runs locally, in which language it's written, and how easy it is to get started.

For each tool we publish the same structured facts: category, license, local execution, language, ease of use, what it's best for, and its strongest points. Suggestions are welcome through the submission page and are reviewed manually against the same criteria.

The commercial exception

A small number of closed, paid products are listed. The site shows open-source and commercial AI side by side, so a paid product is not disqualified for being paid — it has to clear two things:

• Its publisher is identifiable and reachable for the long term — its own domain, a contact address at that domain, and a named company. A disposable mailbox or free static hosting is an automatic no. This is the rule that does the work: it is what separates a product from a link-building campaign.
• It is a product, not a service. Consulting, done-for-you packages and agency retainers are not tools, whatever the AI content.

Two things never make it onto a commercial listing: figures we cannot measure ourselves — user counts, awards, customer logos — and silence about a real caveat. If a product's normal use can get its user in trouble, the page says so. We would rather lose a listing than sell one.

When open-source projects in our catalogue do the same job, we publish an alternatives page next to the listing. That is a service to the reader, not a toll on the publisher.

One submission per publisher, on one account. Several accounts submitting several products from the same hand are treated as one, and reviewed together.

How comparisons are built

Head-to-head pages (X vs Y) are only generated between tools of the same category, from a single structured feature matrix — both sides of a comparison are always evaluated on identical criteria, from identical data. Model comparison tables use the same live OpenRouter feed as the pricing pages, so a price you see in a comparison is the same price you see everywhere else on the site, at the same timestamp.

The Olud Pulse score

On each tool page you will find an Olud Pulse score out of 100 (and its 1-to-5 star equivalent). It measures one thing: real-world adoption momentum, from public, verifiable signals — never our opinion, never a paid placement.

Up to five signals feed the score, depending on what exists for each tool: GitHub stars (total), star velocity (stars gained over the last 7 days), Docker Hub pulls (cumulative), PyPI downloads (last 30 days) and npm downloads (last 30 days).

The method: for every signal, each tool is ranked against the other curated tools, and its position in that ranking becomes a percentile. Its Pulse is the average of those percentiles across the signals it actually has — a library that only lives on PyPI is not penalised for having no Docker image. Tools tied on a signal share the same rank. A signal measured at zero counts as last place, not as missing data. Scores are recalculated every morning from fresh data.

Honest limits: Pulse measures adoption, not quality — a well-marketed tool can outrank a brilliant niche one. Tools without any public footprint (no open repository, no public package) have no score at all rather than a made-up one; that is why a few pages show no Pulse block. Read the score together with the number of signals shown beside it: 183 of our 230 measured tools are only visible on GitHub, and a Pulse built on one signal does not mean the same thing as a Pulse built on four. Docker Hub covers 15 tools, PyPI 39, npm 13.

The AI health score

On each project page you will find a health score out of 100, with a label. Unlike Pulse, which measures adoption, this one measures a single question: is this project still being looked after? It is recomputed every day from public GitHub data. Here is the whole formula — no weighting is hidden.

Maintenance is measured relative to popularity on purpose: 300 open issues on an 80,000-star project is normal, on a 500-star project it is a project drowning.

Labels: 85+ Thriving · 70+ Healthy · 50+ Maintained · 30+ Slowing down · below, At risk.

Honest limits. GitHub's open-issue count includes pull requests, so a project receiving many outside contributions currently has its open PRs read as unresolved problems, which costs it Maintenance points unfairly. We know, and it is the one number in this score we are not satisfied with. Contributor counts also come from GitHub's own statistics, which cap at the top contributors on very large repositories.

Maintainers often ask what moves fastest: pushing code. Going from « last push two months ago » to « last push this week » is worth 11 points on its own, and it shows up within a day.

What we will never do

Some open-source projects also sell a hosted or enterprise edition. When that is the case we say so on the tool page, under Also sold as — a fact we verify on the project's own site, never a paid mention. It changes no ranking and no score, and it carries none of the « Sponsored » labelling reserved for placements that were actually bought.

We also don't editorialize numbers: stars, prices and dates are shown as the source APIs report them. When something is wrong — it happens, upstream data isn't perfect — tell us and we'll fix the source or the pipeline, not just the page.

Update frequency

• Model prices and lists — every hour.
• Project statistics (stars, activity, velocity, "new today") — every day, some counters hourly.
• Editorial content (tool sheets, guides, comparisons) — continuously, as tools evolve and new ones are added.