No Code? No Problem.

Contributing to Open Source Without Writing Code

Konstantin Taletskiy

Who here has wanted to contribute to open source…

but felt like they weren’t ready?

Asking for a show of hands. Pause. I’ve been in the Jupyter community for 7 years. Some of my most valuable contributions? Zero lines of code.

The barrier isn’t technical

It’s social

Here’s what I’ve learned: the barrier to open source isn’t technical—it’s social. And that means if you can show up, listen, and help—you can contribute.

The currency in open source is trust

• Time
• Presence
• Frequency

Someone told me early on: the currency in open source is trust, not code.

Trust takes three things: time, presence, and frequency.

That’s good news. It means your first contribution isn’t a pull request—it’s showing up. And showing up is something anyone can do.

Show Up

Community calls · Camera on · Introduce yourself · Take notes · Welcome newcomers

Join a community call. Turn on your camera. Introduce yourself. Take notes. Welcome newcomers.

This is the connective tissue of healthy projects—and it’s chronically undervalued.

Here’s the Jupyter community calendar—open to everyone. You can find calls for JupyterHub, JupyterLab, and other subprojects.

Documentation

On Monday—here at this conference—I was doing an NVIDIA tutorial and noticed the docs were out of date. I opened a PR. It got merged the same day.

That’s it. That’s a contribution.

Ecosystem Stewardship

Last month I did a ‘metadata deep clean’ across JupyterLab extensions—fixing broken URLs, updating classifiers, adding badges to READMEs.

Eight PRs. None of them touched application code. All of them made extensions easier to find, trust, and contribute to.

It’s not flashy. But it moves the ecosystem forward.

More ways to contribute

• Issue triage — reproduce bugs, ask clarifying questions
• Answer questions — Discourse, Zulip/Discord, GitHub
• Accessibility — screen readers, keyboard nav, color contrast
• Translation — JupyterLab supports 20+ languages because of volunteers
• Writing & speaking — including ⚡️ talks like this one

Reproduce a bug. Ask a clarifying question. This unglamorous work saves maintainers hours.

Answer questions on Discourse or Stack Overflow. You don’t need to be an expert—you just need to have solved that problem once.

Test with screen readers. Check keyboard navigation. This work is chronically under-resourced.

JupyterLab supports 20+ languages because volunteers translated it. Your fluency is a superpower.

Blog posts, talks, tutorials. Every time you explain a project to someone new, you’re growing its reach. Yes, this talk counts.

Why this matters

• Free maintainers to focus on what only they can do
• Build trust that makes code contributions easier later
• Make the project welcoming to the next person

Maintainer burnout is real. And most of it isn’t from writing code—it’s from everything around the code.

When you take on non-code work, you free maintainers to focus on what only they can do. You build the trust that makes future code contributions easier. You make the project more welcoming to the next person.

Pick one thing this week

• Found a typo? Fix it.
• Unanswered question? Answer it.
• Broken link? That’s a PR.
• Community call on the calendar? Show up.

Pick one thing this week.

Pause between each line. Let them land.

You don’t need mass expertise. You just need to start.

You don’t need mass expertise.

You just need to start.

Let this sit for a beat.

Thank you

LinkedIn

This talk

JupyterLab Marketplace

Thank you.

If there’s time: And if you want to see what a healthy extension ecosystem looks like in data—I have a longer talk tomorrow.