choosing what to build#

• should be an area you are familiar with

• projection about your final product

• you should have knowledge of hte exiting product, to avoid rebuilding the wheels

• make sure you can do it slightly better

• small enough that you can finish (my note: still important despite we’re in AI era!!!)

• killer feature in the first version. the most important ones must come the first.

• makes sense without users. (anti-example: social apps like instagram) (example: a debug tool, which will work despite having few users)

Implementation is easy and irrelevant#

This is true especially AI era.

Some great projects actually have terrible implementations. In other words, good implementation is not necessary for a good project.

Readme#

people judge you project by its README.

• the simplest demo, from scratch
• mark tags for your repository
• graphs or video beat a paragraph - people hate reading
• no idea on how to write a good readme? copy other projects’ ideas!

Now let people know about it.#

• find your users
• make videos and demos
• write articles: write about the problem, not the tool.
  • No one will search your unknown projects. but people do search for their problems. so you should describe problems that your project solves
  • fun idea: “greatest XXXs in 2026” put all well-known ones and put yours alongside.

but it is really hard to build a new community#

people are recognized by their roles in larger open source projects#

Prerequisites#

• know how to use git
• write reasonable code
• understand the code base
  • you don’t have to understand everything
  • but at least you shold know the parts you are going to contribute
  • choosing a project you already working with is good, since you already have knowledge about it

where to start#

• tests: extra coverage. an extra check or clearer failure info. stabilization. optimization.
• bugs: reproduce the bug first. then fix it with enough thought behind the fix
  • anti-pattern: what breaks other functions/tests or changes irrelevant behaviors
• out-of-date stuff: flag or remove unused things.

The goal is to make it obviously better. (so the maintainer is more likely to merge your codes)

Anti-Pattern#

Don’t start with typos, docs, refactor, cosmetic change, a new feature, version upgrades

A PR is the beginning, not the end#

One of the hardest parts of merging your first PRs is getting a reviewer.

• tag people responsible for the scopes gently

Iterating on a PR is communication#

• respond fast
• explain your thinking in detail if you disagree with someone
• don’t argue about everything. (i.e. be nice)

From contributor to committer#

Committer status is not a title you apply for. It is trust that builds up quietly.

• not just writing code.
• start reviewing code.
• involve into community
• own something: keep an eye on some parts of the project that few people notices
• KEEP DOING IT

Contributing in the age of AI.#

• Make the PR more human
• Review and question (yourself, not AI) about the code.
• Less code, less test
• Write the description by hand (or else others may ignores you)