TL;DR: For a first contribution, the projects worth your time are the ones where humans answer outside pull requests and first changes are easy to make. Right now the list starts with llama.cpp, Meshery, open-design, stdlib and Ant Design.
In Porchlamp's October 2026 snapshot of 11,000 GitHub projects, the first-contribution ranking scores projects mostly on two things: how quickly humans respond to outside pull requests (35% of the score) and how easy a first change is (30%).
Which open-source projects are good for a first contribution?
The usual advice for a first open-source contribution is to pick something popular. But popular projects are often the slowest to answer a stranger. Your first PR can sit for weeks with no reply, and that's usually where people give up.
So I built a ranking that asks a different question: if you're new, where will your pull request actually get seen?
What it looks at
Two things carry most of the weight:
- Responsiveness (35%): how fast a human answers outside PRs, and how many of those PRs get a decision.
- Accessibility (30%): good first issues that are actually open, and whether first-time contributors get merged and come back.
The rest is governance (15%), how much other software depends on the project (10%), and review and CI practices (10%).
The best projects for a first contribution right now
- llama.cpp
- Meshery
- open-design
- stdlib
- Ant Design
- Organic Maps
- Apache Maka
- Cluster API
- freeCodeCamp
A few of these jump up a lot compared with the default ranking. open-design climbs 63 places and stdlib 49. That means their strengths are exactly the things a newcomer needs.
Two labels you'll see
- "B (capped)": not a bad grade. It means only part of the project's data could be measured, so the tier can't go higher yet.
- The Δ rank column: how far a project moves between the default ranking and this one. It isn't movement over time.
How to use it
- Open the Porchlamp first-contribution rankings.
- Pick two or three projects in a language you know.
- Open each one's pull requests on GitHub and read a few recent ones from outside contributors. Do they get answers?
- Then find a good first issue and start small.
A high rank isn't a promise about your particular PR, but it's a much better bet than stars.
If a row looks wrong to you, an issue on the repository with the pull requests that show it is the most useful thing you can send.
Which project gave you your first merged PR, and how long did it take?
Top comments (2)
I maintain a small project alone, and what makes an issue a good first one for me is that it names the file, says what to change and has one clear way to check it. That's how I try to write ours. #34 in Styx is a decent example: one description string in a test file, with the new text in copy.ts to build it from. Which signals does your ranking weigh most?
Thanks, #34 is a good one: file, change and check are all there.
The ranking mostly weighs how fast maintainers reply to outside PRs and how easy a first change is, but it only counts good-first-issue labels, not how well they're written.
Which of your three matters most?