Matt Asay
Contributor

Open source your way to an MBA

analysis
Dec 09, 20205 mins
CareersOpen SourceTechnology Industry

Didn’t have time or inclination to get your Harvard MBA? Just start an open source project instead.

People in tech tend to self-select into different functions: Engineers architect and write code, while folks on the business side do marketing and sales. In open source, however, there’s a confluence of business and engineering, argues Envoy creator Matt Klein in an interview. Indeed, Klein suggests, “Starting an open source project isn’t really any different from starting a company.”

Didn’t have time or inclination to get your Harvard MBA? No matter. Just start an open source project instead.

[ Also on InfoWorld: Are you sure you want to open source that project? ]

The open source MBA

While this might not seem intuitive, anyone who has been involved in open source will likely appreciate Klein’s point. We might not look at an open source project through the lens of business, but the two involve very similar skill sets, as Klein suggests:

If you look at [the activities necessary to growing] a startup, you’re going to focus on things like hiring people, marketing, engineering, etc. All these things have to come together to make a company successful. It’s really the same for open source. You have marketing, you have PR, you have engineering, you have hiring, which is finding maintainers, and contributors. And if you don’t do all of those things well, your project is probably not going to be successful.

In a previous interview, Klein talked about how all this work can add up to crush an open source project creator. And yet “if they don’t do all of these things [like PR, marketing, and “hiring”], they’re just going to throw something over the wall” and it will be a “net negative” for them and their employer.

Always be selling

One critically important thing successful open source project maintainers must do, Klein explains, is to get “customers.” Early on, Klein worked tirelessly to convince corporations to build on Envoy, and he remembers that he was “trying to do whatever it took to actually get them to adopt Envoy, because it was pretty clear to me that if that happened, it would lead to an explosion of growth.”

That first Envoy user of note turned out to be Google, which built Envoy into their cloud load balancing services, among other uses, and has continued to be a great partner for Envoy. But two weeks after Klein and Lyft open sourced Envoy, Apple showed up. Then Microsoft.

The fuse had been lit. That was both good and bad.

When the Envoy “project absolutely exploded,” Klein explains, “We didn’t have the infrastructure in place to support me,” like maintainers and contributors. “It was like a startup that had exploded and was entering hyper growth and really all of the same things that would apply from starting a company apply there.” This meant Klein had to work as hard (or harder) to recruit contributors to Envoy.

Looking back, what has Klein learned? Surprisingly, not much, he notes, from a technical perspective. “I don’t think I’ve learned [much of] anything, technically, in the last four and a half or five years.” The real learning, he says, has to do with management.

I suspect few to no open source maintainers want the title of “CEO” but that’s really what Klein’s job is as maintainer of the Envoy project. “I do all the things that no one else wants to do,” like a CEO, he notes. “And I often joke that the higher you rise in any enterprise, the worse your job actually gets.” 

Better through community

Despite all Klein’s talk about his “open source MBA,” it’s telling that he feels Envoy owes much of its success precisely because he opted to never turn it into a business. This is the opposite of what he was told at the time: “A bunch of people [told me] the only way to have the open source project become successful is if [I] started a company. Like, if [I] didn’t start a company around it, no one would care.”

Klein didn’t agree. Nor was he interested in the kind of success the VCs kept pitching to him. As he wrote back in 2017,

When I sat down and really thought about it, the only compelling reason I could come up with to start a company now was to maximize potential income. This just isn’t a compelling enough reason to do something to offset the industry wide impact I am currently having and the potential to see software that I helped create become truly ubiquitous over the next several years.

Indeed, Klein stresses just how important it has been for Envoy to be built for use, not sale. “I’m a big believer that when you build and operate software hand in hand, you create better software,” he says. “Very few of the projects that have found wide success come from end users, meaning they haven’t come from users that are building to solve [their own] business problems.”

Not only does it matter from a software utility perspective, but also from a project governance angle. With Apple, Google, Microsoft, and other competitors all piling into Envoy, Klein suggests, it was important that he has “always been viewed as a neutral party,” and “wouldn’t steer the project into one entity’s camp or give someone an unfair advantage.” Which suggests that Klein can probably also add “business development” skills to the list of skills needed for open source project maintainers.

We don’t give MBAs to open source creators. Talking to Klein, it seems like we should.

Matt Asay
Contributor

Matt Asay runs developer relations at MongoDB. Previously. Asay was a Principal at Amazon Web Services and Head of Developer Ecosystem for Adobe. Prior to Adobe, Asay held a range of roles at open source companies: VP of business development, marketing, and community at MongoDB; VP of business development at real-time analytics company Nodeable (acquired by Appcelerator); VP of business development and interim CEO at mobile HTML5 start-up Strobe (acquired by Facebook); COO at Canonical, the Ubuntu Linux company; and head of the Americas at Alfresco, a content management startup. Asay is an emeritus board member of the Open Source Initiative (OSI) and holds a J.D. from Stanford, where he focused on open source and other IP licensing issues.

More from this author