Contributing to Open Source as a Product Designer

I didn’t set out to write code. I set out to make design contributions and write documentation, which felt like the safest possible entry point into a codebase with thousands of contributors. It was. It also turned out to be a door into everything else.

Here’s what actually happened, and what I’d tell any designer waiting to start their open-source journey.

My First Introduction to Open-source

The first time I heard about open source was during my college years, when I heard people talk about GSoC (Google Summer of Code).

There were project lists and proposal deadlines. I read a few of those project descriptions and quietly closed the tab. It was all repositories and pull requests and languages I didn’t know.

I wasn’t from a computer science background. The whole thing seemed to be built for people who could code, or so I thought at the time.

I did not do anything about it for years. Until I did.

It was in December 2025 that I finally made my first contribution to GitLab.
And the thing I want to say to anyone who felt the way I felt in college is this: the barrier I imagined was almost entirely made up. Not because open source is easier than it looks, but because I had misunderstood what it was asking for.

Taking the small first step

My first merge request was adding alt text for images.

That’s it. It was one of those issues explicitly tagged for first-time contributors, the kind maintainers keep around precisely so that people like me have somewhere to land. In terms of impact on the product, it was minuscule.

In terms of impact on me, it was the whole thing. Because what I was actually learning wasn’t alt text; it was the machinery around it.

How to fork a repo. How to make a branch and not panic at the terminal. What a merge request template expects from you. What happens when a reviewer leaves a comment, and you have to go back in and change something.

No tutorial teaches you that.

You can watch as many Git explainers as you like and still freeze the first time you have to push something with your name on it into a repository that thousands of people work in.

The only cure is doing it once on something low-stakes enough that being wrong doesn’t cost anyone anything.

Finding something that was actually mine

After the first contribution, I started looking for a design-related challenge and discovered Pajamas — GitLab’s design system.

A few months later, I came across an open issue proposing role-based “Get started” guides for the design system — one for designers, one for developers, one for brand.

A common feature in documentation that Pajamas did not have yet.

I read it and realised something that hadn’t occurred to me during the college years: I was probably better positioned to write the designer one than most of the engineers in that repository.

Not because I knew the codebase better.

Because I had been the confused new designer, roughly six months earlier, trying to figure out where to start with Pajamas — as a designer.

I knew exactly which questions that page needed to answer, because I’d had all of them.

A page that explained to a new designer how to get Figma access, enable the UI Kit libraries, use a component, and what not to do. I already knew what that page needed to say, because I’d been the person who needed it.

And while working on the issue, I ended up shipping three pages for design, development, and brand.

That’s the shift I’d want other designers to make.

Your first contribution should lean on the judgment you already have.

Documentation, content, information architecture, design-system guidance, accessibility — these are real, merged, credited contributions.

They’re also, conveniently, how you absorb everything else: how the repo is organised, how reviews work, what the team’s conventions are.

Learning from reviews

The clearest case: I’d written a guide for developers and packed it with setup information, everything the project scaffolds for you when you start fresh.

All of it accurate. All of it wrong for that page.

A developer already working in the main codebase has that setup; they arrive with one question, and everything else on the page is noise competing for attention. That content belonged somewhere else, for someone else.

Not everything that breaks is your fault

One more thing, because it cost me a lot of unnecessary anxiety.

At one point, a check on my merge request failed. I went back and read my own changes over and over, convinced I’d broken something.

I hadn’t.

The failure had to do with how the automation runs on forked copies of a repository — nothing to do with my work at all, and nothing I could have fixed.

I lost hours to versions of that. Something red on the screen, and my instinct that it must be me. It usually wasn’t.

Now the first question I ask is whether the failure is even mine, and I only start digging once I’m sure it is. That single habit made the whole thing feel much less intimidating.

If you’ve been circling this for a while

I don’t think I needed more technical ability to start. I needed permission, and nobody was ever going to hand it to me, because nobody was gatekeeping in the first place.

The issue lists were public the entire time. And that is perhaps the most beautiful thing about open source.

So go search.

Find a project that interests you, look for something unassigned, and see where your skills actually meet the problem.

You’ll find more of those than you expect.

And if you do start contributing after reading this, welcome to open source.