As an open source maintainer, it’s hard not to put a lot of pressure on yourself. You love what you do, and the freedom you give others to take what you’ve made and build their own amazing things. Software freedom is very important to both me and the GraphQL community, and it’s been fantastic to take a project with such a modern focus and make it so accessible.
It’s very easy to dedicate hours and hours to this work, and I’ve come to realize that protecting my time is important. I’ve burnt out in the past, so now I try to recognize the feeling of mounting pressure and move my focus elsewhere if things get to be too much.
GitHub Sponsors helps me manage my focus. If a sponsor comes to me with issues, and they’re significant and addressable, I will absolutely prioritize them. But if something isn’t really a problem, or might be the result of someone improperly using the software, I can set that boundary: I can step back and rely on others, or deal with it when I’m less busy. It’s good to not feel like you owe the eight billion people on this planet everything, and to know that every individual in your community is able to help.
When a hobby becomes an opportunity
I’ve loved open source since 1999. I like the idea that if some software doesn’t do what I want, I don’t have to throw it out entirely and find an alternative, or build a new version myself. With open source, I can take what’s already there and improve it. More importantly, I can share those improvements with other people—and everyone benefits.
I started as a protocol-obsessed 13-year-old, hosting my own email server from my bedroom using Linux. That experience taught me a lot about networking and the power of helping people (not to mention the beauty of the command line!).
Traditional employment isn’t really my thing. Since finishing university, I’ve run agencies and startups, been a freelancer, and contributed to open source. Just over three years ago, I started contributing quite heavily to PostGraphQL, which I was using for one of my startup ideas. Built in Node.js, PostGraphQL enabled me to instantly get a well-structured GraphQL API from my PostgreSQL database. It was a lightbulb moment; I’d spent 10 years building and fighting with REST APIs, and with PostGraphQL, so much of that effort was no longer needed. Not just on the back end, but the front end, too.
PostGraphQL’s GraphQL API was beautiful, but the execution could get bogged down in more complex operations. So I built the prototype of Graphile Engine to allow projects like PostGraphQL to “look ahead” in the GraphQL request and resolve complex queries orders of magnitude faster. Around that time, PostGraphQL’s primary maintainer changed jobs and handed the project reins over to me, so I integrated Graphile Engine and released PostGraphile v4.
To help developers get more done in less time, Graphile now maintains a suite of tools focused around three growing software ecosystems: Postgres, Node.js, and GraphQL. These technologies pair wonderfully together and are getting more exciting for developers. Charities, governments, startups: We have users in every sector, and it has a big impact and saves developers huge amounts of time.
When your biggest supporter is also your wife
We have a lot of contributors, but at the moment it’s me writing the bulk of the code and pushing the projects forward as the maintainer. During the beta period of PostGraphile v4, people started sending me donations, and I began to see the value in transitioning my hobby into a way to earn a living. I thought, why not give the full-time open source maintainer thing a try?
When the kids started school, my wife Jem realized they had some of their time back and wanted to help. We’ve worked together successfully on other technical projects, so it was an easy decision to go into business together. Jem now provides the foundation and building blocks to support me and Graphile. They help engage the community; make sure sponsors are happy and kept up to date; write the newsletter; and manage the documentation website. In short, Jem wears all the hats to enable me to focus on where I add the most value—working on the code—which is fantastic.
The challenge, as always, is that we have to bring money in from somewhere. We’ve got the kids and the house, and we all know GitHub stars won’t pay the rent. Luckily, we were inspired by various other open source projects, such as Vue.js, that have managed to raise a significant amount of donations through GitHub Sponsors and Patreon and get a really good funding base. So we decided to try that, too.
A community that funds together, stays together
One-off donations are a nice thing to have when open source is a hobby. You get a £100 donation and can do something special that weekend. It’s a nice reward, but we can’t rely on that money, which means we can’t plan around it. We determined that if we wanted to work on pure open source development—where we spend 99 percent of the money we get from supporters to produce the open software they’re funding—sponsorship was the best route.
It all started with one amazing supporter making regular large PayPal contributions. He encouraged us to keep going and take this seriously. From there, we moved to Patreon which helped us increase our funding base, but is not optimized for open source. We felt that sending supporters to an unfamiliar place to create an account and submit money was a barrier. Then GitHub Sponsors came out; it’s right there where people already are. They just tap to give back. And once the community starts sponsoring one person, they’ll sponsor another. That first barrier is broken, so they give a little here and a little there, and the whole open source community benefits. I feel that GitHub Sponsors is really good for the ecosystem as a whole, and I really want to support that.
Learning together and taking a step back
From the start, we’ve been strict to ensure people adhere to the code of conduct in the Graphile community. It’s positive, open, and hospitable, and a lot of that shows when people ask for help through our chat system. They usually get a response within a couple of hours, either from me or the community. We ensure they know they’re welcome here, which starts a chain reaction. They help the newcomers, who help the next newcomers. We encourage a vibe where the community nurtures new relationships. Everyone is learning together.
At the core of GitHub is the community base, which connects you with almost everything else in open source. We can link two maintainers and they can see each other’s work and gain each other’s respect, even if they’ve never heard of each other. I love that spirit of helping.
Unfortunately, some people who use open source don’t engage in a positive manner, perhaps with inappropriate outreach or an aggressive tone. I think that can be due to a sense of entitlement, since everything is free in open source.
Once, when version four of PostGraphile was still in alpha, someone got really upset that the documentation was unfinished and went on a massive tirade. I’m proud of the way I handled it: I took a break, and responded when I was calm and collected later that day. They made some valuable points, so I dealt with those, released improved documentation, and replied to let them know. Sadly I never heard from this person again; I think they had let things get overwhelming and lashed out.
You have to have thick skin as a maintainer, and in open source in general. When someone is upset, maintain empathy and meter your reaction. Take time to read beyond their words and try to understand where they’re coming from. Once you’ve digested their frustration, then you’re in a position to reply.
Setting boundaries and leaning on the community
I’ve learned to limit direct communication: I accept DMs from sponsors, paying customers, and friends, and gently remind everyone else to seek support via a public channel. This helps ensure content isn’t locked away in hidden channels, gives other community members a chance to provide answers, and helps scale my support. If one person has a question, it’s likely others would benefit from the answer, too. For common requests, we can ping our friendly Hubot instance (named Graphubothttps://github.com/graphile/hubot) to output detailed auto-responses.
In our documentation repository, I have an issue called the “Benjie responses megathread.” Anytime I respond to a question that I think the docs don’t cover and might be asked again, I’ll add it there with the intention to write the documentation later, or pull in help from the community.
Just like our software is one to many, I try to make all my responses one to many. I'm so grateful to the open source community; the more people I can help, the better.