Share your tool. Keep your project.
Create a listing in your own repository, then request OIC review.
Describe the actual tool
Give it a short description, category, platforms, and a working link to get started. Name the creator or maintainer. List only public information you have permission to share.
Describe a genuinely useful free tool or edition, rather than a time-limited trial. State what is free, who can use it, any limits, and what it needs: hardware, a host platform, an account, hosting, integration, or support. Separate optional paid extras from the free scope; reviewers need the actual terms.
Make the terms clear
Choose open source, source available, or closed source. Link to the license or free-use terms. A public repository alone doesn’t mean a project is open source.
Closed-source tools don’t need a public code repository. They do need a legitimate way to access the free software and read its terms.
Add the files and resources people need: a repository, release package, container image or document. Link each item to the location you manage, and name separate terms or platform requirements when they differ.
Preview, then propose
Use the form or open an existing YAML file to preview the listing. Save it as .oic/project.yaml with your logo, screenshots and optional overview file. Commit them to your repository, then request a listing. A public listing-only repository works for private software.
Request a listing using your public profile repository.
A person reviews it
Inclusion depends on a useful ongoing free edition, accurate attribution, working project and terms links, clear requirements, and an honest description. A maintainer checks these before publication; updates follow the same process. Curated links and community submissions are labeled separately.
Spam, impersonation, misleading free-use claims, and known malicious content do not belong in the catalog. These checks also apply to projects from OIC’s founders.
YAML validation checks the file’s structure. Listing review checks its claims against sources. Neither proves that software is safe or suitable for production.
What keeps the catalog usefulRead the public Listing Charter for the full admission standard and review limits.
What about evaluations?
A self-test records what a project’s own team tested. An independent review adds a separate reviewer and a defined scope. Neither is interchangeable with a catalog listing.
The current catalog does not award grades or publish independent verification. When a scoped report is available, it should name the release, tests, reviewer, and limits.
Keep the information useful
Found an unclear term, broken link, or missing requirement? Open “Suggest a correction” on the project page and download a note with the detail and its source.
Correction notes stay on your device until you attach them to an issue in the public catalog. For profile updates, edit your repository: OIC checks registered sources daily and prepares changes for review.