# definitive-opensource: a curated index of consumer open source apps

> definitive-opensource is a Python-generated catalogue of 806 consumer-facing open source applications, split by platform and tagged for risk. It is a discovery index, not a package manager, and its last push was on 2026-01-24.

**mustbeperfect/definitive-opensource** — The definitive list of the best of (consumer facing) open source.

- Repository: https://github.com/mustbeperfect/definitive-opensource
- Website: https://dos.mustbeperfect.com
- Stars: 3,418 · Forks: 135
- Language: Python
- License: MIT
- Published: 2026-08-04 · Updated: 2026-08-18 · Language: en
- Canonical page: https://hysenlabs.com/projects/mustbeperfect-definitive-opensource

## The problem definitive-opensource was built to solve

GitHub has no shortage of awesome lists, and the README says so directly. The stated complaint is that existing lists carry long-deprecated applications, sit cluttered with small projects on the verge of extinction, or simply miss modern open source software. definitive-opensource positions itself against all three failure modes at once: a single catalogue of consumer-facing apps chosen for what the README calls a solid user base, a solid set of contributors, visible long term growth, and overall product quality.

The audience is narrower than the name suggests. The README states the list is exclusively for apps a person uses directly, meaning desktop applications, self-hosted applications and command line utilities. Developer-facing tools such as languages, frameworks and libraries are excluded. If you are choosing a web framework or an HTTP client, this repository will not help you, and that boundary is deliberate rather than an oversight.

The curation claim is worth reading closely. The README argues the list is curated not by opinion but by statistics and facts, and that neutrality means presenting options without persuading. That is a coherent editorial stance, but it also means the list tells you what exists and roughly how healthy it looks, not which of two similar tools you should pick for your own workflow. The judgement call stays with you.

## How the Python pipeline turns JSON into per-platform lists

The architecture is documented in the repository's own explanation of how the list works. The project began as a single markdown file edited by hand. As it scaled, that approach became unworkable, and the README notes that requests for platform-specific READMEs would not have been realistic to produce manually. As of v0.6.2-beta the project was rebuilt around data files.

Categories live in categories.json and applications live in applications.json. Python scripts read those files and generate one main list plus platform-specific lists. GitHub Actions run the scripts whenever changes land, so the markdown is an output rather than a source of truth. The README describes the benefit as easier refactoring of the list format and the elimination of typos, both of which follow from having exactly one place to edit a project entry.

The division of labour is explicit. Scripts handle markdown formatting, statistics updates and detection of potentially abandoned projects. Humans decide which projects enter the list, which get removed, and what tags they carry. The README calls this a middle ground between human input and automation, and contrasts it with fully automated websites where statistics alone fail to capture the complete picture. That is a fair description of the trade-off: automation gives consistency, and human review gives context that a commit-date heuristic cannot.

The top-level layout matches the description: apps/, core/, resources/ and assets/ sit alongside the README and LICENSE. Platform-specific output goes under resources/readmes/, with windows.md, macos.md, linux.md and selfhost.md linked from the README header.

## Reading the tag system before you trust an entry

The tag vocabulary is the most useful part of the project and the part most likely to be skimmed past. Alerts use coloured circles for security incidents graded minor, moderate, major and critical. Separate markers flag potentially abandoned projects, closed development models, paused development, slowed development, restrictive licences, corporate influence, commercial products, experimental pre-alpha software, critically unstable or buggy software, projects on watch for removal, and excessive AI usage.

Platform tags are equally specific. Cross, Windows, MacOS, Linux, Android, IOS, SelfHost, Web (Cloud), VSCode, JetBrains, Chromium, Firefox and N/A describe where something runs. The README adds a rule that matters when you are planning an install: Cross, MacOS, Linux and Windows tags imply the app ships as a binary such as an exe or dmg, unless a manual tag is also present, in which case expect another runtime or installation method. SelfHost implies Docker installability by default.

Property tags cover CLI, TUI, CLI+, Plugin, Extension, Web UI and Manual. Manual means installation through pip, npm, cargo or a source build. The Web UI tag applies to desktop apps that expose a web interface, and the README notes that self-hosted apps imply a web UI already.

The practical reading is that a tag column can disqualify an entry before you open its repository. A restrictive licence marker or a security incident marker is information you would otherwise have to dig out of release notes. The caveat is that these are maintainer-applied labels with no published verification procedure in the README, so treat them as a prompt to check the upstream project rather than a verdict.

## Installing it and getting a first usable list

There is no package to install here. The project is a data repository plus Python scripts, and the README points readers at the web client at dos.mustbeperfect.com because the README itself has become difficult to navigate at 806 projects. For most readers the web client is the fastest path, and cloning is only necessary if you want to run the generation scripts yourself.

To get the source, clone the default branch:

```bash
git clone https://github.com/mustbeperfect/definitive-opensource.git
cd definitive-opensource
```

After cloning you have apps/, core/, resources/ and assets/ at the top level, plus the README and the MIT LICENSE. The generated platform lists are the files you actually want to read, and the README links them directly:

```bash
ls resources/readmes/
```

That directory contains windows.md, macos.md, linux.md and selfhost.md according to the README header. Opening the file for your platform gives you the same entries as the main list, filtered to what runs there.

If you intend to edit the list rather than read it, the data lives in two JSON files. The README names them explicitly:

```bash
ls apps/
```

Edits belong in categories.json and applications.json, not in the generated markdown, because GitHub Actions regenerate the markdown from those files when changes are pushed. The README does not document a local command for running the generation scripts, so the exact invocation is something you would have to read out of the scripts in core/ rather than from the documentation.

