Sam Dean | 23 March 2018
Matt Butcher provides tips for managing open source projects based on experience with Kubernetes Helm.
As open source technology has become more strategically important for organizations everywhere, many tech workers are choosing to or being asked to build out and oversee their own open source projects. From Google, to Netflix to Facebook, companies are also releasing their open source creations to the community. These efforts require more management than may seem apparent at first, and there is also a particular kind of “nice problem to have” that can arise. Specifically, a new open source project can suddenly take on a life of its own, growing far faster than ever imagined.
That nice problem to have was the subject of an Open Source Summit 2017 session presented by Matt Butcher, Principal Software Development Engineer at Microsoft. We covered some of his advice for open source projects in a previous post. And, here, we discuss specific project management issues Butcher has faced.
In his talk, Butcher cited examples from the Kubernetes Helm project, which grew to involve hundreds of contributors and thousands of active users in a span of 18 months..
Minefields and sparring matches
One thing Butcher and his collaborators on the Helm project learned is that managing governance and standards is an ongoing challenge. They also learned that code reviews can become “minefields of interaction,” where community members may have unexpected motives behind their messages. “I have been involved in situations where code reviews become a sparring match,” said Butcher.
“With Helm, we developed guidelines for them. They can develop in such a way that some people will just want to weigh in and show that they’re right. In some cases it’s very important to acknowledge contributions We actually have an internal rule in our core maintainers guide that says, ‘Make sure that at least one comment that you leave on a code review, if you’re asking for changes, is a positive one. It sounds really juvenile, right? But it serves a specific purpose. It lets somebody know, ‘I acknowledge that you just made a gift of your time and your resources,” he said.
Shifting perspective
Butcher also noted that team dynamics can change quickly as internal focus shifts to external focus. “At some point you’re going to release your project out into the wild, and then you’ll hit your stability marker, which might be, say, your version 1.0,” he said. “At that point your perspective changes and you say, ‘Hey, instead of huddling together to work on our team dynamics, we’re all going to face outward. That can be a touchy border to be on.”
In the case of Helm, team members reached out in unexpected ways during the early growth phase. “We did some crazy stuff when we were launching it,” Butcher said. “We actually had kind of an internal semi-formal policy that you would pair with people who came in and had big problems, which resulted in random people from the team joining meetings with people they’d never met and saying, ‘Hey, tell me about your problem and let me see if I can help.’ The whole point of this was to try and actively pull people into the community and get them engaged right away.”
Timelines are guidelines
Butcher stressed that project managers should “know what they’re building and be ruthless about sticking to it.” That means, in some cases, that timelines are guidelines. “You want to commit to timelines, because that’s respectful to the community,” he said. “On the flip side, you also are trying to keep your core contributors motivated. You don’t want them to feel undue pressure. In many cases the community understands that you are at the liberty of the contributors and sometimes something does come up. At times, we had to go back to the community and say, ‘we couldn’t do it because the Kubernetes team isn’t ready for us yet, so we’re going to have to wait a little while.”
You can learn more about open source project management in The Linux Foundation’s growing collection of Open Source Guides for the Enterprise. These free online guides cover starting an open source project, improving your open source impact, participating in open source communities, and more.
Share your knowledge and expertise at Open Source Summit North America, happening August 29-31 in Vancouver BC. Proposals are being accepted through April 29th.