Open source is the most credible signal a student can produce, and the one most students never attempt because a large repository looks like a cliff. The way in is not heroics. It is contributing to something you already use, in the smallest way that is genuinely useful, and repeating.

Pick a repository you actually use

The retrieval library in your RAG project, the training toolkit in your fine-tuning project, the web framework in both. You already know its rough edges because you have hit them. That knowledge is your contribution.

Read before you write

  • The contributing guide and code of conduct.
  • Ten recent merged pull requests — what size, what style, what the maintainers ask for.
  • The issue tracker, filtered to labels like good first issue or documentation.

First contributions that are welcome

  1. A documentation fix for something that confused you, with the clearer wording.
  2. A reproducible bug report with a minimal example — often more valuable than a fix.
  3. A test for behaviour that is not covered.
  4. A small fix for an issue a maintainer has labelled as approachable.

How to behave

Comment on an issue before starting so nobody duplicates work. Keep the pull request small and single-purpose. Respond to review within a day and without defensiveness; review is teaching you the codebase. Thank people. Maintainers remember contributors who were easy to work with far more than those who were brilliant.

Turning it into a track record

Three merged contributions to a library you use is a line on your resume that no certificate matches, and a talking point in any interview: you have read production code and had your changes reviewed by its authors. Link the pull requests from your GitHub profile and mention them in your LinkedIn posts — the same visibility that leads to hackathon invitations and mentors.

— Pranjul Rathour, GenAI Engineer from Kanpur, India. Open to GenAI roles, hackathon judging, mentorship sessions and guest talks at any campus: pranjulrathour41@gmail.com.