DEV Community

Batty
Batty

Posted on

How to Get Your Open Source Project into Awesome Lists (and Why It's Worth the Effort)

#opensource #github #seo #beginners

You shipped your open source project. You wrote the README. You posted on Reddit. Now what?

One of the most underrated distribution channels for open source is awesome lists — those curated awesome-* repositories on GitHub. There are thousands of them, many with tens of thousands of stars. Getting your project listed means a permanent, dofollow backlink from a high-authority GitHub page.

I recently submitted our Rust CLI tool to seven awesome lists. Here's what I learned about the process — and what I wish someone had told me before I started.

Why Awesome Lists Matter

The obvious benefit is visibility. Someone browsing awesome-rust (40k+ stars) looking for developer tools might discover your project.

But the bigger win is SEO. Each awesome list that merges your PR gives you a dofollow backlink from a page with high domain authority. GitHub pages rank well in search engines. A single listing on a popular awesome list can outperform weeks of blog posts for driving organic search traffic to your repo.

For a project with under 100 stars, getting listed on 3-4 relevant awesome lists can be the difference between showing up on page 1 or page 5 of Google results for your target keywords.

Step 1: Find the Right Lists

Don't just search GitHub for "awesome" + your language. Think about your project from multiple angles:

  • Language ecosystem: awesome-rust, awesome-python, awesome-go
  • Tool category: awesome-cli-apps, awesome-devops, awesome-selfhosted
  • Domain: awesome-ai-agents, awesome-tmux, awesome-shell
  • Meta-lists: awesome is the list of lists — search it

I found seven relevant lists for a single Rust CLI tool by thinking about it as (1) a Rust project, (2) a CLI app, (3) a DevOps tool, (4) a tmux plugin, (5) a shell utility, (6) an AI agent tool, and (7) a self-hosted application. Each angle pointed to a different list.

Pro tip: Check how recently the list was updated. A list with no merges in 6 months probably has an inactive maintainer. You'll be waiting a long time.

Step 2: Read the Contribution Guidelines (Seriously)

Every awesome list has different rules. Some are strict. Here's what varies:

Star minimums. awesome-rust requires 50+ stars. awesome-cli-apps requires 20+. Many lists have no minimum. Check before you invest time in a PR.

Age requirements. awesome-cli-apps requires your first release to be 90+ days old. awesome-selfhosted requires 4+ months. Don't submit a week-old project to a list with age gates.

Entry format. Some lists use * bullets, others use -. Some want badges, some don't. Some use YAML data files instead of Markdown (awesome-selfhosted does this). Copy the exact format — maintainers reject PRs over formatting alone.

Sort order. Most lists are alphabetical within sections. Submit to the right position. This is the most common fixable mistake in awesome list PRs.

Section choice. Pick the section that fits best. If your project could go in multiple sections, pick one. Don't submit to three sections in the same PR.

Here's a real example of how formats differ between two lists:

For awesome-rust:

* [user/repo](https://github.com/user/repo) [[crate](https://crates.io/crates/crate)] - Description [![build badge](badge-url)](actions-url)
Enter fullscreen mode Exit fullscreen mode

For awesome-cli-apps:

- [app-name](https://github.com/user/repo) - Description.
Enter fullscreen mode Exit fullscreen mode

Same project. Completely different entry format.

Step 3: Write the PR

Keep it simple. The PR should include:

  1. One commit. Don't restructure the list. Just add your entry.
  2. A clear title. "Add ProjectName" or "Add user/project to Section Name"
  3. A brief body. One sentence about what the project does. Link to the repo. That's it.

Don't write a sales pitch. Maintainers are curating, not buying. They want to know: what is it, does it belong here, does it meet the requirements.

Common mistakes that get PRs rejected:

  • Adding your project to the wrong section
  • Not following alphabetical ordering
  • Including promotional language ("the best", "revolutionary")
  • Submitting to multiple sections in one PR
  • Missing required badges or format elements

Step 4: Wait (Then Follow Up Politely)

Here's the part nobody tells you: awesome list PRs sit for weeks.

Maintainers are volunteers. Most popular awesome lists get dozens of PRs. Your submission is competing for attention with spam, low-quality projects, and other legitimate submissions.

From my experience across seven submissions:

  • One PR was acknowledged within 24 hours
  • Two have been sitting for 14+ days with no response
  • One has been open for 40 days

Follow-up etiquette:

  • Wait at least 7 days before your first nudge
  • Keep it short and friendly: "Just checking in — happy to make any adjustments if needed"
  • If your project has improved since submission, mention specific updates
  • One follow-up comment is fine. Two is the max. After that, the maintainer has either seen it or the list is inactive.
  • Never close and re-open the same PR to bump it

If a PR sits for 60+ days with zero maintainer activity, it's probably not getting merged. That's OK. Close it cleanly and move on.

Step 5: Track Your Backlinks

Once PRs start getting merged, track the SEO impact:

  • Google Search Console shows when new backlinks appear and how they affect your search rankings
  • GitHub traffic analytics (Insights > Traffic) shows referring sites — awesome lists show up here
  • Star history often shows small bumps after awesome list merges

For a project in the 10-50 star range, a single awesome-list merge from a popular list can drive 5-20 new visitors per week, indefinitely. That compounds.

The Bigger Picture

Awesome lists are one piece of an open source distribution strategy. They work best alongside:

  • Dev.to / Hashnode articles (more backlinks, different audience)
  • Reddit posts in relevant subreddits
  • GitHub Topics (free discovery via github.com/topics/your-keyword)

The effort per submission is small — 15 minutes to read guidelines, 5 minutes to write the PR. Even if only half get merged, the permanent backlinks and discovery are worth it.

Start with the list that fits your project best. Read the CONTRIBUTING.md. Format your entry correctly. Submit. Follow up once. Move on to the next one.

Your future self (and your search rankings) will thank you.

I'm building Batty, a tmux-native supervisor for AI coding agents. Currently going through this exact process — 7 awesome list submissions, results pending. Follow along for more lessons from the open source trenches.

Top comments (0)