Skip to content

Latest commit

 

History

History
68 lines (50 loc) · 2.62 KB

File metadata and controls

68 lines (50 loc) · 2.62 KB

Contributing

Thanks for your interest in adding to this list. We want this to stay high signal, low noise — the bar is on purpose.

When to open a PR

Open a PR when:

  • You want to add a project that fits a category but is missing.
  • You want to correct a fact (license, description, link, status).
  • You want to propose a new category with at least 3 candidate projects.
  • You want to fix a workflow diagram or improve clarity.

Do not open a PR when:

  • The project is generic dev tooling (frameworks, ORMs, generic databases).
  • The project is a SaaS-only product with no self-host option.
  • The project has no license, or a custom restrictive license.
  • The project is your own and has < 50 stars and no production users (we'll close it; come back when it's battle-tested).

Hard criteria

  1. Open source with a clear license in the repo. AGPL is fine — just call it out.
  2. GitHub stars ≥ 500 OR fills a unique gap (explain why in the PR body).
  3. Active — commits within the last 12 months, OR explicitly archived/mature.
  4. Direct retail/ecommerce relevance — at least one production user in retail/ecom.

Soft criteria (we use these to break ties)

  • Multi-language support / i18n.
  • Self-host works on commodity hardware.
  • Production deployment guides exist.
  • Commercial company behind it (signal of staying power), OR a healthy independent community.
  • License is MIT / Apache-2.0 / BSD (preferred over copyleft for SaaS use).

PR format

### Category: <which section>

**Name**: repo/project name
**URL**: https://github.com/...
**License**: MIT / Apache-2.0 / GPL-3.0 / etc
**Stars**: ~X.Xk
**One-liner**: what it does in < 15 words
**Why include**: one sentence on why it earns its slot
**Use when**: concrete scenario

Style

  • Alphabetical within category, unless the project is the category leader (put it first).
  • Use the existing format: **Name** — description. License. Use when: …
  • Don't editorialize. Don't compare to other entries in the list — readers can read.
  • No affiliate links, no promo codes, no "sponsored" entries. Ever.

Review process

  • First PR from a contributor: I'll review carefully and may ask for a one-line reword.
  • Repeat contributors: trust + light review.
  • Disagreements about inclusion go to PR comments, not blocking. The maintainer decides.

What I won't accept

  • AI-generated mass submissions (you'll get a close + comment).
  • Affiliate links, SEO dumps.
  • "Awesome list of awesome lists" recursion.
  • Projects where the only ecommerce connection is "you can run it in the same data center as your store."

Thanks for keeping the bar high.