## Where this list stops being the right tool

The exclusion of developer-facing software is the first hard boundary. If your question is which library to depend on, or which framework to build a service with, the README rules that category out before any curation happens. That is not a gap to work around; it is the scope.

The second limitation is freshness. The last push was on 2026-01-24, and the most recent release is v0.8.5-beta from the same date. A curated index is only as current as its last regeneration, so a project that changed licence, stalled, or shipped a security fix after that date will not be reflected in the tag column. The README says the maintainers continuously monitor projects and remove anything that no longer fits, but that monitoring runs on the same update cycle as everything else.

The third is that curation is not verification. The README describes strict minimum requirements and additional research for vetting, and states that a project passing is likely popular enough to survive far into the future. Popularity is a proxy for survival, not a guarantee, and the project says as much by adding a potentially abandoned tag rather than removing borderline entries outright. An entry appearing in the list tells you the maintainers judged it worth including at the time of the last update. It does not tell you the software is secure, well maintained today, or suitable for your environment.

Finally, the README concedes the name oversells the scope: the project states that definitive does not carry the dictionary sense of finality here, and that the list survives through community contribution.

## definitive-opensource against automated discovery sites

The clearest alternative is the class of automated open source discovery sites, which the README describes as mostly automated websites for finding open source projects that rely on statistics alone. The difference is where judgement sits. An automated site ranks by measurable signals and returns whatever scores highest. definitive-opensource uses scripts for formatting, statistics updates and abandonment detection, but the admission decision, the removal decision and the tag assignment are made by people.

That buys context at the cost of throughput. A fully automated index can refresh continuously and cover every repository on a host. A human-reviewed list updates when someone reviews it, which is why the README frames the platform-specific outputs as a generation problem and the selection itself as an editorial one. If you want exhaustive coverage, the automated approach wins. If you want a shortlist where someone has already filtered out deprecated and near-extinct projects, this repository is aimed at exactly that.

The second comparison is to the individual upstream repositories themselves. Reading a project's own README gives you its maintainer's view, which is authoritative on features and silent on how the project compares with alternatives. definitive-opensource gives you the comparison, grouped by category and annotated with risk markers, but nothing about the internals of any single application. The two sources answer different questions, and using the list as a starting point rather than an ending point is the intended pattern.

## Licence, maintenance and what an upgrade costs

The repository is MIT licensed, and the LICENSE file sits at the top level. For a data repository this is permissive in the ordinary sense: you can reuse the list content, but MIT covers the repository's own code and data, not the licences of the 806 applications it describes. Those are separate, and the README's restrictive licence tag exists precisely because some listed projects are not permissively licensed. Checking the tag column is not a substitute for reading the upstream licence if you plan to redistribute a listed application.

Upgrade cost for a consumer of the list is close to zero. There is nothing to install and nothing to keep in sync, so staying current means revisiting the platform file or the web client. The cost appears if you fork the data. Because categories.json and applications.json are the source of truth and the markdown is generated, a fork that edits markdown directly will conflict with the generation pipeline on the next sync. A fork that edits the JSON files stays compatible, but it also inherits the work of re-applying your changes whenever upstream restructures its categories.

The maintenance signal to watch is the release cadence. v0.6.3-beta landed on 2025-05-31, v0.7.4-beta on 2025-11-12, and v0.8.5-beta on 2026-01-24. The gaps are months, not weeks, and every release so far carries a beta suffix, which is consistent with the README's own framing of the project as continuously evolving through community contribution.

## Conclusion

Adopt definitive-opensource as a shortlist source when you need consumer-facing desktop, self-hosted or CLI software and want the vetting already done; skip it if you are looking for libraries, frameworks or language tooling, which the README excludes by design. Before relying on any entry, open the linked platform file for that project, check the tag column for security or abandonment markers, and confirm the upstream repository is still receiving commits, because the list's own status field reflects the maintainer's assessment rather than an automated check.

## FAQ

### What does definitive-opensource mean by open source?

The README applies the term to consumer-facing applications you use directly, including desktop apps, self-hosted apps and command line utilities. Developer-facing tools such as languages, frameworks and libraries are explicitly excluded, so the list's definition is scoped to end-user software rather than to a licence test.

### Does definitive-opensource only list free software?

No. The tag system includes a commercial marker and a restrictive licence marker, which means entries can be commercial products or carry licences that are not permissive. The list also flags corporate influence separately, so paid or corporate-backed projects are labelled rather than filtered out.

### Where do I download definitive-opensource?

There is no package to download. The README recommends the web client at dos.mustbeperfect.com for browsing, and the repository itself can be cloned from GitHub. Generated platform lists live under resources/readmes/ as windows.md, macos.md, linux.md and selfhost.md.

### How do I add a project to the definitive-opensource list?

Entries come from categories.json and applications.json rather than from the generated markdown, and Python scripts plus GitHub Actions rebuild the lists when those files change. The README does not document the submission criteria as a checklist, so the selection decision remains with the maintainers.

### Why is the definitive-opensource README so hard to read?

The README states that the list's increasing size has made navigation difficult at 806 projects, and recommends the web client for a better experience. The platform-specific markdown files exist partly for the same reason, since producing them by hand was described as unrealistic.

## Sources

- [Official documentation](https://dos.mustbeperfect.com)
- [Official README](https://github.com/mustbeperfect/definitive-opensource#readme)
- [Project repository](https://github.com/mustbeperfect/definitive-opensource)
- [Release notes](https://github.com/mustbeperfect/definitive-opensource/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/mustbeperfect-definitive-opensource