Discovery guidelines

1. About these guidelines

OSS Tanbou's discovery features highlight independently developed OSS that is not yet widely known. We look for useful ideas and thoughtful details that make people want to try a product or create something of their own. The problem being solved and the ideas behind the implementation matter more than popularity alone.

These criteria apply to selection for discovery features, not to every listing in the OSS catalog or every editorial pickup. Not all OSS listed on this site is expected to meet the conditions below.

2. Eligible OSS

Published under an individual account

The GitHub repository must be owned by an individual account (User). Repositories owned by company or organization accounts (Organization) are outside the scope of discovery features.

A product people can use directly

We look for apps, tools, games, CLIs, GUIs, browser extensions, generators, and similar products that people operate directly to accomplish a task. These are distinct from libraries and frameworks intended to be embedded in another program.

Released under an eligible license

To emphasize projects that readers can incorporate into their own creations, discovery features focus on permissive licenses. The eligible identifiers are:

MIT, Apache-2.0, BSD-3-Clause, BSD-2-Clause, ISC, Unlicense, CC0-1.0, MIT-0, 0BSD, Zlib, BSL-1.0, UPL-1.0, and BlueOak-1.0.0.

Copyleft licenses such as GPL, AGPL, LGPL, MPL, and EPL, and projects whose license cannot be verified, are outside this discovery scope. This is an editorial selection policy, not a judgment about the value or usability of those projects. Check each project's license text and its scope before using, modifying, or redistributing it.

3. Star counts and maintenance

Roughly 10 to 800 stars

This range helps us find projects that have attracted some interest beyond their author without already being widely known. A count of 10 to 800 is a guideline, not an automatic pass or fail.

• New projects below 10 stars: A recent release may be considered when direct verification establishes its quality, even before it gains stars.
• Projects above 800 stars: We may relax the upper limit when a project is discussed internationally but has no substantial Japanese-language coverage.

Updated within 12 months, or already complete

A commit within the past 12 months is the usual expectation. A project with fewer recent updates may still qualify when it is complete and reliably serves its intended, focused purpose.

We look for evidence such as completion statements in the README or CHANGELOG, stable versioning, issues that have been addressed or closed as intended behavior, and no gaps in core functionality. Projects that have been inactive for over a year and remain unfinished are excluded. Archived repositories are excluded regardless of completeness.

4. Outside the discovery scope

• Libraries, frameworks, SDKs, plugins, and developer dependency packages
• Repositories owned by company or organization accounts
• Forks of another repository
• Archived repositories
• Projects without an eligible or verifiable license
• Projects that have been inactive for over a year and remain unfinished

A finished browser extension that people use directly can qualify. We distinguish these user-facing products from the plugins and dependency packages excluded above.

5. What we look for during selection

For eligible candidates, we consider:

• A clear problem and audience: Who benefits, in what situation, and why the product was created.
• Specific, distinctive ideas: Thoughtful usability, feature choices, architecture, or implementation details.
• An inspiring independent project: Value that can be explained to people without specialist knowledge and can spark an interest in building.
• Verifiable information: Claims supported by primary sources such as the README, source code, commit history, and releases.

When finding candidates, we also consider stars and forks, updates and releases, the development team, whether it is a usable product, community discussion, and the README's explanations, images, and videos. These are signals to help prioritize investigation. Metrics and scores do not determine acceptance; the site operator makes the final selection.

6. What to include in a submission

Choose whether you discovered someone else's OSS or are submitting your own work, and enter the GitHub owner and repository name. Your description is most helpful when it explains:

1. Who the product is for and what they can do with it.
2. What you appreciated when using it, or what makes it distinctive.
3. Any reason to consider a star-count exception, or evidence that a project with few recent updates is complete, where applicable.

Separate verified facts from opinions and assumptions. Meeting the criteria or submitting a project does not guarantee publication.

7. Publication and use

Our introductions distinguish information checked against official documentation from hands-on verification. Selection or publication does not guarantee safety or operation in every environment. Before installation, check the official instructions and the project's current status.

See the Terms of Service for site usage and the Privacy Policy for information about account data and other personal information.