I think the first thing that I did, which I already alluded to, is… When I say this, it sounds so obvious, but I think a lot of people don’t do it…
The most important thing
It’s just critical to be welcoming and to be nice to people. Particularly early on in a project lifecycle. And I’ve really come to the realization through this process (and you can look at other open source communities and see how they evolve)…
Humans have a herd mentality. By herd mentality I mean that when a precedent is set, human behavior typically follows that precedent.
So the seeds of how people treat each other, the seeds of the process, they are really set by the people that form the core. And again, it’s no similar – there’s open source, there’s corporate cultures… I mean, you see this all throughout human evolution or human history. How these communities get started.. it is easier to follow the herd, it’s much harder to be an outlier.
So if you start a project and you’re a mean a-hole to everyone, then people are gonna join the project and they’re all gonna be mean a-holes, because that is the way that it’s done.
And without naming names, we have seen that in some very notable open source projects. And I think I knew that I did not want to do that. I knew how important it was to set that example from the get-go.
And that ranges from taking meetings with people, trying to help them with their early deployments, to just being nice to people on GitHub, appreciating them for their work and all of this stuff that… Again, it sounds obvious, but people don’t do it.
And I think that early on, setting those examples, the people that became maintainers - they followed that example. And then we have succeeded in building a set of maintainers and contributors that all act in this way. And I really do think that in a short period of time…
(I mean, I looked the other day, and at least on GitHub, just from a code contribution perspective, we’re almost at 600 contributors. Which for a fairly low-level C++… it’s not Go. It’s a pretty low-level project, so that is freakin’ incredible. It just blows my mind. And then you look at all of the vertical products and all these other things that are built on top.)
Again, there’s a lot of reasons that people have done it, but I think that a big part of it is that we actually went through and we built a seed from the beginning of welcoming contributions, and making the community very important, and being nice to each other… And then I think those seeds spread.
Well beyond anything else, I always tell people that just being nice and welcoming and seeing that community and having basic human decency is by far the most important thing.
Other things that helped
Beyond being nice, I think there’s some other aspects, which comes back to some of the things that I was saying, around a lot of… There’s a lot of non-technical reasons that Envoy succeeded. I invested a lot early on in documentation. I’m a pretty decent writer. So making sure that the documentation makes sense, and having some blog posts, and going and talking at conferences… And then, again, having people value quality documentation is something that I think is really important.
And basic things… Like, when we launched, we had a nice website with a logo, and it looked professionally done. I think some people scoff at this idea that you can fake your way through open source. Or you can have a very poor technical product, but you can have a great website and great documentation and all these things, then you’ll become a successful project.
I take a more pragmatic view, which is that (as I said before) it’s like starting a company. There’s eight different things, that range from technical, to documentation, to PR, to marketing, to HR… And you have to win at all of them. So to me, it’s not an and/or. It’s both.
And I think that’s what became really clear to me very early on, is that we need to invest in all of these things.
Some people ask me:
What have you learned in the last 4+ years of open source?
And if I have to be honest with you, I have learned little to nothing technically. I worked on these proxy systems for a long time, and sure, I’ve learned a few things here and there, but I don’t even do that much coding anymore.
I have learned so much about community building, open source leadership, and leading in a sense where – you know, open source is fascinating, because it’s basically anarchy.
None of these people work for me, so it’s about building coalitions, negotiating, and making sure that people are happy. There’s been so many learnings here that have been really incredible.
Matt says many more interesting things in this episode, including
- What makes Envoy different than NGINX and HAProxy
- Why he didn’t start a business around Envoy
- Whether or not he regrets that decision
- What would happen if he left Lyft and went to work at Google
It’s worth a listen 👇
He also gave an entire talk about this at OSCON which you should check out.
Oh, and to get content like this in your inbox every weekend… Sign up for Changelog Weekly rn. ✊