How to contribute

Where the catalog lives

Every tool is an entry in src/data/tools.ts. The English translation of that same entry (description, features, pros/cons) goes in src/data/tools.en.ts, keyed by the same id. There is no other place data is stored — what you see on the site is literally that file's content as of the last build.

Adding a new tool

1. Fork the repo and open src/data/tools.ts.
2. Copy an existing entry from a similar category as a template and add yours to the array.
3. Add the English translation (same id) in tools.en.ts.
4. Run npm run dev and check the tool's page renders correctly, then npm run build to confirm nothing is broken.
5. Open a Pull Request. If you would rather not touch code, open an Issue instead (see below) and we will add it.

Fields on a listing

The OpenSourceTool type (in src/lib/types.ts) requires these fields for the build to compile:

• id / slug — the same lowercase, hyphenated string (e.g. "n8n"). Must be unique across the whole catalog.
• name, description, shortDescription.
• replaces — array of the SaaS product(s) it replaces, e.g. ["Notion", "Slite"].
• category — one of the existing categories in ToolCategory (src/lib/types.ts). If none fits, say so in the PR/Issue and we will discuss it.
• websiteUrl / githubUrl.
• license — the real license exactly as it appears in the repo's LICENSE file (e.g. "MIT", "AGPL-3.0", "Sustainable Use License (Fair-code)"), not a generic "open source".
• dockerCompose — the project's real docker-compose.yml, with images on a fixed version whenever the project publishes one (avoid :latest if a stable tag exists). If it genuinely does not deploy via docker-compose (its own installer script like curl | bash), put that script there instead with a comment explaining what it does.
• features, techStack, pros, cons, tags.

These other fields are optional for the build to compile, but we expect them on any new tool now that we enforce them systematically:

• fossModel — "FOSS" (OSI license, no paid feature), "OpenCore" (OSI core + paid features), "FairCode" (no usage limits but a non-OSI license banning resale) or "SourceAvailable" (public code, non-OSI license). Do not set it if you are not sure — we will review it before publishing.
• minRamMb / difficulty — if you omit these, they are inferred automatically by counting your dockerCompose's services. Only set them by hand if you know the project's real RAM requirement and want it more precise than the estimate.
• dockerStatus — "VERIFIED_PINNED" if you have checked the image actually exists under that exact tag on its real registry. Do not set it if you have not verified it yourself.

What we accept

• Self-hosted software that genuinely works — not a product announcement or an idea-stage project.
• A public, reachable source repository (GitHub, GitLab, Codeberg...).
• An identifiable, verifiable license in that repository — not just "it's open source".
• Recognizable recent activity (commits, releases, or answered issues in the last few months). We do not have an exact day threshold — if the project has had no movement at all for a long time, say so in the PR and we will judge it case by case; we do not auto-reject on a specific date.

Reporting outdated data

If you spot a license that changed, a Docker image still on :latest that should now be pinned, a dead link, or any other stale data, open an Issue with the template below — you do not need to know how to fix it, just point it out with a link to the real source (the repo's LICENSE file, the registry's tags page, etc.).

Direct links