definitive-opensource: A curated, scripted index of consumer-facing open source apps

What the list actually covers

The repository defines itself as a list of the best consumer-facing open source projects. That means desktop apps, selfhosted applications, and command line utilities. Developer-facing tools like languages, frameworks, and libraries are explicitly excluded. The README states the list contains 806 projects as of version 0.8.5-beta. The primary audience is someone looking for a ready-made shortlist of open source apps they can install and use directly, without having to sift through the thousands of projects on GitHub. The list is organized by platform, with separate README files for Windows, macOS, Linux, and SelfHosted, plus a web client at dos.mustbeperfect.com for easier navigation. The project's stated goal is to avoid the pitfalls of other awesome lists, which the author says include long-deprecated apps and small projects on the verge of extinction. The emphasis is on projects with a solid user base, a solid set of contributors, visible long-term growth, and overall product quality.

The curation mechanism: statistics plus human judgment

The project does not rely on automated scraping alone. According to the README, the list was originally a single markdown file edited manually. As it scaled, that became impractical, so from version 0.6.2-beta the project was rebuilt around two JSON files: categories.json and applications.json. Python scripts generate the main list and the platform-specific READMEs. These scripts also automate markdown formatting, update statistics, and flag potentially abandoned projects. However, the actual decisions about which projects make the list, which get removed, and what tags are assigned are made by humans. This is a deliberate middle ground between fully automated directories and purely manual lists. The README claims the list is 'curated' based on statistics and facts, not opinion. That is a strong claim, but the tag system shows that human interpretation still plays a role. For example, tags like 'corporate influence' and 'excessive AI usage' are not purely factual; they require a judgment call about what counts as excessive or influential.

How to run it: JSON, Python, and GitHub Actions

The repository is primarily a data set plus a generation pipeline. To reproduce the list locally, you would clone the repository and run the Python scripts that read categories.json and applications.json. The README does not give explicit commands, but it states that GitHub Actions run the scripts whenever changes are made. That means the workflow is: edit the JSON files, commit, and let the automation regenerate the markdown. If you want to contribute, you would add an entry to applications.json with the appropriate fields, such as name, category, tags, and probably a URL or repository link. The README lists many tags, including platform tags like Cross, Windows, SelfHost, and property tags like CLI, TUI, and Manual. There is no detailed schema in the provided material, so the exact structure of the JSON entries is not confirmed. The web client is the recommended way to browse the list, as the README itself says the main README has become difficult to navigate due to its size.

The tag system: a rich but subjective vocabulary

The list uses a large set of emoji-based tags to convey status and properties. Status tags include 'Active Development', 'Incremental', 'Maintenance', 'Idle', and 'Abandoned'. Alert tags include security incidents (minor, moderate, major, critical), potentially abandoned, closed development model, development paused, development slowed, restrictive license, corporate influence, commercial, experimental, critically unstable, on watch for removal, and excessive AI usage. There are also highlight tags like disruptive, influential, pioneering, and innovative. Some tags are factual: platform tags like Windows or SelfHost are straightforward. Others, like 'corporate influence' or 'excessive AI usage', are qualitative and could be contested. The README says the list aims to be neutral and present options, not persuade or redact. Yet a tag like 'restrictive license' is a warning, and 'corporate influence' carries a negative connotation. This is a tension in the project's design: it claims neutrality but uses a vocabulary that implies judgment. As a reader, you should not take these tags as objective facts. They are the maintainers' assessments.

Limitations and failure modes

The most obvious limitation is the project's own admission that 'definitive' does not mean final. The list is not exhaustive, and the vetting criteria are not publicly defined in detail. The README mentions 'strict minimum requirements' and 'additional research', but it does not specify what those requirements are. That means the selection process is opaque. A project can be removed at any time if it no longer fits the criteria, but the criteria are not fully documented. Another limitation is the dependency on human curation. The README says the list is 'curated' not by opinion but by statistics and facts, but the tag system shows that human judgment is unavoidable. For example, deciding whether a project is 'innovative' or 'disruptive' is subjective. Also, the list only includes consumer-facing apps. If you are looking for developer tools, this is the wrong place. The README explicitly excludes languages, frameworks, and libraries. Finally, the size of the list (806 projects) makes it unwieldy in the main README, which is why the web client exists. That is a practical constraint, not a flaw, but it means the primary interface is not the repository itself.

Alternatives: static awesome lists and automated directories

The most direct alternative is the traditional 'awesome list' format, such as the many curated lists on GitHub that focus on specific topics or platforms. Those lists are typically single markdown files maintained by one or a few people, with no automated generation. The difference is that awesome lists often include developer tools and libraries, and they rarely have a formal vetting process. Another alternative is automated directories that scrape GitHub repositories and rank them by stars or activity. These sites rely purely on statistics, which the definitive-opensource README argues is insufficient because statistics alone fail to capture the complete picture. The trade-off is clear: automated directories are more comprehensive and up-to-date, but they include many low-quality or abandoned projects. definitive-opensource tries to filter those out, but at the cost of human bias and a slower update cycle. If you want a purely objective, data-driven list, an automated directory is a better fit. If you want a human-filtered selection, this project is one option, but its criteria are not fully transparent.

Maintenance, licensing, and upgrade cost

The project is under active development, with the latest release v0.8.5-beta pushed on 2026-01-24. The release history shows a steady cadence: v0.6.3-beta in May 2025, v0.7.4-beta in November 2025, and v0.8.5-beta in January 2026. The repository is not archived, and the status is marked as 'Active'. The license is MIT, which means you can freely use, modify, and distribute the list and its scripts, with attribution. There is no separate license for the data itself, but the MIT license covers the repository content as a whole. The maintenance cost for a user is low: you do not need to run anything to use the list; you just browse the README or the web client. If you want to contribute, you need to understand the JSON structure and the tag conventions, which are described in the README but not fully detailed. The upgrade cost is also low for consumers, as the list is regenerated automatically. For someone who wants to fork the project and maintain their own list, the Python scripts and GitHub Actions provide a template, but you would need to adapt the schemas to your needs. The main ongoing cost is for the maintainers: they must continuously monitor projects, update tags, and remove entries that no longer meet the criteria, as stated in the README.

Editorial conclusion

Adopt definitive-opensource if you are a user or hobbyist looking for a broad, human-curated index of consumer-facing open source apps, especially for selfhosted or cross-platform tools. Do not treat it as a final authority: the list is explicitly not final, and the human curation process means personal taste and oversight gaps exist. Before relying on any entry, verify its maintenance status, license, and recent activity directly on the project's repository. Also check the tag definitions, since tags like 'corporate influence' or 'excessive AI usage' are subjective and may affect your adoption decision. If you need a purely statistical or automatically updated index, look elsewhere; this project is a hybrid that prioritizes human judgment over raw numbers.

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes