Back in the early 2010s, I ran a program called 'Open Source Comes to Campus'. We'd go to college campuses around the country and host day-long workshops introducing students to open source, teaching them social norms and tools like git, and encouraging them to make their first contribution.

I remember at one event, eating lunch with some of the students. They expressed their excitement for the afternoon contribution session. "I've wanted to contribute for a while," they said, "but I know so little. I don't want to be a burden on the maintainer."

"Oh, don't worry about it," I replied. "Everyone was a newcomer once. You won't be a burden!"

I was lying.

Of course, I didn't know it at the time. I was pretty new to open source myself, and I'd never been a maintainer. I was befuddled at how difficult the afternoon contribution sessions were turning out to be.

Students had a hard time picking projects. So we curated a selection of projects for them from local volunteer mentors and friends-of-the-org. But some students still struggled - none of the projects seemed to inspire them.

Students had a hard time picking tasks. So we went through and found dozens of tasks labeled 'good first issue'. But more often than not, things with that label were much more complex than they seemed, leaving students feeling defeated - they couldn't even finish a 'good first issue!'

Even when they found a project and a task, students needed so much more help than I'd anticipated. Help setting up development environments. Help reading code. Help understanding the core concepts and abstractions of the project that were relevant to the tasks they'd picked. Some students were able to pair with mentors and get a contribution finished. But many of them felt bad at the amount of help they needed and most, once the workshop was over and they no longer had a mentor to pair with, felt like contributing again would be insurmountable.

The thing is: making contributions to a project is hard. Maintainers who've prepared for a sprint or hackathon all know that vetting a 'good first issue' to make sure it actually is a good first issue takes more work than just fixing the issue would, the vast majority of the time.

Open source projects are complex. They contain tons of internal context, much of which you have to know in order to contribute.

I've learned a lot over the years about how to make contributing easier, including asking newcomers to find holes in your onboarding and documentation, embracing the non-coding skills newcomers might already be experts in, and identifying low-context tasks and context-building tasks.

That's good stuff. I'm proud of it. I help clients (and friends!) make contributing to their projects easier to this day.

But...

What if newcomers don't contribute?

What if they just...exist, without contributing? Why do we care so much that they contribute right away? Why is it so urgent?

Open source prioritizes contribution—doing—over presence and relationship—being.

On the one hand, this makes sense. Open source communities come together around doing something: building and maintaing a piece of software. But we run the risk of being so focused on doing that we lose the ability to simply be.

The ability to simply be ourselves and feel good about it, without having to prove ourselves through achievement, is a cornerstone of psychological health. It is a hallmark of good relationships to be liked for who you are instead of what you can do. Unfortunately it's an ability that open source culture, and western culture in general, is constantly eating away at. (Have you ever reflected on the phrase "earn a living"¹? In our culture, you literally have to do stuff in order be.)

This pattern doesn't just affect new contributors. It can be even harder on maintainers.

Unlike new contributors, who struggle to find things they can do, maintainers are often overwhelmed by things to do. There's more than they can reasonably handle. But, though the reason they cannot do the tasks is different, it's the same fundamental problem. Both the new contributor and the maintainer are faced with things they cannot do, and the guilt they feel over that eats away at their ability to simply be. The new contributor feels like a failure and leaves the project. The maintainer feels like a failure, and burns out.

It can even become a self-reinforcing cycle. The maintainer blames themselves for not finding ways to help newcomers contribute. They didn't do enough to help the newcomer do things. The newcomer feels like even more of a burden to the maintainer. See how overburdened the maintainer seems? Maybe they'd be better off leaving.

It doesn't have to be like this.

We can create communities that celebrate being just as much as doing. One of the best ways to do this is by cultivating purely social spaces where you can get to know each other as whole people, share pictures of your pets, talk about your favorite books and tv shows, and vent about your day. I strongly encourage projects to host regular hangouts and happy hours. Not project nights—project nights are fine, but they come with an expectation of doing. We want space where people can simply be.

Open Source Comes to Campus's parent project, OpenHatch, had an irc channel the community liked to hang out in. I met some of my favorite people in that irc channel. Those relationships have long outlasted OpenHatch.

Who knows what lifelong friends you'll make by creating more space to just hang out in your project.

You can also audit your documentation and processes to make sure that there's no expectation of doing. For example, your contributor guide could explicitly say that people don't have to contribute to join the community. If you run a project night, you could create tables just for chatting, or juggling, or eating chocolate (shout out to two of my favorite PyCon open spaces²!)

Creating a culture of simply being is its own reward. The lack of pressure makes everyone happier (and, counterintuitively, more productive).

That said. There are two additional reasons to adopt this approach.

First: it turns out 'just being there' is one of the most impotant things that newcomers can contribute. Body doubling is a vital intervention for people with ADHD and can be helpful for neurotypical people (or people who are neurodivergent in different ways) too. I cannot overstate the value of having someone you can vent to, or talk through your priorities with, or someone who can remind you that you have value regardless of whether you merge any pull requests today.

Second: 'just being there' is also a great way for newcomers to slowly gain the context they need to contribute. Yes, people learn by doing, but they also learn by observing, by seeing over time the issues that come up, and the topics that get talked about. A newcomer might not be ready to contribute the first day they arrive in your community, but after five or six months of listening to core contributors discuss bugs and debate design questions they might be ready—and the relationships they've built with others will help them ask for help if they get stuck along the way.

---

It might seem like a lot of my work is focused on helping people contribute to open source. And that's true. But more than that, my goal is to help people be in open source.

So, to newcomers, I say: you have value whether or not you contribute. Your simple presence here, in these spaces, in relationship to us, is its own contribution.

And to maintainers I say: you have value regardless of your project. If you never wrote another line of code, or documentation, or closed another issue, or answered another user question, you would still be a beautiful worthwhile human being. Your simple presence here, in these spaces, in relationship to us, is its own contribution.

Thank you for being in open source with me.

Footnotes