Methodology & editorial standards
How the tally is kept.
DAIODA's only real asset is trust: that when a project is called open source here, it actually is. This page documents exactly how that determination is made, how projects are chosen, how activity is judged, and how you can push back when we get something wrong.
What counts as open source
DAIODA uses the Open Source Definition as its standard: an open-source license grants the freedom to use, study, modify, and redistribute the software, with no restriction on field of use, persons, or commercial activity. In practice, that means OSI-approved licenses — MIT, Apache-2.0, the BSD family, the GPL/LGPL/AGPL family, MPL, and their peers.
Concretely, a project earns each verdict as follows:
The code ships under an OSI-approved license, confirmed by reading the license in the repository. For tools, this is the whole story. For models, the weights must also be under an open license.
The software is open source, but the model weights ship under a custom, non-commercial, or otherwise restricted license. Featured — because the code genuinely is open — with the weights terms shown plainly.
The license restricts use in ways the Open Source Definition forbids — fair-code, "source available," field-of-use conditions, branding locks, or all-rights-reserved. Collected in The Fine Print, never in the main catalog.
A free tier, a public demo, a downloadable model, a published paper, or an open API doesnot make a project open source. Only the license does.
How projects are selected
Candidates come from primary sources — GitHub and GitLab, official project sites and docs, research papers, maintainer announcements, and foundation repositories — plus community signal and the occasional tip. The initial launch catalog drew on a seed list and then expanded well beyond it through independent research.
A project has to clear a few bars to be featured:
- Genuinely open, per the definition above (or clearly labeled as partial or fine-print if not).
- Useful, notable, or unusual — it earns its place either by being genuinely good or by being genuinely interesting.
- Real, not vaporware — an existing repository with actual code or weights, not just an announcement.
- Not a near-duplicate — when several projects do the same thing, we feature the strongest and cite the rest as alternatives rather than listing all of them.
Curation is deliberately opinionated. This is a digest, not a database dump; leaving good projects out is a feature, and every entry carries an editorial takeaway rather than a neutral restatement of its README.
How licenses are verified
The license verdict is the single most important field on this site, so it gets the most rigor:
- Read the license from the source. The determination comes from the actual LICENSE file in the repository, not from GitHub's auto-detected label, a third-party listing, or a blog post — those are frequently wrong.
- Separate code from weights. For models, the code license and the weights license are recorded independently, because they routinely differ (MIT code, non-commercial weights is common).
- Check for added conditions. "Apache-2.0 with additional conditions," "Sustainable Use," "Community License," and branding clauses are flagged — these are the disguises that turn an open-looking repo into something that isn't.
- Note commercial restrictions and dependencies. Where commercial use is limited, or a key dependency carries a stricter license, it's called out in the entry.
- When in doubt, downgrade. Unclear licensing is treated as not-verified rather than given the benefit of the doubt.
License reading here is careful, but it is not legal advice. For anything commercial, confirm against the project's current license yourself — licenses change, sometimes without a version bump.
How activity is evaluated
Every entry carries a Tally: stars, last meaningful activity, project status, and the date the tally was checked. Status is assigned by judgment, not a formula:
- Maintained — active commits and releases within a recent window.
- Stable — mature and cared for, but intentionally slow-moving (a finished small model, a release repo).
- Experimental / Early — promising but young, pre-1.0, or still proving itself.
- Static — essentially complete or dormant, kept for reference.
Star counts and dates are point-in-time snapshots and drift constantly — treat them as rough indicators, not live figures. Abandoned or archived projects are re-tallied and their status updated (or they're moved out of the featured catalog) rather than left to quietly rot.
Publishing cadence
New projects come ashore weekly, in the Daybreakedition. The workflow behind each edition is: discover candidates from primary sources, verify open-source status by reading licenses, filter duplicates and low-quality entries, write original editorial context, and review before publishing. Automated tooling helps with discovery and with re-checking activity; the license verdict and the editorial judgment stay under human-style review, never auto-published as unverified claims. The full pipeline is documented in the build guide.
Corrections & maintainer requests
The tally only stays honest if it's easy to challenge. Two paths:
Spotted an error?
A broken link, a stale status, a star count that's wildly off, or — most importantly — a license verdict you think is wrong. Open an issue on the project repository (linked from the footer once the source is public) with the project name and what needs fixing. License corrections jump the queue.
Maintain a featured project?
If you maintain a project listed here and something is out of date — a relicense, a new release, a status change, or a description you'd word differently — say so and it'll be updated. If your project is in The Fine Print and you've since adopted an OSI license, tell us; nothing would make the tally happier than moving you into the main catalog.
Corrections are applied transparently, and material changes to a verdict are noted in the project's tally so the record stays legible.