Brendan Burns on Building Open Source Communities
Kubernetes co-founder Brendan Burns, now a distinguished engineer at Microsoft, has a lot of experience with open source communities, from the load tester JMeter in the late ‘90s to the popular orchestrator tool.
He recounted major eureka moments as well as some “well, duh” lessons from that experience at the recent ChefConf 2019 event in Seattle.
His talk followed a rally for community by Chef’s Nell Shamrell-Harrington.
Chef, of course, is looking to expand its developer community after announcing in April that it’s going totally open source with Apache 2 licensing.
Rejecting the open core model, it plans to collaborate with a community of users on a subscription service of packaged software.
“It’s turned into this amazing learning opportunity about how do you build communities and how do you scale. … There was this quote, something like ‘every order of magnitude, the problem changes.’ It’s just so true,” Burns said of working in open source.
One thing he learned from creating DroidDraw, a graphical user interface (GUI) builder for Android, was how building something and open-sourcing it helps other people.
“At least for me, one of the defining characteristics of all the software that I’ve loved to build has been that it has empowered other people,” he said.
When people come to him about setting up an open source project, the first question he asks is why. What kind of community are you looking to build?
He pointed to multiple types of open source:
- Open for partners — when you want to partner with three or four other people. It’s just a practical way to collaborate among a small set of people. Example: Android.
- Single-vendor open source — You put it out there because it was the right thing to do, it might help you execute faster and in a more open way, but not necessarily because you want contributions. Example: .NET core.
- Open for collaboration — People around the world want to collaborate, but they’re not really looking to build a large community. Increasing the number of GitHub stars is not the focus. Example: Linux kernel.
- Open source communities — Example: Kubernetes
“We really set out to build a community. We knew we had to have an ecosystem. We knew we needed for users to support each other and be successful,” he said.
“It’s not just collaboration around the source, it’s about an open community working in all sorts of venues. We have docs people, we have contributor experience people, we have people ensuring the code of conduct on our Slack channel is OK. … I think it’s inescapable that this thing would not have been successful if we had not done that. It was a real differentiator.”
Microsoft, as well as other companies take part in all these types, he said.
As for that order of magnitude, it evolves as does the project.
- The first 10 people — It’s more like every software project you’ve ever done, he said. You have to get the frameworks right so people can develop software together. You start to need automation, documentation, you’re going to have people come and go.
“Small changes in trajectory early on have a big impact on the future. It’s really important to get all the right pieces in the right place,” he said.
- The next 100 — You start to feel it’s too big, you need smaller teams. You need to ensure this contribution doesn’t break something over there that you don’t really understand.
“You go from being able to hold it all in your head to being able to only hold little bits and pieces in your head at a time,” he said.
You start working on planning. You have to synchronize people’s work.
- 1K and beyond — The problems just multiply. You start worrying about delegating responsibility, sub-teams around release, security, how to manage these various bits of your project. How do you do meetups and conferences? Where are the bottlenecks? The management of the project becomes a task unto itself.
What about bad actors? How do you identify and police people in your community who are not contributing in a positive way?
How do you set a coherent direction? Sooner or later you’re going to need project managers.
“Getting that voice of the community is an incredibly important part of the job. Organizing the work, making sure everyone is happy is an incredibly important part of the job,” he said.
An often-overlooked aspect, he said, is how do you manage needs and expectations.
“Suddenly you’re mission-critical to some company, but they’re not paying you. … You signed up for this because you wanted your project to be useful and used by the world, and part of being useful and used by the world is fixing people’s bugs. But you’re on vacation with your family for the first time in a year. But somebody needs a bug fixed. … You have to figure out how to balance those tradeoffs.”
He said he’s seen a lot on both sides: Maintainers bemoaning that users want bugs fixed. “I’m like, ‘Hey, you signed up for this’” and users being demanding “and, I’m like, ‘Dude, it’s free.’” It’s really tricky to get right, he said.
He calls the need for governance a real “aha” moment for everyone on the Kubernetes leadership team, something they had to figure out on the fly.
“To start a project, you need three things: a read me, a license file and a code of conduct.” — Brendan Burns
He said he prefers a collaborative communal design, “but my goodness is it a mess.” You have to create governance to protect the health of the project, before it becomes an emergency.
A code of conduct is essential, he said.
“To start a project, you need three things: a read me, a license file and a code of conduct. … For me it was shocking. This is just no-brainer stuff. We’re professionals, be professional, be nice. But it turns out, 1,000 people, roll the dice, there are people who don’t get that. You have to write these things down, so you can say, ‘Here’s where we said this, you agreed to it and if not, here’s the door.’”
Focus on building healthy dialogues. You’re going to have disagreements, but do it in a healthy and honest way that moves the project forward.
It’s also essential to manage expectations and burnout, something the Kubernetes team struggled with.
There’s also the issue of forks, he said.
“We have to think about forks as the ultimate escape hatch. A fork is the way a project tells you it’s unhealthy. It’s actually a good thing,” he said.
