For more background, I cover a lot of how I got started with OSS in this blog post. I wrote: in no way was I able to do anything without the many folks in the community who helped, taught, and inspired me!
When I first heard about Babel, I got really excited about the ways it could improve the development experience. I followed Dan Abramov’s advice: "watching" (really lurking on!) the GitHub repo to try to get more context into the project and its issues. I made my first Babel pull request on March 2, 2015.
Then Sebastian (the creator of Babel) made the issue: Looking for a maintainer for a non-core Babel project, so I reached out to help. Being added as a "collaborator" soon after helped push me to get more involved. I started reading every issue and pull request and began to think about the project as a whole. I didn’t realize that after a short while I had become a Babel core maintainer, rather than just a "collaborator".
I believe the list has changed as I’ve learned about new aspects of maintenance!
I’ll work on bugs and features (which is great), but the project health still suffers without contributors. That’s why I'm leaning towards doing more of the pure maintenance side of things like making it easier to contribute, finding beginner-friendly issues, spending timing writing documentation on how to contribute, etc.
There are the regular tasks:
There’s also support:
- Being available for answers (much of which I need to figure out first) on Slack and Twitter, etc
- Checking out related projects: integrations like babel-loader, babel-plugin repos, projects that have Babel as a dependency
- Writing meeting notes, ideas, and discussions for babel/notes
- Sharing the work of awesome contributors, like Babel plugins and talks
- Sharing new features, ideas, and related projects with others
- Reaching out to both community members and projects for help or discussion
And project sustainability:
- Figuring out where we can improve with automation or better infrastructure
- Measuring project health for both contributors and maintainers
- Exploring options for partnering with organizations (GSoC, RSoC, coding bootcamps, and schools)
Being able to work out problems with so many awesome collaborators has been great. Huge shoutout to our whole team and the greater community of people and tools. I’ve been able to learn so much, including:
Empathy: I’ve learned a bit more about caring for your users (it helps that I am a user too). It isn’t just about the code (like all things in life), it’s the people that keep the project moving forward and alive and the community of users
Writing chops: I have a newfound appreciation for writing and see the parallels of being a greater writer and a great programmer. For someone who hated English and writing in school, I'm starting to understand its immense importance in our field
"It isn’t just about the code (like all things in life), it’s the people that keep the project moving forward and alive and the community of users."
We have no idea the amount of work that goes into each and every project. It’s not just the contribution graph but the hours of thought that goes into design, code review, and discussion.
It’s easy for us (and me) to forget that maintainers and users are all people. Issues are opened with the highest degree of entitlement. Unpaid volunteers are expected to help with a problem and with grace and urgency. Angry blog posts and tweets are written explaining how project was done wrong or is constantly buggy.
Like many in open source, I was struggling with the burden of maintaining a project. When I first started doing open source, I used to just stay late to work on it or right when I got home. I replaced a lot of time playing video games with open source.
I’ve tried in the last year to cut back on this, even though it’s hard. I try to spend weekends to rest, and on Sunday block out all of time for church and other related activities. I was able to discuss with my boss the issues I was facing and we came up with ideas on how we could incorporate open source tasks given our own use of Babel.
I'm still trying to understand burnout. Even though it’s been a struggle at times, I just feel blessed to have been able to take part in all of this. As a Christian, I believe my prayers for wisdom in maintenance and grace in discernment really showed in my interactions with others, and I hope that my experience has helped or inspired others to get involved in open source.
"Even though it’s been a struggle at times, I just feel blessed to have been able to take part in all of this... I hope that my experience has helped or inspired others to get involved in open source."
Being able to meet other developers whether online, at meetups, or at the few conferences I’ve been to has been such a joy for me, but one moment stands out: learning about Guy Fieri!
- Don’t shoulder the burden on your own. It’s better to have help than total control. You can always naturally scale up as your project gets bigger or more popular, but I would suggest adding other collaborators as soon as possible
- Separate yourself from your project, even though it can be very difficult to not take things personally
- You can only do your best! Try not to lose sleep over a bad release, bugs, hundreds of open issues, complaints on Twitter, and an overwhelming amount of support questions
- Continuously reach out to people to become contributors. Actively determine what needs to change on the project’s end to help facilitate that
- Learn from criticism. Each piece of feedback could mean a potential change to the documentation, a bug in the code, or just a need for better error messages.
- Help each other. Talk to other maintainers about their issues and struggles
- Document everything. It doesn’t have to be public if it’s just your ideas or thoughts, but meetings and discussions should be public if possible
- Tell people (tweet) what you are working on while you are doing it rather than only after. It shows you the process and that we all make mistakes
The greatest contribution need for Babel
I think the greatest need for Babel is just more contributors. For a project that’s downloaded ~6 million times a month, there’s still no one who actually works on Babel full-time, and only a handful of contributors. Someone (or more) working on Babel full time would be great: if not code, then project management. We’d also love to have:
- Contributors doing things that aren’t necessarily code. We can improve our documentation, DX with less dependencies and config, easier setup (babel-init), integrations with other tools (automatically configured via create-react-app, and more
- Contributors from underrepresented backgrounds. We’ve been accepted as a Rails Girls Summer of Code project and are looking for teams to join us, or anyone really, if they’re looking for mentorship
What will your story be?
Learn how to run a successful project
Open source is made by people just like you. Learn how to contribute, launch a new project, and build a healthy community of contributors.
An easier way to contribute to open source
Every Friday, invest a few hours contributing to the software you use and love.
Meet other maintainers
Brett Cannon made his first open source contribution more than 15 years ago. Now a Software Engineer at Microsoft, he’s still a core contributor to Python, a project he has contributed to for more than a decade.
Russell Keith-Magee created BeeWare to fill a gap in his own process. Today, BeeWare is the go-to project for supporting Python on every platform.
Tim Graham started contributing to Django as part of a college research project. Now he helps maintain the popular web framework full time as a Django Fellow.