Skip to content
For founders5 min read

The open source launch checklist

Before you share your open source project, make sure these files, docs, and settings are in place so first time visitors become users and contributors.

By TeaserTrack Team

Published

Handwritten to do list in a graph paper notebook with a pen, an open source launch checklist
On this page

    When an open source project gets attention, most visitors decide within a minute whether to star it, try it, or close the tab. That decision is made almost entirely from your repository page. This checklist covers what to have in place before you share the link anywhere.

    The README

    Your README is your landing page. Structure it so the answers come in the order people ask the questions:

    1. What is it? One sentence under the project name.
    2. Why should I care? Two or three sentences on the problem it solves.
    3. Show me. A screenshot, GIF, or short video of it working.
    4. How do I try it? The shortest possible install and first run commands.
    5. Where do I learn more? Links to docs, examples, and community.

    Put the install command near the top. Many visitors will copy it before reading anything else.

    Man reading papers and taking notes beside a laptop in an office
    Write the README for someone who will copy the install command first.

    Essential files

    Make sure these exist in the repository root:

    • LICENSE with a recognised open source license
    • CONTRIBUTING.md explaining how to set up the project locally and submit changes
    • CODE_OF_CONDUCT.md so contributors know what behavior to expect
    • SECURITY.md with a private way to report vulnerabilities

    GitHub surfaces several of these on your repository page, which signals that the project is maintained with care.

    Issues and discussions

    Before launch, prepare for the questions that will arrive:

    • Add issue templates for bug reports and feature requests
    • Label a handful of real issues as good first issue, with enough context for someone new to pick them up
    • Enable Discussions if you want questions separated from bug reports
    Three colleagues talking over a laptop in a meeting
    Decide where questions go before the first ones arrive.

    Releases and versioning

    Tag a proper release, even if it is v0.1.0. Write release notes that explain what works today and what is known to be missing. A clear version number tells people how stable the project is without guessing.

    Automated checks

    Set up continuous integration that runs your tests and linters on every pull request. It protects your main branch and shows contributors their changes are safe before you review them.

    Repository settings

    A few settings that are easy to forget:

    • A short description and website link in the About section
    • Topics that match how people search, such as nextjs, postgres, or ai-agents
    • A social preview image, so links shared on social media show your project instead of a generic card
    • Branch protection on your default branch
    Colourful code on a dark monitor, ready for an open source launch
    Branch protection and checks on every pull request keep the default branch healthy.

    Launch it

    With the repository ready, share it where your users are, and list it on TeaserTrack with your GitHub link, a teaser, and your release date. Listings for open source projects link straight to the repository, so stars and contributors can follow.