Build what's next on GitHub, the place for anyone from anywhere to build anything.
Join us October 28-29 in San Francisco or online for GitHub Universe, our flagship developer event uniting people, agents, and the world's code.
We’re sharing interviews from several open source contributors about their projects, challenges, and what a GitHub sponsorship means to them. This week, read about Siân Griffin.
With the launch of GitHub Sponsors, open source maintainers and developers can apply to receive funding from the community that depends on their work. Through sponsorship, open source maintainers have the freedom, financial security, and autonomy to continue the work they’re passionate about to further build and strengthen the open source community.
Over the next few weeks, we’re sharing the stories of several open source contributors. Learn about their projects, challenges, and what sponsorship means to them.
Sage Griffin is co-lead of the crates.io team, the creator of diesel.rs, and co-host of yakshave.fm. Sage has worked full time in open source for five years and is currently attempting to fund work on crates.io and the Rust ecosystem.
The project I try to spend the most time on is crates.io, which is the package registry for Rust (e.g. npm, rubygems.org, etc). I co-lead the team responsible for keeping the registry running, and handle most of the daily operations and support.
I also created Diesel, which is an ORM and query builder for Rust. Most folks know me from the many years I’ve spent working on Rails (mostly Active Record) from versions 4.1 to 5.2.
I originally got involved with crates.io because of Diesel. I created Diesel as an excuse to play with Rust as a higher-level language, and I needed a real application to use as a sandbox to explore APIs. I never intended to publish my fork, but crates.io showed interest in porting to Diesel, so I made the effort to move the project over.
I was mostly involved as a code contributor to the project until a point came where there was a (minor) bug in production and no one was around to deploy. At that point my co-lead and I took over operations and created the formal crates.io team.
Since then, there’s always been a pretty large backlog of technical, operational, and organizational debt to get through. I kept telling myself that, in a few months, I’ll get through the backlog and start focusing more on other things. It became clear that “in a few months” wasn’t ever going to come, and there was a clear need for someone working on crates.io full time. At that point I left my job, and I’ve been figuring out how to fund my work on crates.io ever since.
Onboarding new contributors is a huge problem in open source. I’d wager that the majority of large open source projects would say that they’re understaffed. It’s hard to find new contributors at all, and when they show up it takes a lot of work to get the first few pull requests merged. It’s not until their third or fourth commit that they really start to be able to heavily contribute to the project. But it’s extremely hard to get people to that point—75 percent of contributors on rails have two or fewer commits.
There are a lot of things that can be done by maintainers to improve this (mentoring, curating easy issues, etc.). But by the time a project has this problem and everyone involved has started to think about this stuff, it’s probably grown to the size where there aren’t enough people to handle incoming issues. Time spent getting new contributors gets cut, which means the gap between the issue backlog and the people able to take care of it grows even more, and the cycle continues.
This can also mean that the original maintainers find themselves spending all of their time mentoring or doing issue triage, and no longer get to spend much time working on the features they want, which can cause a lot of people to burn out and leave projects.
Crates.io is a very different project to work on than most open source applications. Being an open source service has very different challenges associated with it. Normally open source is “love it or leave it”. But with an open source service, if someone disagrees with how we’re handling things, they can actually come attack us. They can try to take the service down, or fill it with spam, or any number of malicious acts.
This is also the first time I’ve been in this sort of leadership role. It’s not quite a management position, but I do find myself spending a lot more time coordinating, running meetings, or writing documentation and less time writing code. As we try to grow the team in 2019 I hope to be spending even more time focusing on that.
All of this has forced me to really try to improve my communication skills. I’ve often been the very terse, sometimes bitter open source maintainer. When going through issues, I’m usually pressed for time which meant I was always brief and didn’t necessarily show folks the respect they deserve. That doesn’t work with this project, or any. Folks often take what I say as representative of the team, which means I need to be very measured in how I respond.
By far our largest need is growing the operations team. Right now there are only a handful of us who can deal with service issues, even the ones that are fixed by a restart. It also means that our on-call rotation is tiny. I’m either on-call or backup 100 percent of the time. Being able to hand off more of the normal operations would allow for more time to focus on growing the team—and maybe even get back to writing code.
When I decided to start working on this full time, I did so without an employer sponsoring me. I’m still not 100 percent sure how I’m actually going to fund this. Getting support from the community definitely helps take the pressure off from finding other sources of income. There are a lot of tools out there for this, but none of them have felt like a good fit for me in the past. Having this sort of sponsorship come from developers where we actually do our work just makes sense. And not having to give up five percent or more of the income makes a huge deal when I’m trying to pay my mortgage.
By supporting me, you’re supporting the person who gets woken up at three in the morning when crates.io goes down. This project is a critical piece of the Rust ecosystem. If crates.io is down, nobody who uses Rust can do their job. It’s a huge responsibility and one that I want to devote as much of my time to as possible.
Want to learn more about featured maintainers? Read about:
Check back soon—we’ll be adding new interviews every week. Contact us If you have ideas about how GitHub Sponsors can better serve the open source community.
