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. :)
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.
Start collaborating with your team on GitHub
Advanced collaboration and
management tools for teams
Starts at $25 / month and includes your first 5 users
Free to academic faculty for teaching or non-profit researchChoose Team
Security, compliance, and deployment controls for organizations
Free for educational institutions participating in the GitHub Education program
Want to use GitHub on your own? Check out our plans for individuals