Sefism Open Source Roadmap

What this roadmap is

The Sefism Open Source roadmap takes you from "I can build small programs" to working confidently in codebases you did not write. It runs in six stages, from how projects are governed to maintaining a project of your own, with a mentored programme such as Google Summer of Code, Outreachy or LFX Mentorship along the way.

The outcome is concrete. By the end you can:

• Fork, branch, rebase and open a clean pull request that follows a project's contributing guide.
• Show at least three pull requests merged into a project you did not start.
• Triage issues, review other people's pull requests and take part in project discussions as a regular.
• Write a mentored programme proposal with weekly milestones, backed by merged contributions.
• Maintain a public repository with a README, licence, CI, issue templates and tagged releases.

Those are things a reviewer can open and check, which is the real value of open source on a profile: public, reviewed work in someone else's codebase.

Who it suits, and who should start elsewhere

It suits students and engineers who can already write small programs in at least one language and want real-world experience: reading unfamiliar code, taking review from strangers and shipping changes that other people depend on. It is a strong fit if you have few internships to point to, or if you are aiming for a mentored programme next year.

If you cannot yet build a small program on your own, start with the Programming roadmap and come back. If Git itself still feels like magic, the Developer tools roadmap covers the terminal, Git and editor habits in more depth than stage two here. If your goal is turning contributions into a job, pair this roadmap with Job search and LinkedIn and personal branding.

Prerequisites and realistic time

You need one language you are comfortable in, a GitHub account and a machine that can build the projects you choose. No prior contributions are expected.

The six stages add up to about 158 hours. On Sefism's default pace of about 5 hours a week that is roughly 32 weeks; at 8 hours a week, about 21 weeks; at 12 hours a week, about 16. The first two stages are marked as foundations, so if you already work with forks and rebases every day you can skim them.

Much of the time is calendar time rather than effort: maintainers take days to review, and mentored programmes run on fixed yearly timelines. Plan around that rather than against it.

A sample week for a student (about 8 hours): two evenings of one and a half hours on the current stage's reading or Git practice, one longer weekend session of three hours inside your chosen project (building it, reproducing an issue, writing the change), and two short slots for replying to review comments and reading the project's discussions.

A sample week for someone working full time (about 5 hours): two 45-minute weekday sessions for review replies and reading code, and one three-hour block at the weekend for the actual change. Keep one issue open at a time, so a busy week never leaves a maintainer waiting on you.

Stage by stage

1. How open source works (8 hours, foundation)

Before touching code, learn how projects are run. Topics: why people and companies contribute, what an open source licence does, permissive and copyleft licences, maintainers and project governance, contributing guides and codes of conduct, CLAs and DCO sign-offs, and issue and pull request etiquette. The point the stage makes early: most rejected first pull requests break a norm, not a test.

Milestone: pick three projects you already use and, for each, write down its licence, who makes decisions and the steps in its contributing guide.

2. Git and GitHub for contributors (20 hours, foundation)

Contributing means working in a repository you do not own. You learn the everyday commands (status, diff, stash, log), forks with origin and upstream remotes, feature branches, commit messages and Conventional Commits, keeping a branch up to date with rebase, resolving conflicts during a rebase, and squashing and force-pushing safely. Tauseef's advice for this stage is to learn a dozen commands properly rather than fifty badly, never to work on your fork's main branch, and to use --force-with-lease, never plain --force.

Milestone: in a practice repository with an upstream remote, open a pull request from a branch, rebase it onto an updated upstream, resolve a conflict, and squash it into commits with clear messages.

3. Your first merged pull request (20 hours)

Get a small change merged into a real project. Topics: finding beginner-friendly issues, claiming an issue the right way, running a project locally, documentation and test contributions, opening a pull request, writing its description, passing CI checks and responding to review feedback. The stage comes with a checklist: rehearse once with the First Contributions exercise, shortlist three active projects, get the tests passing locally before changing anything, comment on one unclaimed issue with your plan, keep the pull request to one change, and answer every review comment.

Milestone: one pull request merged into an active project you did not start (not a practice repository), with a reply to every review comment on it. Small and boring is the goal: a broken docs link, a missing test, a confusing error message. Typo-only pull requests sent to collect a count are noticed by maintainers.

4. Becoming a regular on one project (40 hours)

One-off pull requests teach little. Here you commit to one project for a few months. Topics: choosing the project, reading a large codebase, project discussions and channels, issue triage, reproducing bugs with a minimal example, reviewing other people's pull requests, bug fixes and small features, and (optionally) proposals for bigger changes. You trace one feature end to end with a debugger, follow the project on CodeTriage, review three open pull requests and take one issue beyond the beginner label after agreeing the approach with a maintainer.

