Open source is like a gifted child grown into a struggling adult. "So much potential! We thought it was the future! What's wrong with it!?"
It might feel strange to say that open source is struggling. There are millions of repositories on GitHub. The biggest and most successful companies in the world use and even release things as open source. Isn't open source thriving?
Certainly some parts of it are. And I would never presume to speak for all of open source. But I care about more than the license. To me, the promise of open source is technology that's accessible and collaborative, that empowers users instead of exploiting them. By *that* metric, open source is not living up to the dream.
I've been an open source contributor for over a decade now. And I keep seeing:
Open source maintainers burning out. Too often, they're working alone, trying to meet the needs of thousands of strangers they've never met beyond the occasional impatient request in an issue tracker. They started their project because they like to code, but now they're asked to be a project manager, community manager, support specialist, designer, fundraising expert, and more—often for little to no money. They're drowning.
New contributors bouncing off open source. People are attracted to the values and the educational opportunities in open source, but they don't know how to find projects that are ready to mentor them. Too often they run into burned out maintainers who don't have the energy to help them. We encourage newcomers to contribute right away, making them think they're only valuable for what they can do, instead of who they are.
Valuable projects going un-funded or under-funded. So many open source projects provide real value to the world, but they don't get the support they need in return. Partially that's because maintainers are too busy and burned out to be effective fundraisers (see above) but it's also because projects don't have good relationships with users and stakeholders. Users have been trained by the tech industry to believe that all tech is built by faceless corporations trying to exploit them, rather than real people who want to support them and who need their support in turn.
Projects that fail their users. The lack of user engagement goes both ways. It makes it hard for users to support projects and it makes it hard for projects to serve their users. Many open source projects are difficult to use. It's not just that they can't compete with the slick design of VC-funded or big tech projects. It's that they seem to be designed for extremely technically savvy users. Maybe because those are the only users who are in communication—in relationship—with the project.
Communities that struggle to adapt to change or fall apart due to conflict. Change is hard. Conflict is scary. And these communities are already under so much stress. They need support in working through problems, whether that's a tough technical decision, a changing culture, or the need for a new governance structure.
What do these problems have in common?
They're all, fundamentally, about relationships.
Good relationships make good technology
Some people use 'relational technology' to refer to technologies that shape relationships, like chat apps or social media. But that's putting the cart before the horse.
I'm focused on the inverse: how relationships shape technology.
Many of the apps that are considered 'relational tech' are built without care for the relationships of workers, users and funders. This leads to exploitative technologies that bring out the worst in people, rather than the best.
If we want technology that helps us have good relationships, then the people building, using and funding the technology need to have good relationships.
Good relationships give us:
- information, which helps us continually improve the technology
- support, which helps our technology be more resilient and reliable
- accountability, which helps us trust the technology
- empathy, which gives the technology meaning
Relationships are the primary way that information is passed from one person to another. A good relationship can be the difference between speaking up with feedback instead of quietly abandoning the project. Tools like issue trackers and kanban boards can help share information, but even then, relationships matter. Maintainers are more likely to pay attention to an issue posted by a friend than one shared by a stranger. In a company, a product manager is more likely to prioritize a feature when someone with power over them has requested it. By strengthening relationships, we increase the amount of information being shared, which is crucial for improving the technology.
Relationships also increase the support people get. This can be financial support, allowing maintainers to spend more time on the project, or educational or emotional support allowing them to work through tough problems. The more support people get, the more resilient they are, and the more resilient the people creating a technology are, the more reliable the technology itself will be. (The XZ Utils backdoor is a painful example . The single maintainer behind the project was so under-supported that he made for an easy target, compromising the project and nearly the internet's whole infrastructure.)
Relationships increase accountability. Sometimes technology has bugs. Sometimes it harms users. No development approach will ever change that. But if we feel like the people building the tech care about the harm they cause and will do their best to fix it, we can keep on trusting the project overall. And when we trust tech, we're much more likely to recommend it to others, pay for it, and contribute to it.
Finally, building strong relationships gives you empathy into how your actions impact others. In the case of open source, an empathetic connection to users helps you see the impact that your work is having in the world, which in turn gives your own work meaning. And at the end of the day, what most of us want is a life full of meaning.
What do good relationships look like?
The Relational Tech Approach goes into much more detail about how to build good relationships. But here's the tl;dr:
A good relationship is one where people can share their needs with each other, and collaborate on getting those needs met.
We can use this needs-first lens to better understand the problems listed above.
Burned out maintainers are being asked to meet the needs of others without having their own needs met. Instead of glorifying these one-sided relationships, we can encourage maintainers to stand up for their needs. Maybe they'll be able to find contributors, users, funders, or peers who can meet them. Or maybe they won't, and they'll have to retire their project. Either way, that's a better outcome than burning out.
Open source newcomers need a supportive environment, one in which their presence in the community, and relationships to other community members, is more important than whether they've made any pull requests. If maintainers are honest about their needs and expectations, newcomers can pick projects that are a good match for them. If a maintainer says, "I don't have a lot of time for mentorship", then a newcomer who enjoys figuring things out for themselves might stick around, while a newcomer who learns through pairing, or asking questions, might look elsewhere.
The lack of funding for projects and the bad user experience are two sides of the same coin. If users can share their needs with the project, that will make the project better and help users understand the project's needs in turn. It also gives users a real stake in seeing the project continue. This is true whether you're talking about crowdfunding campaigns or getting a company who depends on your open source project to invest. When people get something of value from a person they're in a relationship with, they want to reciprocate. But too often there's no relationship at all between projects, and their users/funders.
Finally, communities struggling with conflict—either active conflict, or fear of it—are of course struggling with their relationships. By focusing on the needs of the different parties in conflict, we can understand what's at the heart of the conflict and help resolve it.
Of course, it's not as simple as just forming good relationships. Forming good relationships is...surprisingly hard, actually? And "sharing your needs" might seem straightforward but many of us have big emotional blocks that make it extremely difficult to ask for help. I'd even go so far as to say that open source's culture has, historically, selected precisely for people who feel more comfortable doing things on their own than asking for help from others.
But that's why this consultancy exists. It's the "relational" in "relational tech". Building relationships is hard, and complicated, and under-valued in open source, and I want to change that. So that open source projects and communities and the people they serve can all flourish.
If you're intrigued, here are some things you can do next:
- read The Relational Tech Approach, which goes into my framework and processes in more detail
- browse my services, which put the relational tech approach into action
- join my low traffic newsletter or read the blog
- if your project is struggling with any of these challenges, you can book a free one-hour consultation call
Regardless, thank you for reading!