↗
Jess Frazelle
Jess Frazelle works on Kubernetes full-time. Previously she maintained Docker, a software containerization platform used by thousands of teams.
Read more
→
I was already familiar with Docker, but I opened my first pull request on July 9th, 2014. It was to fix some duplicate IP tables rules. After joining the company and contributing more, I became a maintainer.
Even though I’m no longer at Docker, I still work on open source full time for Kubernetes—it’s awesome! l contribute in my free time, too, but it’s super nice to be paid for something I would do anyways. Then I get to spend 100 percent of my time on code being released to the public.
First get through the pertinent stuff via uber-sophisticated-yet-awful email filters, the labels “github/ping” and “mailing lists/participating”:
Then get on with it:
I remember the first time I contributed to a large project was Docker. I must have read the CONTRIBUTING.md like 50 times and triple/quadruple checked my pull request before opening it. I was so nervous. I quickly learned that no one really minds if you mess up, either a bot will catch it or a human will. I think it has given me a lot of confidence to contribute to other projects.
Contributing also makes me prioritize working on open source code. I now understand just how cool it is to be able to “ping” an expert when you need help. For example, when we were building the user namespaces support into Docker, a kernel maintainer for namespaces commented on the pull request and made sure it was implemented correctly. It’s so valuable for a project to not only have input from others but from the actual people who built what you are trying to integrate.
People. I think the hardest part is dealing with people problems. It might be that jerk that opens issues and is super mean, demanding, and/or condescending. It could be the community member who is upset their patch got closed. A lot of maintaining is keeping everyone happy. I also think a lot of this is how maintainers react when all this starts to weigh on them. Is it destructive to the culture of the community? Is it bringing everyone else down?
There is a lot involved in a healthy community, and a lot of it is just people problems.
Interacting with the other docker maintainers on IRC. It seemed like someone was always awake at any time of day or night so there was always someone to chat with. Plus we would talk about super random things as well. I convinced another maintainer to get their first breakfast burrito, then got to see their reaction. I got to know the other maintainers so well we became friends. When you work on open source full time, your coworkers are the community—that has to be my favorite part.
Another one of my favorite things is that I got all the maintainers to start referring to “systemd” as “butts.” Or at least to know if I said “butts.” I meant “systemd.”
“I got to know the other maintainers so well we became friends. When you work on open source full time your coworkers are the community—that has to be my favorite part.”
Good luck! OK, but seriously I would recommend checking out the bots other projects use to free up some time from continuously repeating themselves. Try and reuse those bots for your use case, and instead of building something completely new, try to work with other projects to make something both your projects could use. Take time off when you need it. People may push you to extremes and make you feel you need to respond right away but listen to your needs as well.
“Take time off when you need it. People may push you to extremes and make you feel you need to respond right away but listen to your needs as well.”
Probably documentation, same goes for Kubernetes. Building cool things and adding features is awesome, but if no one understands how to use said features, it is kind of pointless. :)
project
location
day job
From flexible hosting to data‐powered security, get everything your team needs to build at their best.
Contact sales