Milestone: three merged pull requests to a project you did not start, at least one a bug fix or feature rather than documentation, plus five issues you reproduced or triaged.

5. Mentored programmes (40 hours)

Google Summer of Code, Outreachy and LFX Mentorship pair you with maintainers on a fixed-length, usually paid project. Topics: the programmes themselves, timelines and eligibility, choosing an organisation and a project idea, contributing before you apply, writing a proposal with milestones, working with a mentor, and optionally Hacktoberfest and the MLH Fellowship. The advice is blunt: strong applicants start two to three months before applications open, inside the organisation they will apply to, and a rejection simply means applying again with a longer history.

Milestone: submit a proposal to one mentored programme with a week-by-week plan and links to at least two merged pull requests in that organisation.

6. Maintaining your own project (30 hours)

Run a small project the way good maintainers do. Topics: README and quick start, choosing a licence, a contributing guide and code of conduct, CI with GitHub Actions, issue and pull request templates, writing good first issues, semantic versioning and releases, reviewing outside contributions, and sustaining yourself as a maintainer. Start with a tool you needed yourself, because projects built only for a portfolio are usually abandoned by the second month.

Milestone: publish a project with a README, licence, CONTRIBUTING.md, CI running tests on every pull request, two labelled good first issues, and a tagged release with a changelog.

Projects that fit the last stage

The roadmap suggests six project ideas from the Sefism library for your own repository:

• Developer portfolio and blog generator from GitHub, a small tool others can install.
• Good first issue finder for university open source clubs, which filters stale and claimed issues: the problem you just lived through.
• Open source contribution matcher, ranking issues by personal fit and project responsiveness.
• Web accessibility regression testing in CI, a CI tool other projects can adopt.
• Dependency supply chain risk scanner, scoring maintainer health and dependency risk.
• Evidence-grounded pull request review agent, for those who want an AI angle.

How it works on Sefism

The public page at /roadmaps/open-source/ shows the full list of six stages, with the first two stages open to read. Each stage lists its topics, milestone, Tauseef's advice and the resources picked for it, such as the Open Source Guides, Pro Git, Learn Git Branching, Good First Issue, CodeTriage and the official programme pages.

Everything here is free to learn from. Adding the roadmap to your dashboard uses credits: your first roadmap is free, and new members get starting credits for the rest. Once added, every stage opens, you can tick off topics and milestones as you go, each topic gets a short self-check question and an AI study prompt that quizzes you rather than doing the work, and the companion cheat sheet comes with it. If you get stuck on a stage, you can send Tauseef a question about it. Create a free account to start.

The companion cheat sheet

The Open source cheat sheet follows the same six chapters, with 51 concepts covering licences, the contributor Git workflow, pull request habits, triage, mentored programmes and maintainership. Use it to revise after each stage and keep it open while you work on a real pull request.

Related on Sefism

• How to learn Git and GitHub properly
• Projects, DSA, open source or networking: where to spend free time
• How to read and understand a large codebase
• Everyone has internships and projects and I have almost nothing
• Git, properly: the model behind the commands you use every day
• Library: Google Summer of Code, Outreachy, LFX Mentorship, Open Source Guides: How to Contribute

What you can do afterwards

You will have a public trail of merged, reviewed work, a project you maintain and, ideally, a mentored programme on your record. That gives you real answers to "tell me about working in a large codebase" and "how do you handle code review". Natural next steps are Job search to turn the work into applications, or Your first tech job, which builds on the same review and pull request habits.

FAQ

How long does it take to get a first open source pull request merged? The roadmap gives the first-PR stage about 20 hours, after roughly 28 hours of foundations. The waiting is often longer than the work: pick active projects where maintainers reply to new issues, and expect a week or so before a polite nudge.

Do I need to be an expert programmer to contribute? No. The roadmap starts with documentation, tests and labelled beginner issues, where maintainers expect newcomers. You do need to build the project and run its tests locally before changing anything.

Is open source still worth it in 2026, with AI writing code? The roadmap's case is about the parts AI does not replace: working inside someone else's codebase, agreeing an approach with maintainers, and taking review in public. Those are visible, checkable signals that a reviewer can open.

How do I get into Google Summer of Code or Outreachy? Stage five's answer: read the official timeline and eligibility, shortlist two organisations, get two pull requests merged there before applications open, and write the proposal as a project plan with weekly milestones and risks.

Should I contribute to many projects or one? One. Months on one project teach more than one pull request to twenty, and it is how maintainers start to know your name.