open source

Episode 49: Open Source API Management with Martin Buhr, Founder / CEO of Tyk

Intro


Mike Schwartz: Hello and welcome to Open Source Underdogs. I’m your host, Mike Schwartz, and this is episode 49 with Martin Buhr, CEO of Tyk. API Management is a hyper-competitive market–there are commercial, open-source and SaaS products from which to choose. This makes Tyk’s success even more impressive. I think they’ve done a lot of basic things right: keep it simple, provide great support, make sure customers are happy. That’s enabled Tyk to grow organically, with a relatively small amount of outside investment.

This interview, it’s a little bit on a long side, so, let’s just get on with it. Here we go!

Mike Schwartz: Martin, thank you so much for joining today.

Martin Buhr: Hi, yeah, Mike, thanks for having me.

Origin

Mike Schwartz: In 2016, the API Gateway and Management market was already pretty well-saturated, you could say, with existing well-funded competitors. Why were you crazy enough to jump into this shark tank?

Martin Buhr: Well, the origin story, it’s a bit of a Cinderella story actually. I needed to make a gateway for the platform I was running as a side business, besides my regular job. And the existing solutions that were around were either large enterprise monoliths, SaaS platforms or open-source platforms – there was one or two – but they were getting really, really big. There wasn’t anything small and tactical to just use — I mean, I could use like NginX or something as a proxy, but I needed more than that.

I had just rebuilt my existing services with API first, and the platform itself, I didn’t want to write my own authentication code and I thought, “Well, that’s what API gateway’s for.” And I couldn’t find one, and I thought, “Well, what the heck, why don’t I just build one?”, which is probably a stupid thing to do, but it turned out okay.

So, that’s why I ended up with the Gateway. It was really small tactical at first. Work with my platform was really meant to sort of easy to inject into other ecosystems, without having too much deep integration. And I kind of built on it, to get more metrics out of it and understand how people were using my service. Until eventually, I realized that the side business I was running was awful. It was just costing me more money than it was fun to run.


So, I closed that down and open-sourced the Gateway because I thought why not, it is a pretty decent piece of software. And that’s how I ended up in a market, it was almost accidental. And at the start, I had this dashboard which was the UI for the system, and also gave me some analytics. And I thought, “Okay, I will close-source that and I’ll sell it.” The Gateway itself will be open-source, and I’ll sell them, the dashboard.

I sold the initial version of the dashboard for something like 400£ for a lifetime license because I wanted to take my wife to – I was living in London at the time – I wanted to take my wife to Gordon Ramsey in London, which is this super restaurant.

And their average meal per head is 400£, that’s how the meal cost, which is a stupid amount of money, but it’s a very good food, and anyway. So, I wouldn’t say that I started with a great business model – I just wanted to take my wife to lunch.

Origins Continued

Mike Schwartz: The open-source project started before the company. At what point did you say, well, I think we can really scale this, and what was your plan for sort of scaling the business?

Martin Buhr: After that initial sort of launch phase and sticking up the project on Hacker News with the small website, it got a lot of attraction, lots of people were interested, and loads and loads of different companies came along and emailed me, amongst which some of them were — we had Home Depot, Viacom, and a couple others. Some Fortune 500 sort of emailed me saying, “Oh, hi, yeah. We’d love to try your platform out, can you tell me more, can we get a call?”

But I was having those conversations at six o’clock in the morning because I was in the UK and they were in the US. And there I was in my pajamas, trying to convince them to spend some money with me, and they would tell me, “Well, how does your support work, and how are you going to scale this business, and how is this going to work long-term, why should we onboard this?”

It was the first spur to say, “Well maybe there’s a bit of a traction in this, and maybe I need some help. You know, I’m quite technical, but I’ve not run a business successfully, and marketed it and sold it properly, you know.”
Once we got the initial traction, and I saw a lot of interest, I managed to talk to an old friend of mine, I used to work with, into joining. And he came on – his name’s James – he came on as a CEO, commercial guy, and sort of helped me shape the whole thing. He shaped the business, he shaped the product offering and the marketing, and I shaped the product.


And that was a good team, because we used to work together at the agency, and we were project managers together, so he was very much on the commercial side of things and the operation side, and I was very much on the technical side of things, but we pitched together a lot.

So, we kind of knew each other’s flow, so when it came to — I think one of the first people we had to pitch to was Eurostar in London, which is the link between Britain and France, the train that goes up through the channel tunnel. And when we went there, it was our first real pitch as a company. And that’s sort of how it moved from being an open-source project that had some interest to being something viable. I think one of the things I’d really came back that they sort of told me that we were annoying people or, you know, poking them in the eye with this project was when one of our competitors, and they are not the only ones actually, three of our competitors offered to buy us or acquire us.

And this happened early on, when they came along and said, “Oh, don’t you want to work in Silicon Valley? Don’t you want to do this, don’t you want to do that?” And that kind of thing tells you quite a lot about the business having viability. So, at that point, we thought, “You know, let’s do this.”

Our first real sort of tangible money spending client wasn’t even a client, it was a company in the US in Texas that wanted to try us out, and James sort of talked them into doing an onboarding and training session with, so that we could try it out, and so we could do the integration for them.

So, they paid for the tickets in the per diem for us to go visit Dallas, spent a week there, I learned how to two-step. It was pretty cool, a far too much Tex-Mex food. And we actually never got the client, they changed teams halfway through, so we never actually got the deal, but we did get this real validation. And it was on that trip, where James turned around to me, and he said, “When I get home, I’m going to quit my job.”, because we both had day jobs at the time. And that was it. He was employee zero.

So, that’s kind of the way that panned out. We kind of stumbled into it, and then went into it full-on once we felt we had real traction. It was something there that showed growth. We had people who were actually willing to spend money on the product and spend money on us, so, yes. Does that answer your question?

Mike Schwartz: Yeah, definitely.

Value Prop / Open-Source Strategy

Mike Schwartz: So, today, what would you say is the most important value proposition for your customers?

Martin Buhr: When people come to us for API Management, there’s multiple outcomes they come to us for. They might be breaking down a monolith into a microservice architecture, they might be adopting Kubernetes, they might be looking at functions as a service, or they might be looking at the old-school API economy stuff. So, you know when you said earlier how the market was saturated with solutions, those solutions are built on the premise that users wanted to sell their back office.

So, they had existing service that they wanted to monetize them. That was the API economy. And all those business premises were on that, where it’s actually — I feel like API management now is much, much more than that. It is all about managing internal services usage, external service usage, integration – it goes all over the place in terms of the actual market. You know, sometimes we have customers going to us for integration problems, which aren’t API Management problems.

We also get a lot of folks that are just moving vendors, but the main value proposition for us is, Tyk is small, lean, really efficient. I mean, we get benchmarked against NginX and OpenResty all the time. So, you know, latency matters a lot when it comes to high-volume APIs. So, all of those boxes are ticked. Being an open-source product, we’re not open core, we’re open source. It’s just a big distinction between those two things.


So, we spent a lot of time, effort and money on engineering team working on the open-source project, to make sure that it has all the features you need to get the job done. Most open-core products will just give you an empty shell and then sell you the bits you need. We don’t do that, we don’t hide the ball. That’s a big change for us, and I think one of the largest pieces for us is that when folks come to us we have a really unique way of engaging with customers. You know, James and I are from the agency world, and it’s slightly different in terms of how you handle your customers to have a normal B2B sales works.


And I think our customers see that, and it’s created this — we have this amazing reputation for customer support. We’re always rated best of the best in Forrester and Gartner every single time. Our customers are extremely satisfied with dealing with us as a company. We are extremely good handling our customers and handling our relationship. And that’s a great value proposition, because it means, once they meet us, they go, “Oh, this is a bit different.” And then they look at the product, and they go, “Oh, this product actually says what it does on the tin.” And that’s a big differentiator for us.

We were also – and this is slightly different aspect, but when we entered this market, one of the main things we did was say, when somebody wants to install a critical infrastructure, like an API Gateway, they do not want to worry about security concerns, that software phoning home, worrying about external access to it, or external access to those laws.


So, right from the back, our software does not phone home, our licensing system doesn’t check on whether your license is valid – it’s all cryptographically done. And that puts us at a bit of a risk. It puts us at risk to make sure that we are selling something that will not bring us any income revenue, but at the same time, it gives our customers that satisfaction that they can actually create their infrastructure behind the firewall, lock it in the cave somewhere, and it will still keep ticking over. And that’s really important, especially when you go into heavily-regulated markets like healthcare, banking, insurance, and things like that.

Because these organizations, they need to be able to file out their solutions, and make sure that they have full control. So, we kind of revived this on-premise business model, where everybody’s moving to SaaS, we said, “No, no, go on-prem.”, because a lot of organizations need this, especially B2Bs.

You know, for the smaller stuff, we see a lot of companies coming to us for our SaaS, and we were one of the first companies to offer a hybrid SaaS solution, so you could go into our cloud, you could run your traffic via our cloud or, you could run your gateway locally and localize your traffic, but have all of the management infrastructure, which is the more expensive part of the infrastructure sitting in our cloud. And that was a bit of a big deal at the time.

And we took that capability, and we made that into a product, and now that became our Enterprise product. We called it rather imaginatively multi-data center bridge. It doesn’t really roll out of the tongue, but that piece of software is our big, big ticket item. And it’s closed-source. But all it really does is it enables the user to manage their API ecosystem and their gateway fleets across multiple data centers, firewalls, regions, without having to worry about latency uptime of connectivity, they can fail independently, and they scale it independently, and that’s all built into a base platform.

So, it’s quite powerful. When you get out of the box, it’s super powerful. And then, if you add all value-add that we have, that’s closed-source on top of it, it’s worth the money.  So, when it comes to open source, a lot of people try to monetize open source through support, and that’s when it’s hard to scale. You know, when you scale support, you’re scaling the margin you have and your time.

So, your customer base gets bigger, and you’ll look at your own, let’s say, your customer base comes in, they join in, the organization, they’re trying to integrate your number of support calls and the usage of SLA peaks over let’s say maybe six weeks. So, they’re getting their money’s worth on what they pay for support.

But then, once everything’s working, and they got the hang of the product, that tails off again. And that’s great because, obviously, it frees you up to do more support work, but it also means that the value they’re getting out of it, goes down. And then, it becomes more of an insurance policy, and expensive insurance policy, which means, it’s one of the first things that gets caught, especially when your software works really well. You know, as you grow, you then hire more support engineers to help you make sure you can manage SLA.

But as that support tails off, where your business stops growing so quickly, those margins you’re making on someone’s time, just aren’t sustainable, and they scale really badly. Whereas selling a product, so selling a physical thing, you know, the old school put it in a box and sell it to the end-user – that has a huge margin, because you sell a thing, you’re dealing with unit economics. And that’s much, much easier business to run.


So, when we came to the open-source conclusion, we said, “Okay, so we’re going to hamstring ourselves by giving away a free product that’s incredibly powerful. And then, we’re going to have all these value-add products that sit on top of it that are geared towards the enterprise. But those will be closed-source. And that is what we will sell. But it’s worked for us, because the thing is the value-add stuff that large organizations want to pay for is the kind of stuff that gives them those insurance policies.

Most engineers don’t want user interfaces, they don’t want human intervention, but their managers do. That VP of marketing wants to be able to go in and look at a chart. And they need that full back control, where they can manually intervene, without having to worry about a DevOps pipeline, or something like that.

And then, there’s that piece, obviously analytics is a very big piece. And then, last but not least is simple things that all businesses want, single sign-on, role-based access control multi-tenancy. Those are the kind of things that large enterprises just salivate over. And if you can take that, bundle that into your enterprise value-proposition, that’s the bit you sell. And you’ll see actually, if you look at most open-source solutions these days, you’ll see that there’s an open-source product. And then all of those businessy things are the bits they sell for an extortion amount of money.

Is Tyk Open Core?

Mike Schwartz: Actually, I wanted to roll back a little bit to something that you said. You mentioned that you’re open source, you’re not open core, would you say that there’s a core product, or let’s say, that’s open source, and then, there are additional components which are commercially licensed – how does it work?

Martin Buhr: The bit that does all the heavy lifting is the gateway. It’s a proxy, traffic goes in, gets managed, traffic goes out the back end. And that’s where all the hard work happens. So, not only does it move the traffic, but also it applies things like rate limits, quotas, it gathers analytics, it might transform the request in some way, it might run some plug-in middleware – all kinds of transformational or validation elements that you need to do to your traffic. That’s where your authentication lives, where your authorization layers live.

That component is sort of the key bit, that’s what you want. That’s the thing that you want to put in front of you, into your DMZ, in front of your traffic to secure your services. That part is completely open source, and all of the components you need, all the features you need, to manage your traffic, is part of that component.

If I went out and I said, “Okay, I am large business A, and I want to spend no money on my traffic management, my API gateway and my API management.” I could do all of that, with our gateway. The only difference is, there’s no UI, you have to do it all programmatically, with our API, and with files, and all that kind of good standard, you know, unixy way. So, that’s fully functional. We don’t hobble our product at all. But then, we have the components that go on top of that that are the value-adds. So, there’s a separate service called our Tyk dashboard. That’s the management UI. It’s also the management API.

So, the dashboard is a single-page web app. It consumes the dashboard API, the dashboard API is much larger and granular, it’s multi-tenanted, you can have users, RBAC, and all of that good stuff. It also has a developer portal, which you can expose to let your developers that self-serve access to various services in the organization or even externally.

And so, that part, that whole application is closed-source, and that takes a license key. And that license key is essentially a cryptographically signed object, we use a private key to sign it, the public key is embedded in the binary, so all we need to do is validate the signature. If the signature is valid, we can trust the claims inside it, and that then says what you’re allowed to do with the dashboard.

And it has an expiry set, so we know that, let’s say, it’s a one-year license, and then the software will lock you out after one year because that’s expired.

Good thing about that is, it doesn’t need to call home, we don’t need to actually validate the license because all that stuff happens in the software in quite a safe way. It’s hard to break unless we lose our private key obviously. So, that’s one component, and then the second component that I talked about, this multi-data center bridge, also has a license with a separate key because it’s an add-on. So, you can kind of build out your ecosystem with Tyk. You can start with the gateway, which is open source. “Okay, this is great. I like this, but I actually want a UI, and I want all this cool RBAC functionality.”


So, you buy the dashboard, and you just tell the gateway to be managed by the dashboard. So, now, you extended out your installation. And now, I actually need gateways in six different locations or six different networks. Okay, I can’t do that with one dashboard because of latency problems, database problems and things like that, so I’ll buy the multi-data center bridge. It’s an add-on, you point the bridge at your dashboard, and you point your gateways at the bridge. And it then takes care of handling your fleet.

So, we basically license those components, and within the dashboard, there are feature flags, you know, for role-based access control, multi-tenancy, things like that, single sign-on. Those are feature flags we can switch on and off in the license, so we can start with a base license, and then build up on the pricing tiers from there. And we leave that up to – it’s not a software decision, that usually goes to the commercial team. They’ll sort of know what levers they see coming out of the interactions with potential customers and saying, “Okay, well, these are the things that people want. Let’s figure out how we can price those.”

So, there’s always this evolution in how we price our software, but that’s essentially how we manage it. It basically means that somebody could go along, they go to our dashboard installation, they run that for a year, and they’re like, “Okay, we can’t afford this anymore.” They don’t actually have to take away this out – they just simply have to take the configurations out, put them into the open-source system and take away the dashboard, and they can keep running. That’s the important bit.

Whereas with an open-core system, the core thing, doing all the work is hobbled. Because, if you no longer own the components that are doing the work, like your rate limiting, or managing open ID connect, or something like that, then actually, the whole thing is broken. So, you can’t continue, you have to shift.

Products

Mike Schwartz: So, of the pre-products that you mentioned, there’s the self-managed, the enterprise, and the SaaS. From a revenue perspective, which of those is the most important today?

Martin Buhr: At the moment, on-prem, the self-managed is the one with the best margin, because we don’t take on any of the costs of running the software. SaaS is a tricky business, you have to run it, you have to put a margin on top, and you scale accordingly. So, there’s quite a lot of cost of just getting everything running.

We’re about to launch the brand new version of our SaaS, which basically takes all of the stuff you get with the on-prem version, all the good stuff, like our plug-in capability and things like that, and makes it into a multi-region SaaS, so you can say, “Oh, I want to have my dashboards in…”, but that’s mainly on data sovereignty because we operate in Europe, and we operate in Australia and Singapore. You find these data sovereignty levels get more and more and more strict. And that’s why on-prem is really popular.

But the first thing that gets cut during recession is your DevOps team. So, the last thing you really want to do is manage people that manage software, so they all go for SaaS. But then, if your SaaS offering is enough to scratch, you lose them at that point. So, we’re building our SaaS to basically be just as competitive as our on-prem solution, and just as capable in terms of where you locate it, where you run it, and doing it all by a managed controller, to make that work. But essentially, to answer the question, yeah, the wholly-owned system is the one with the biggest margin, and the one we currently see the most interesting.

Sales Motion

Michael Schwartz: So, on your website, I didn’t see any particular vertical, marketing focus. Are the sales opportunities primarily inbound, like i.e people find the open source and then, they reach out to Tyk?

Martin Buhr: It’s a bit of a mix, mostly inbound, yes. People do reach out to us, we don’t necessarily have to go banging on doors, which is good. The way people find us are a few. Yeah, there’s google looking for the open-source software, trying that out. But actually, interesting, a lot of stuff that drives us is, whenever there is a comparison, we’re always in the mix these days with our largest competitors.

And Gartner and Forrester run reports on full lifecycle API management. And we were lucky enough, six months into launch of the company, to be featured in both. I think we were an honorary mention in the first Forrester because we didn’t quite have the revenue they needed for open source, but we did manage to get in there.

So, we’ve been on the radar for a while. Nowadays, it’s more about when people look for, you know, they’re looking to do a proof of concept or some kind of RFP that will hit us off just by default. And then, they reach out to us and say, “Tell us more about your software.”

You know, the other sort of big inbound market is – especially in Asia actually – is partner marketing. So, we have a whole bunch of integration partners out there since our business is mainly the use case for an API Management solution is ultimately an integration problem.

So, we have all these systems integrators that will look to us to provide a solution. And they might be more vertical focused. So, you’ll have NSI that’s healthcare, or you know, government, or things like that. And they’ll specialize in that sector for us. They’ll build on top of our platform.

Partner Development

Mike Schwartz: Did you actively recruit and identify the system integration partners, or did they find you?


Martin Buhr: We hired a really, really good sales guy in Singapore, and he knew how that market worked out there. So, he courted them initially, it was a bit of a mix of inbound and courtship, and usually what happens is, it’s a bit more opportunistic. The problem with legacy providers at the moment is they already have all these partner relationships set up, but they’re also extremely expensive. So, when it comes down to trying to cut costs or trying to streamline things like government spending, looking at the value, those solutions add, becomes problematic for most, especially if they’re closed-source. The open-source model always feels cheaper, so that tends to be a big driver as well.

I’m not saying that open source is cheaper, but open source is perceived as less costly because it doesn’t come with the overhead of training and a sales cycle that comes with it. Because you go and try and get a trial of a large enterprise piece of software, you have to go through three layers of account managers, sales peoples and technical representatives before you can get your hands on the software. And that’s bad accessibility can be a real problem, buying off the back of a data sheet.

Is It Worth It To Serve Smaller Customers?

Mike Schwartz: I’m gathering that enterprise customers are most important from a revenue standpoint, but have you found a way to serve small organizations, i.e through the SaaS? And is serving those smaller organizations actually like materials of the business? Is it worth the effort?


Martin Buhr: It’s definitely worth the effort. I mean, we started off as a community business, still are. The people that pay our bills are the large Enterprise customers. Those are the ones we really try and court, but those are six-month, twelve-month deals. You know, selling into the enterprise takes forever, not just from just getting in the door, but also just getting contract signed and making sure that the invoicing is correct, and going through all their procurement coops. So, that’s all well and good.

That’s the bit that sustains you, but at the end, it’s the smaller engineer, the side project, the hacker that drives interest, that pushes the platform a bit, that actually will probably contribute back. Especially in the open-source place world, and so we do. I mean, as our SaaS version is relatively less costly than the on-prem version, and we do obviously offer discounts for charities or small businesses and things like that.

So, we do have ways in to use the software without paying us a fortune. And we do sometimes say, “Here, you have the dashboard to be filtered free.” But most importantly, what I said is, “If you’re working with a smaller customer, is we can enable them through our community support or through discounting, to make sure that they get what they need.

We don’t actively go after those customers. Instead, actually, almost every single time, you engage in a sale, especially in our market, it’s an integration sale. There’s a lot of expertise required – they’ll have their own identity provider, they’ll have their own databases they want to use, they’ll have different service types that they want to use, they’ll have specific integration problems that they need to solve, and they need your help with.

You know, that’s the old fight of how good is your documentation versus how much help do you want to give on a personal level. In this case, that person’s time is really expensive, so we have to be very careful where we spend that time, but we do make sure that all of our engineers, for example, are on our community forum and are actively engaged in helping the community, make sure that they can do what they need to do and work with the software. We’re not exclusively focused on the enterprise, we just can’t spend a huge amount of time on customers that don’t sustain us.

We do ultimately have bills to pay, and developers got to eat. We have something like 74 people on staff now, in 22 different countries. And, well, it’s lovely to be able to offer an open-source piece of software to the community, and take the position that we will never hide the ball. And you know, it’ll be a fully functioning piece of software forever. The bits that are the value-add, we do need to charge for, and we just need to make sure we can keep the doors open.

One of the things I think that really puts a lot of people off of starting an open-source project is, there’s a lot of entitlement that comes with folks that use open-source software that they don’t quite understand. You know, the person building it is doing this out of love or, you know, because they enjoy it. It’s rare that an open-source project becomes a business. And once it becomes a business, your viewpoint has to change. So, it’s a sort of double-edged sword of how much do you put up with users that feel like you owe them something versus trying to run a business profitably.

Hybrid Cloud Pricing

Mike Schwartz: Hybrid cloud API proxies are hard to price. Some companies are pricing per transaction, but transaction value varies widely based on the line of business per server. And CPU models are tough because in the Cloud Native world with auto scaling, compute can be a moving target. I heard MuleSoft has a pricing model based on per container hour gig of RAM. So, I’m wondering, have you figured out what are the gates you’re using to figure out how do you price for this type of service in the enterprise space?

Martin Buhr: Hybrid’s tough because you’re not actually running the traffic either. So, if you’re telling a user, “Oh, no, you run all the infrastructure, and we’ll charge you for the traffic.” It’s problematic at best. So, what we do is, for us, when somebody comes along and says, “Okay, we want to use the hybrid.”, they are basically using — you have to remember that everybody that uses our software, no matter the large enterprise to the smallest user are all using the same open-source gateway.

So, if you use our hybrid offering, you’re actually using our open-source gateway in the configuration, so it works with our hybrid cloud. So, the nice thing is, we can basically say, “Look, here’s the container, it’s public, do what you want with it. Just make sure you configure it this way. And the way we price is pretty straightforward – you basically pay us for your account. It’s a monthly subscription, and that subscription comes with data retention limits. So, that’s the most expensive part.

We don’t run any of the traffic. The traffic is going through hybrid gateway, so we are just collecting and storing and processing analytics, and that IS expensive.

So, we say, okay, so per gig, per — we actually do it by number of days we store it for. You know, you get seven days, or 30 days, or 100 days, plus the additional features in the dashboard because all the value-add stuff, so single sign-on, role-based access control – all that stuff that lives in the cloud bit, whereas the hybrid gateway itself is fully featured, so they just simply need to configure it.

So, actually the way we offer is just a subscription model, where we don’t charge by scale. If they want to run 100 gateways, that’s absolutely fine. I mean, admittedly it’s a bit of a surprise to us when people do it, but we have had it before where we had one Malaysian customer who was — they were a huge ecommerce provider out there. So, big sort of eshop, mobile shop. And they were running millions of requests today, through our hybrid infrastructure. And they must have had 100 or 150 gateways spun up in their architecture. I think they were using mesosphere.

Yeah, it just sort of, it stood up, as long as we didn’t have to store it, it was okay. So, for our hybrid instead, we’ve actually parceled it as part of our overall SaaS solution. So, if you pay our cloud price, we throw hybrid in, just as part of it, because it’s meant to be a flexible proposition – it shouldn’t be either/or.

Self-Hosted Pricing

Mike Schwartz: I see, what about on the self-managed piece, how do you price that?

Martin Buhr: Well, if it scales according to how many gateways the dashboard has to manage. So, you could for example, have 10 gateways running open source – fine, no problem. But as soon as you introduce the dashboard, we limit that down to how many things can actually connect to it. So, customers come to us and say, “Okay, I have this much traffic, I have this kind of size of server, these are my requirements for a high availability and failover.” And we can then put a package together for them saying, “Okay, well, you need two gateways, or you need five gateways, or you need ten gateways to manage that.” And then the license is built accordingly.

So, they then install the license, and it allows ten gateways to connect. If you try to add an eleventh, the one that rejects the connection, that gateway doesn’t boot basically.

What Is Tyk Doing To Grow The Community?

Mike Schwartz: It sounded, like you were saying, that you actually had good community interactions on the support forums. Are you planning to foster growth of the open-source community and ecosystem, and how are you planning to do that?

Martin Buhr: Yeah, we just hired a full-blown community manager – I think he came to us from Mozilla to help us build out our open-source offering. So, it’s one of those things that gets neglected as you get bigger. You kind of go, “We’re making money, uuu, let’s focus on that.” And then, you sort of forget about all these free users that are sitting there, giving you all this free feedback on what your product needs.

So, we do a couple of things. One, we have an open-source community forum, and all of our engineers are on there, all of our consulting engineers, so these are kind of like post-sales technical architects are on there, plus our support managers are on there to make sure that there is coverage. So, you do actually get access to the staff, it’s not just the community helping itself. So, we do actively do that. It’s obviously a bit slower than our SLA approach, but, nonetheless, it is there.

And then, as a sort of a community manager is focusing quite heavily on what we can do better in Github, managing tickets, managing visibility of the roadmap, managing pull requests, and also in general, figuring out how we can shift from being an open-source project that we mainly drive to becoming more of a platform that people can build on top of.

We are currently investigating ways of doing that to make that really work, because as I said, you know, systems integrators and partners, they will have large companies like Accenture or Tata Consulting, or Capgemini, you know, they do have industry vertical professionals. And those guys will go in there with the product that they’ve got internally around HIPAA compliance or HR compliance, or open banking, or whatever. And they’ll want to build products around that.

So, the more customizable your solution is, to handle an industry, handle a vertical, the better, because they can build products out of your platform, and both people win. You win because you sell a license, they win because they’ve now cornered a vertical with this particular solution that happens to be based on yours. So, that’s sort of where I’d like to see it go.

And we’ve seen it here and there, you know, it’s hard to track them because as I said, we don’t call home, so we don’t actually know where any of these open-source gateways are running. But when they do pop up, you do find some really interesting stuff.


We had a customer in Thailand that said, “Okay.”, that the guys they brought it into the company, they eventually left, and they started their own thing. And they just recently shared with us like, “Oh, look, we’ve done all this extra work, and now it integrates with this, and we have all these plugins.” And they’re literally running a business off of that. And I love to see that, it’s amazing. They’re doing this all open-source work, and we’ve seen a couple of integrators, partners, individual open-source contributors, just taking the product a little bit further. And that’s wonderful to see. So, I actually like to see more of that and have more visibility of it.

As we said, we don’t at the moment, because we don’t really force it to call home, so we can’t really just sort of poke a user and say, “What are you doing?”

Open Source Ecosystem Duplicating Enterprise Features?

Mike Schwartz: How would you feel if somebody took the open source, or some company took the open source and built a sort of platform around it, and there was some overlap, maybe with some of the features that you were offering? Would you see that as a positive or negative for the company?


Martin Buhr: It depends. If they’re taking business away from us. It’s a positive most of the time because they’re doing something with it that we can’t do. If they’re doing full-blown overlap, like they’re taking our dashboard and copying it and adding services on top, and then saying, “Okay, this is a cheaper version of the version you can get from the vendor.” I would be a little bit irritated because it’d be reverse engineering, some APIs we’ve got. BUT, it is the price you pay for being an open-source market, for being an open-source product. It is part of the risk.

You see a lot of people moving into the business source license, and we considered that for a while to think, “Okay, well how do we stop people trying to edge into our market.” And at the moment, it’s not so serious. I mean, if you were a database, like Mongo or Redis, it’s a much bigger problem because your footprint is much bigger, in terms of usage. And it’s this whole thing, it’s sort of API theft, or Driver theft.

And you can see it in some businesses as well that they are API based, where, all of a sudden, they’ll go, “Oh, we support the Uber API for our car service.”, which means, you can just point at a different endpoint, and your SDKs will continue to work, or all your integrations will continue to work. Or, you can just drop in a new driver, you can use the same Redis driver to connect to ElasticCache as you can to run fast. That’s just mean.

It’s really taking advantage of interfaces, and I think it’s part of the open-source problem, it’s a real issue if you become very successful in open source. You know, you become a kind of standard, I mean, we don’t have that yet. I would love that, but we don’t have it yet. But, it’s like MySQL, or Redis is a great example, they have this wire protocol, if somebody wants to launch a competing product, they just need to implement this wire protocol because it’s open source. And all of a sudden, they can say, “Oh, no, we’re driver compatible.”

Cockroach Labs, for example, is driver compatible with Postgres, let’s interface that.” It’s just a way of acquiring users through somebody else’s hard work, which is — it’s a risk, it’s a real, real risk. And that’s why things like the business source license exist. But I think the only time you need to look at something like that is when you do actually have people building out large-scale, high-visibility platforms that are competing with yours.

Most of the time, there should be enough space in the market for you both to coexist, so it’s a bit tricky. There is no answer I think. I’m not sure if that answers your question.

Advice For Startups

Mike Schwartz: So, last question. Any advice for entrepreneurs who are launching a business around an open-source product?

Martin Buhr: The first thing is, try and figure out what are the bits that are valuable in your product, because that’s the thing you’re going to need to protect and monetize. A great example actually is the Caddy Project, a really, really good web server with some really strange monetization options. And they changed their tune several times, from enabling access to a built server, to removing headers, to doing all kinds of stuff with their proprietary version. And it’s because the entire product was open source.

What you need to kind of figure out, if you look at like Kibana or even NginX, you kind of want to say, “Well, if you’re going to try and monetize an open-source project, you can’t monetize the actual open-source piece because that’s always going to be free and open, and you don’t really want to be hobbling your own open-source software.

So, you have two choices: you have the choice of either forking and creating a second branch that has all the value-add stuff that you want to sell, or going open core, where you then sell the plugins and things like that. Or maybe go like us, where you say, “We have an open-source offering, we’re going to continue providing that, it’s fully functional.” But, if you’re a big business, you’re going to want all this extra stuff. That’s the stuff that’s instead of baking it into the core, we’ve created different separate services for it, and we charged for those. That makes it more sustainable.

The other thing is, I guess, if you’re starting an open-source business, you need to really figure out who you want to sell to, because mass market is hard. If you’re looking at investment, mass market is great. So, if you’ve got something that’s got really high penetration – a good example might be, like Postman or Visual Studio Code, that gets a lot of adoption, it gets a lot of adoptions. It means you have access to millions of users. And that’s really valuable because you can eventually monetize that and mine it for that 10-20% that’ll actually pay you some money.

When you’re going mass market, you have to go for as much penetration as possible. If you’re going B2B, and you want to go into the enterprise layer, and you want to start charging those big bucks, you need to really start thinking about your sales process. I think most startups, when they get into the B2B industry, even if it’s open source or not, selling to a business is hard, it takes forever. If you don’t have the experience of working in that environment and dealing with the red tape, the context, the process, and the flow, you’re going to have a really hard time to break it.

So, that’s the second thing, it’s probably easier for an open-source product to go from mass appeal rather than B2B, but B2B is where all the money is. With the mass appeal product, if you’re going to say, “Okay, I’ve got a new code editor, or a driver, or a really cool data stitching API or whatever, if you get a lot of users for that, that’s great, but you’ll need to monetize them down the line.

And one, that means you have to alienate your community, two, it means that actually your value will be in that network, which means you’re going to be trying to sell on that network. And open-source business is that we are relying on a network need funding. So, eventually, you’re going to have to get funding in order to monetize the network, in order to get to a point, where you’re profitable.

At Tyk, we were really, really lucky because we managed to build the business really organically from the start. We started with zero employees, then one, then two, then three, then seven, and that was off of the back of a little bit of Angel money and actual real deals. We were making cash, and we were in the black. And then we grew slowly.

We only took funding last year, but that was so that we could go aggressively into the American market and open an office there because that costs a fortune. You know, you can’t build that organically. So, you kind of need to really figure out where you want to go with your project if you’re going with open source. That’s a lot of weird advice, I guess.

Mike Schwartz: That’s great. Martin, thank you so much for spending all the time with us today, and congratulations, and best of luck.

Martin Buhr: Thanks, Mike.

Mike Schwartz: And thanks to the whole Tyk team for collaborating on this podcast. Editing by Ines Cetenji. Transcription by Marina Andjelkovic. Cool graphics from Kamal Bhattacharjee. Music from Broke For Free, Chris Zabriskie and Lee Rosevere.

Don’t forget to follow us on Twitter. The handle is @fosspodcast. You can also follow me personally on LinkedIn. I always post a link to the episodes, and you can share it from there too. Next episode we have Kathryn Erickson from DataStax, one of the leaders in the Cassandra ecosystem. Hope you enjoyed this episode. Until next time, thanks for listening.

Episode 48: Zero Trust Security and Packaging with Ev Kontsevoy, CEO of Gravitational

Intro


Michael Schwartz: Hello and welcome to Open Source Underdogs. I’m your host Mike Schwartz, and this is episode 48 with Ev Kontsevoy, CEO of Gravitational.
This episode, it’s a little longer than most, clocking in closer to 45 minutes. That’s definitely because Ev has such a broad breadth of technical and business experience, we probably could have gone on another hour.
If you want to hear a little bit more about the tech stack, watch The FLOSS Weekly, episode 529. I’ll put in a link on the episode website.
Gravitational has two very interesting products, and they are somewhat related but also a little different. It must have been a tough marketing challenge to come up with a unified message, but apparently they did it, because the company’s been super successful by all measures.

So, without further ado, let’s cut to the tape. And after you listened to this podcast, I’m sure you’ll want to check out Gravitational’s website for more info.

Ev, thank you so much for joining today.

Ev Kontsevoy: Thank you for having me, Mike.

Story Of Mailgun

Michael Schwartz: Before we talk about Gravitational, can you talk a little bit about your previous startup called Mailgun and your experience at Rackspace, and how that led you to identify the business opportunity for a Gravitational?

Ev Kontsevoy: Mailgun was interesting, and for those who don’t know, Mailgun is an API platform to send and receive emails programmatically, so it’s email for developers. If you need to send a password recovery email, or if you need to send newsletters to your customers, you just use Mailgun API to send those messages and collect responses.

That company was interesting to me because of two things. First, it was founded in the middle of financial collapse. I moved to New York City around 2009, right when the economy was self-collapsing, I guess. And it’s also when AWS was beginning to happen, which is always interesting, like, which means that when everything is crushing around you, there is always some positives. And I thought, well, if Jeff Bezos can sell APIs to servers, I could probably sell APIs to emails.

And the reason for that is that if you’re moving to the cloud, you cannot really take your things with you, so whatever email delivery appliance you used to have, like you need to have a virtual replacement for it, that’s how Mailgun really got started. It was really tough, raising money back then for a project like this, because most investors didn’t understand what an API was. I would do a presentation, and then an investor will pull out a Blackberry. And he said, “All right. So, I got my Blackberry here out, so how do I use you API?” At that moment, you know that you lost, that this is not going anywhere.

But then, an interesting thing happened. A Twilio got funded. And everyone paid attention because Twilio said, “Oh, we are API for developers to do, like, SMS.” They started saying that Mailgun is simply a Twilio, like Twilio, but for email. And it helped tremendously.

So, we got accepted into Y Combinator, in 2011 actually, and went from there. I ran the company for a couple of years and eventually got acquired by Rackspace, by one of the cloud providers.
So, the interesting thing I learned from that experience – well, it was my first company, so you’ll obviously learn a ton if you do that – but as a technologist, I wasn’t prepared to be exposed to so much…let’s just say crime. That’s what it is really. Because email is a really dark world, so many shady things happen via email. You know, fishing, and viruses, and spam, and I would say that 80% of my attention was consumed by those problems, as we were running that company, which is unfortunate, because you actually want your real users, engineers, developers to enjoy, the product, you want their experience to be great, you want performance to be great, you want documentation to be amazing. And you constantly have to deal with spammers, fishers, and all parts of bad, bad internet.

So, that was my Mailgun experience. And the reason we, I guess, decided to sell that company to Rackspace, is because Rackspace at the time had very compelling vision, for using open source and open standards to free the world from AWS dominance.That was kind of resonating with me because I started my career as a software developer during Windows dominance. And I just remember how boring and bleak everything felt, just operating within constraints of what Microsoft thinks you should be doing. And, yeah, so that was the story of Mailgun.

Technical Origins Of Gravitational

Michael Schwartz: You know, it’s a totally different answer than I was expecting.

Ev Kontsevoy: What did you expect?

Michael Schwartz: I was listening to another episode, or another interview with you, and you spoke for some time about some of the interesting technical challenges around how complex Mailgun was, and how you were considering replicating it on a different cloud, and how completely, like just, it seemed like such a big challenge. And I was wondering if that sort of gave you some technical ideas that might have led to the development of the Gravitational, like, technology stack?

Ev Kontsevoy: Oh, so, that’s more interesting question – how did I go from being an email person to effectively ending up almost in the security space. So, what do you think happens right after an acquisition, when one technical company acquires another technical company? It happened with us, and maybe, like, when Facebook acquired Instagram, there was probably something similar there, the first thing they ask you to do is, start planning to migrate all your stuff into their own infrastructure.

Especially for Rackspace. Rackspace’s a cloud provider. It would be really strange for them to have an email service that’s not using their own cloud. And at the time, we were using SoftLayer, which is now part of IBM – old-school, bare-metal servers, and migrating to a public cloud on Rackspace, which was virtualized and had all these fancy infrastructures as code capabilities. It took us a long time, I don’t remember exactly how long it took, but let’s just say if I say 6 months, it’s not going to be an exaggeration.

And I remember having a conversation with someone in my family, maybe it was even my wife, where someone asked me like, “So, what are you doing – like, now, post-acquisition – like what are you building?” And I said, “We’re not building anything, we’re just moving from SoftLayer data center to Rackspace data center.” And that person wasn’t technical, and she said, “Isn’t that, like, copying files over the internet??” “Why is it taking six months?” Like, “You have that many files??”

And I laughed. But at the same time, it was kind of illuminating. Like, normal people think that copying software from one data center to another, it’s something that happens within few seconds.
Wouldn’t you probably feel the same, like, what is software, is it just some files, you have software on your laptop, I have software on my laptop, like, it’s just copying things around, but apparently, when it comes to data center software, to what we call cloud software today, everything takes months.

And, at the time, I just kind of took this for granted, like you’re sure it’s a complex problem.
We have completely different security here, we’re going to have that over there, over here we are using this kind of load balancing, over there is going to be different kind of load balancing, and the code needs to be updated, and so on and so forth.

But then, when I became a “racker” – that’s how Rackspace employees called themselves, I was a proud Racker by the way, I love that culture – so, once I became a racker, I got exposed to vast representation of cloud users out there, companies who use cloud computing. And I was talking to them usually trying to understand how can we improve, how we can make our cloud offering better.

And I was amazed how frequently they will bring this problem that I had with Mailgun. It’s like, “Hey, we’ve built this application, and it’s running on AWS, and now we’re trying to run it on Rackspace, and it’s really challenging. Can you help us?”

Or they would say, “We want to use Rackspace, or AWS, or Azure, some kind of cloud provider to build applications, the development environment, but for whatever reason, we need to actually run it in Luxembourg, like in the data center that is supposedly compliant with whatever regulations there are under.

So, how do we have staging environment in one place and identical production in a completely different place? And they kept coming to us looking for advice. And sometimes, we would be able to sell them something, you know, like DevOps as a service, or security as a service. But generally, I just saw this trend is that people feel like they’re chained to their cloud environment.
It doesn’t even matter how amazing that environment is.

But not being able to just take your production and have like, I don’t know, a hundred copies of it running all over the world – it’s extremely frustrating. And it’s limiting to a lot of use cases. You know, latency is important. Because the laws of physics, they don’t really change. So, you have to be able to run your code, close to where your data sets are. Data sets are distributed, which means that code needs to be distributed.

And that’s what I became deeply dissatisfied with SaaS model, in general. I don’t think there is anything wrong with Software-as-a-Service, but there is definitely something wrong with software-as-a-service running in a single place.

And as I was talking to more and more companies, I realized that some of them – check this out – they can’t even recreate their production environment in a different Amazon account. Those are companies based in Silicon Valley by the way.

So, let me just kind of zoom into this use case: you have an application running in an AWS account that you have – you control that. Go ahead and create another AWS account from scratch, also yours, so you have full, you know, God permissions for both accounts. And then, have a full replica of what you have in one account and another. And a surprising amount of companies don’t know how to do that.

They just overtime kind of lose institutional knowledge of what would it take to recreate everything from scratch. And as an engineer, you probably understand why that is happening, because you know, when you start building your application, like in the early days, not a single line of code is written, but you’d know that you need some environment.

You’re going to go and click some buttons in that AWS panel, maybe you’ll write some terraform, or cloud formation, but not always, maybe use Ansible, so, you kind of start manually creating first layer of your future environment. Then you start adding things on top, then you start deploying your code, maybe manually at first, maybe SCP. And then, you move to something, I don’t know, maybe like Ansible, or Chef, or Puppet.

So, things happen over time, and not everything is documented. Some scripts, they run daily, maybe they are part of your CICD pipeline. Other scripts you ran three years ago, and maybe the person who did it is no longer with the company. So, the point is, almost any cloud environment today, it’s built with many layers that are created over time by different people.

And that’s the reason why they’re not reproducible. And a company needs to have, you know, we need to have seven regions all over the world instead of one. Or we need to run our software inside of someone else’s AWS account. Or we need to deploy into GovCloud because government wants to use our software. They run into all these issues that they’re chained to one specific environment. And that’s why Gravitational was born. That’s the company that a bunch of ex Mailgunners started. So, that’s maybe a different answer to your original question.

Products

Michael Schwartz: So, let me drill down a little bit more, Gravitational has two products, Teleport and Gravity. Which was the first product? Or were they both coming at the same time?

Ev Kontsevoy: It’s basically a packaging question. We initially built a solution, so if you want to run your software in many different places, you have to solve many different issues for that. You need to separate your application dependencies from infrastructure. You need to solve remote access problem, you need to solve compliance problem – because a lot of these companies, like the reason they needed to be in the different place is because of compliance requirements.

And we had – what I would just call a code base, a bunch of GitHub repositories. We have this culture internally that we create GitHub repository per library. So, we break everything we built into these libraries. Each library has its own repository, and then we compile the software, and then, we produce solution.

So, originally, everything we built was just a collection of these repositories. And we started to sell the solution called Gravity, and Gravity includes everything we do. Gravity is a complete platform. With Gravity, you can take your AWS account – technically, it’s a Kubernetes cluster, but let’s put that aside for now – and you could save it all into a single file. That’s your image, we call it “cluster image”.

Think about like doing a snapshot – it’s not a snapshot, but I think it’s a helpful analogy – and then you can move that file somewhere else, and you can create exact replica. So, you take this image that contains the full copy of your production environment, and you can copy/paste it all over the world, and you can have thousands of identical environments created from that image.

So, the question then becomes, how do you keep them up-to-date, how do you push software updates, how do you fix the vulnerabilities, how do you troubleshoot problems that happen remotely. So, you do need to have some kind of remote access to those environments. Interesting analogy that I like is software updates built into operating systems.

If you have a Mac, it somehow updates itself, it downloads things from Apple, it applies these updates at reboots, and all of this kind of is just working automatically. So, think about it, from Apple’s perspective, how is that different from running a massive software deployment to hundreds of millions of servers running on untrusted network all over the world, with unreliable internet connectivity. For a typical data center person, that is a Star Wars level tech. And that is what Gravity tries to do with data centers, with your cloud account.

And this component that allows you to securely download and apply updates, that is what Teleport is. It is basically a part of Gravity that enables this world-class security into this restricted, regulated, remote environments, where Gravity is usually running.

And at some point, we thought, why don’t we make open source available for people to use as their own software update mechanism in their own kind of applications. And we open-source that, we put documentation in a separate place. And what we discovered very quickly is that people realize that it’s a much better way to do SSH than open SSH oftentimes is. Which was completely unintentional, but it was kind of nice for us because suddenly people started to discover Teleport, and download, and use it more. And basically, it’s a really good way to access infrastructure right now.

So, whatever you’re using to SSH into your servers, or to access your Kubernetes cluster, you’re probably using something worse, so I highly encourage everyone to check Teleport out. It’s free, open-source, Apache license. So, that’s how it happened – everything was built at the same time, but Teleport, just by accident, developed its own fan base, so to speak.

Revenues By Product

Michael Schwartz: In terms of revenues, which product is more important?

Ev Kontsevoy: It’s hard to say. I think both of them are doing really well, and Teleport is definitely not as expensive as Gravity is because it’s not as foundational to company’s business. Because we have Gravity customers who basically run massive, they sell a lot of software into these remote locations and deliver it with Gravity. So, Teleport, it’s usually part of a platform, it’s not the whole platform. So, it’s cheaper per deal, but we do close a lot more Teleport deals.

Marketing Message

Michael Schwartz: Have there been some challenges around finding the right marketing message for this platform?

Ev Kontsevoy: Absolutely, absolutely. I do think we’re still searching for the right way to describe what we do to the world. There are people out there who believe that Gravitational is a company that helps you take your SaaS application and sell it as a kind of on-premise environment. And it’s fine. Yes, we can do that, and we can do it better than anyone else.

But to me, that’s not really the reason why I decided to spend significant, you know, invest a portion of my life into this company. We want to enable a completely different software distribution model. Think about it like push versus pull.

We believe that the reliance of DevOps team needs to be reduced. The fact that most companies today have to set up and maintain these complex environments, with so many moving parts, and have these massive DevOps teams that constantly struggle with this ever-increasing complexity of this environment – it just feels temporary to me. It’s got to be simpler.

The typical DevOps picture at a company, like average company today, reminds me of what you would read in a history book about early computing.

Remember those stories about old electromechanical computers that would take up the whole room in the building, and you had cockroaches and bugs crawling in, and you had special people called debuggers kicking them out with broomsticks and replacing vacuum tubes and relays, computing was like a manual job, you had to have people walk around and constantly do that.

That reminds me a little bit about like a typical cloud environment today. I think it should be sealed, fully automated with zero human presence. So, if you walk into a data center today, you’re actually not going to see that many people, probably you’re not going to see anybody at all. There’s going to be some security at the entrance, but inside, it’s going to be quiet, no people.

So, I want that to be true for virtual access as well. Even though there are no physical people in that data center, but you could be assured that there are probably hundreds, if not thousands of DevOps engineers, maintaining those machines basically manually. And the purpose of like the goal for Gravitational is to make it not so. We want this all to be completely automated, similar to how millions of Apple laptops download software from Apple, apply patches, and keep running. I see no reason why a typical cloud environment for a typical company should be very different from a MacBook.

Value Prop

Michael Schwartz: How do you convert that into like business peak? You know, because it’s sort of, like, what you’re saying is almost like a kind of “sale to the guy with the hands on the keyboard”. Is there a way to convert that into like actual value proposition for the business customers?

Ev Kontsevoy: Well, first of all, let’s be honest with ourselves – can we do this today? Let’s just take a random company that have nothing to do with, let’s say –

Michael Schwartz: – eBay.

Ev Kontsevoy:  eBay. Can they make all of eBay run similar to a MacBook, with no DevOps team or server today? No, I can’t. There’s so many problems. Like, it’s a complex challenge. So, it’s going to take us many years to actually solve all of these challenges. But what you can do, you can start looking into where DevOps teams are overloaded today and start pushing that needle.

So, for example, if you try to run the same application, let’s say in a hundred different places, you will quickly realize that secure access is a huge problem. Because all these different cloud environments, they have their own tools for accessing infrastructure. And then, you have this like open-source ecosystem that all these components need to be integrated and everything used to be secure. And it begins with SSH, and it ends with Kubernetes access, and then you have, like, internal things, like Jenkins, maybe how do you secure access to Jenkins – all of these problems, they become extremely complex if you try to run more than one production environment.

So,okay, now we have a security problem, we have this access problem – that’s what Teleport solves. So, maybe I cannot promise you that your DevOps team will have nothing to do, but I can promise you that your secure access will be taken care of. You no longer need to have a competent team of infrastructure security people.

Or, if you have one, from now on, they can focus on other things, we will take your security problem away. And it doesn’t matter if you have a single cloud environment or 56,000. So, think about any like retail business, like McDonald’s or Taco Bell, they have tens of thousands of restaurants all over the world, each of those is actually a small data center. They have computers in the back, but can you dream about updating software and those locations, using like regular open SSH and let’s say Ansible? That would be quite, let’s say, inconvenient.

So, here’s the problem that we already solved for them. I do think that our strategy will be to just declare that going from 0, which is where we are today into this bright future, where all software runs by itself magically everywhere, we need to solve 57 problems.

Alright. So, let’s outline what those problems are. I think it actually helps because maybe some other startups will help us. Maybe they will solve disaster recovery or backup problems, but we will concentrate on security first. So, that’s how Gravitational is executing today.

Both Teleport and Gravity, they are very much security and compliance oriented. Because, if you want your code to run globally, you have to take care of that first as basically problem zero. That’s why we focus on it for now.

Free V. Commercial Offering

Michael Schwartz: So, a lot of open-source companies, they open-source a funnel for customers who might want to engage commercially. What does the sales motion look like at Gravitational? Is it try by fly, and what’s the effort to bring on these large customer accounts who probably pay the bills?

Ev Kontsevoy: Look, I’m going to be honest with you. We don’t really have a clearly defined strategy that’s documented for example internally, like how do we upsell open-source users. We simply try to — I think we have a following approach, we want to make sure that if you are an individual, like a developer who is curious about where technology is going, someone who has a home lab in their apartment, or a couple of Raspberry Pi’s that they’re running a little toys on – we want to have something for you.

We want you to get access to Gravitational vision, we want you to find our projects interesting. So, we’re going to have something for you. Yes, it’s going to be free, yes it’s going to be open source. We’re not going to sell you anything because you don’t really have problems that we solve at commercial level.
So, then if you are a small team, let’s say about three, two, 20 people, and you are working on some young project, let’s say your startup, we want to have something for you as well.

Then finally, if you’re a large enterprise, let’s say you’re IBM, and you have some problem, we are going to have something for you as well. Every time, we look at the capability that we are introducing into one of our products, we will always have one of those three use cases in mind, simply the size of the team. One-person small team, and then giant team. And it just so happens naturally that things that giant teams want, they are willing to pay for them.

And things that hobbyist would want, I think trying to charge money for it – it is just ridiculous. At least for us. And that’s how we naturally end up in the split, what is a commercial offering and what is free and open-source offering.

Is Gravitational Open Core?

Michael Schwartz: Would you say that Gravitational is open core?

Ev Kontsevoy: I would say no, we are open source, like we are open-product company. Everything we make is open source. We have a tiny bit of proprietary magic dust that we apply to our open-source products, but that dust just happens to be critical for large companies. In other words – let’s talk about a simple use case – you want your engineers to SSH into their machines, in the most convenient way possible. You don’t want to like annoy anybody with additional stuff.

But you also want this to work across all kinds of cloud environments, you want this to work with, you know, IoT devices out there in the field, you want this to be compliant with all these different regulations that your customers want you to be compliant with.

You basically want the best in-class security and compliance, but you don’t want developers to be inconvenience.

Okay, which means you have to use identity-based system. In other words, if a developer, who wants to access something, they need to go through some SSO process, once a day, nothing crazy.
And, usually, if you look at small teams, what do they use, everyone uses like Google Apps and maybe GitHub, which is naturally what are open-source products for. But if you look into what giant enterprises use, you will start discovering products you’ve never heard of. Like, I think SalePoint, and you obviously want Teleport to support those things. And that’s what we’re going to charge you for.

Another thing too is, if you are a giant enterprise, you are going to have all these different teams and different groups, you might have infrastructure developers, or like NetSec team, or you’re going to have like some auditors. So, in other words, the composition of your teams is complicated. And you need highly granular role-based access control.

So, this extra granularity that only large companies require, that’s another proprietary thing, like from our perspective. So, we basically try to attach – we try to draw the line between open source and enterprise offering, basically based on a company size. Because large companies, they need things that are not even obvious to startups.

SaaS Gravitational?

Michael Schwartz: A lot of open-source entrepreneurs, they love the SaaS business model. I’m sure you’ve kicked around some SaaS ideas. Is there a SaaS Gravitational offering, or are you thinking about one?

Ev Kontsevoy: It definitely makes sense. Yes, we do run into accounts every once in a while who simply say, like, “We love your tools, this is unbelievable, but believe it or not, we right now have zero engineers available to set everything up, to get up and running. “Can you just do it for us, can you run it for us?” And we listen, and we, let’s just say we’re considering it.

Pricing

Michael Schwartz: Most of the companies in this space are using a per-user metric for gating. I’m wondering if you’re using that strategy, has it worked for you, is it a good proxy for value and a good way to land and expand?

Ev Kontsevoy: I just told you what our internal motivation is, what we’re actually building – completely autonomous unmanned, operational model. So, it would be strange for us to charge you based per on number of users if we believe that software needs to run without humans standing around.

Difficulty here comes from the fact that we’re not there yet, so yes, you do need DevOps engineers SSHing into boxes every once in a while. But I believe, if we succeed over time, like the need for that will disappear. So, if we, for example, adopt a business model that we’re going to charge you based on how many SSH users are manually accessing servers, that pricing model will not be compatible with our long-term vision.

Even today, I would argue, without even Gravitational technology, if you have a well-running operations, but you are a Cloud environment, you should not be giving SSH access to your production environment, to all of your engineering team.

Ideally, very few people should be able to do that, and ideally, there should be no need. Especially if you’re running on a modern cloud, you can simply like kill things that misbehave and recreate them from scratch very quickly.

Michael Schwartz: So, what gates do you use?

Ev Kontsevoy: It’s based on your footprint. If you’re running large applications, you’re processing tons of data, you’re present in many data centers all over the world, you have tens of thousands of services based on that, we will charge you more for our solutions.

How To Gauge Deployment Size?

Michael Schwartz: In the Kubernetes world, servers are so ephemeral. You get a lot of servers when there’s a big demand and less servers when there’s less demand. It seems like all those per server, per CPU models are so challenged in the new Cloud Native world – how do you gauge the size of a deployment today?


Ev Kontsevoy: Well, I would argue that per server, per CPU, per RAM pricing, it’s not getting obsolete. If anything, it’s getting more and more popular with – like, look, AWS themselves. That’s what they charge you for. Yes, it is more challenging to accurately meter usage, but generally I would say that usage-based billing is the future for almost everything we use in a data center today.
So, for Teleport SSH access specifically, we look at how many servers we’re using. And for different companies, we offer different options there because there are different business models, and that’s the reason why we do custom quotes for every account.
For Gravity though, I do believe that the value we provide is based on how many environments you’re going to be running. Let’s say, if today, you have a single-production environment, then tomorrow, you’re going to be in a hundred production environment – it’s the environment. Like, the number of environments, that’s the value that we give you. So, then we’re going to charge you based on how many environments you have. We don’t really care about how many servers you have in each.
And environments, they rarely jump too quickly. So, it’s kind of slower moving targets. And that’s how our pricing is built on for Gravity site.

Does Open Source Help The Business?

Michael Schwartz: Has open-sourcing the software really materially helped the business?

Ev Kontsevoy: Absolutely. Because it’s the best form of marketing you can do in our market. We are all dreamers. I believe the technical founders and companies that are started by engineers, they almost always have this dream component attached to it.

And you want to find people who agree with you that future is going to look different, the future is going to be moving this direction and not that direction. And that person is probably also technical. And the best way to communicate with that person – and it has always been like this – is to show me the code, let me play with it. Because that’s how we collectively dream together, by downloading each other code, installing it, playing it, and then communicating, and sending each other pull requests and criticism. That’s just the best way for, I think, mankind just collaborate and move the progress forward.

And if you don’t do that, if you use proprietary kind of code in the cave mode, then you’re basically guessing. You’re saying, “Hey, I’m going to go and work on this problem for a year.”, and then I present you with the solution. If solution works for you, you’re going to buy it. And if solution doesn’t work for you, you’re just going to ignore me. And that’s just a much slower way, to get to this optimal state of offering something that the world truly needs.

So, it’s really hard for me to even think differently right now. You see, with Mailgun, it was different because the problem was so obvious. The problem was basically this: the world needs to send and receive email. And there are solutions for it already, and you have them in your data center.

And now, you’re going to go be in the cloud, so you cannot take your solutions with you. So, you need to have a cloud version of it. All right, sure, here’s one. But Gravitational is much more visionary company that we just want to change the way how cloud software runs. And if you’re going to start working on that problem, doing it in the open, it’s the only way I see how it could even be accomplished.

Portability Of Startup Experience?

Michael Schwartz: This is an unusual question that I haven’t asked before, but you sort of backed the question a little bit. You know, I’ve actually started more than one business – Gluu’s my fourth business – and one of the challenges I found in starting the second business was I applied a lot of the lessons from the first business to the second business. And it turned out that the second business was so completely different that actually like I shouldn’t have.

And I’m wondering, are there any cases where – I mean, certainly you learned a lot in the first business, that helps – but was there any like things that you feel like maybe the first experience led you to something to take longer to figure out?

Ev Kontsevoy: Actually, the Gravitational in many ways is anti-Mailgun. So, Mailgun was proprietary code-based SaaS. Gravitational is open-source software that you can download and run. So, from the beginning we knew that our ability to borrow from Mailgun experience is going to be limited.

So, that allowed us to bypass a lot of these potential problems that you’re referring to. However, what was helpful and applicable is just the mechanics of starting and running the company. You know, raising money, incorporating, setting up like basic processes. So, a lot of that you could just fly without even thinking and do exact same things, simply because a lot of early-stage startups are surprisingly similar. So, copy/pasting that experience into your present, I think it’s totally applicable.

Why Leverage An Incubator For A Second Company?

Michael Schwartz: You chose to go to Y Combinator and raise seed funding and go a pretty traditional startup route. But you didn’t have to go that way, you could have probably bootstrapped it. I’m wondering, why did you think going the traditional route made sense, given that you probably had some capital and some experience and maybe could have done without it?

Ev Kontsevoy: Because it worked previous time. You see, I’m a technologist, I’m not a professional entrepreneur. Like, incorporating, raising money, doing all these things – it’s boring stuff. So, it worked wonderfully for us at MailGun, going through this traditional sequence, through Y Combinator seed stage, and so on and so forth. We just did the exact same thing, we would concentrate and spend my time on actually building interesting products and solving problems, because that’s really the reason you’re doing it. Everything else feels almost like distraction.

Yes, you have to do these things, but at the end of the day, they’re not differentiating, they’re not going to define if you’re going to be successful or not – it’s simply getting resources, and office space, and processes, and 401k plan, whatever, just getting it done as soon as possible and moving forward – that was the goal. And look, Y Combinator, they’re very incredibly efficient at getting all of their startups through this early stage, so I highly recommend it.

Team

Michael Schwartz: So, you’re currently in the Bay Area, are you planning to recruit most of the team in the Bay Area? Maybe you’ve already, like, diversified quite a bit – what are your thoughts about building the team in the next couple of years?

Ev Kontsevoy: If you’re asking me, like, what I recommend – I don’t recommend anything. I think it always depends on founders and company culture. There is always this popular question, like, “Shall I go 100% remote, or should I have an office?” I don’t know the answer to that question, there are pros and cons, but what we’ve decided to do is that we want – there are smart people all over the world –we don’t want to discriminate based on either they are in Bay area or not. We want them to be involved, we want them to join the company. And we quickly realized that Seattle actually is the capital of cloud computing of the world. It’s not Bay area.

If you want to recruit engineers who understand what kernel variables are, who understand differences between file systems, who can troubleshoot lost packets in the network, you will have a much better time finding that talent in Seattle because every single public cloud provider is there. You know, Azure, AWS, GCP, it’s all sale companies, even smaller clouds, like former CenturyLink Cloud, in the Oracle Cloud, original team was based there.

So, Seattle, it’s the highest concentration of cloud computing experts. And for that reason, our engineering is actually based in Seattle, even though the company is headquartered in Oakland Bay Area. But we’re also open to hiring people all over the world. We have a small office in Toronto, we have remote people on the east coast, and Germany and Italy. So, we’re constantly evolving in our views on what kind of culture we want to have. It is challenging, it’s not easy.

How To Scale Beyond Startup Phase?

Michael Schwartz: So, you’re in an interesting stage in the company’s development, where you’ve had quite a bit of success, and you’re sort of scaling to the next level. Any advice for entrepreneurs who find themselves in that situation, in terms of, like, how to adjust to this new sort of focus on sales and marketing, especially for technical founders.

Ev Kontsevoy: You just gave them advice – do not ignore sales and marketing. Think seriously about sales and marketing. Something that I learned in my journey, going from engineer to entrepreneur, was that building a sales team, building a marketing team, is absolutely similar to building a product.

So, just like you have an engineering team with your processes, you know, for example, no one can commit to master directly, you have to do your own branch, and a pull request with a code review. And all good engineering teams, they have processes, and then the coding style, and like which programming languages we allow, which ones we do not allow – building this takes experience, building this takes a lot of brains, and doing it well requires a lot of energy and discipline. It’s really tough. So, this is why top technologists are so expensive. And that is absolutely true to yourselves and marketing teams.

Doing marketing and having a marketing machine that’s operating properly also takes a lot of brains. No, it’s not obvious, no, you can’t just read a couple of Golden Books and go do it yourself. And then, the same thing with sales.

So, underestimating the effort and sophistication of sales and marketing activities I think is quite common amongst engineers. So, simply building and expecting that the users will come – it rarely happens. You have to just approach those problems with, I would say, seriousness, and everything else will come from there. Because if you’re not stupid, if you do have engineering approach to everything, simply putting yourself into that frame of kind of mind, will help you solve sales and marketing challenges.

Advice For Entrepreneurs

Michael Schwartz: Last question, any advice for new entrepreneurs launching a business around an open-source software project or product?

Ev Kontsevoy: Yes. I would just say, forget about that word, don’t call yourself entrepreneur – that’s a distraction. Think of yourself as a product person who tries to solve someone’s problem, and just focus on that until you have overwhelming evidence that it is indeed happening. Because at the end of the day, company is just like a vehicle for allocating and distributing resources. This is what it is. It’s deeply secondary to what you actually trying to do. So, if you want to change the way how backups are done, just focus on that and just forget about incorporation, what kind of company you want, what kind of investors you want – all of that, it’s not primary to your success.


You have to understand what your solution is going to be, how it’s going to be different, how it’s going to be better, who is going to like it, who’s going to not like it – solving all of these problems and just focusing on that before you even begin to think about entrepreneurship is probably key.
Because one common thing I see in “entrepreneurial circles” is that people basically start with this, “I want to have a company.”, and then, they start looking for problems to solve. It just feels very unnatural to me.

Closing

Michael Schwartz: Ev, thank you so much for going over a little bit on time and for sharing all your experience, and best of luck with Gravitational.

Ev Kontsevoy: Thank you very much! Thanks for having me, Mike.

Michael Schwartz: Great job by Ev, isn’t it? Editing by Ines Cetenji. Transcription by Marina Andjelkovic. Cool graphics from Kamal Bhattacharjee.

Music from Broke For Free, Chris Zabriskie and Lee Rosevere. The podcast Twitter handle is @fosspodcast. Follow us. Retweet the episodes, help us get the word out.

Next episode German-British-Kiwi, Martin Buhr from Tyk, one of the coolest open-source API Management companies around.

Stay safe everyone. Until next time, thanks for listening.

Episode 47: Jenkins Software Delivery Automation and Management with Tracy Miranda, Director of Open Source Community CloudBees

Intro

Michael Schwartz: Hello and welcome to Open Source Underdogs. I’m your host Michael Schwartz, and this is episode 47 with Tracy Miranda, Director of Open-Source Community at CloudBees.

CloudBees is a company behind Jenkins, the famed project, which is used to automate building, testing and deploying software.

Many commercial and open-source projects use Jenkins as part of their continuous integration and delivery infrastructure, including my company Gluu.

Jenkins was forked from a project called Hudson, started by Sun Microsystems in 2005. After Oracle acquired Sun, Hudson was forked and rebranded as Jenkins.

Tracy has been an entrepreneur, a developer, a technologist for around 20 years. She was active in the Eclipse community, serving on the board of directors. She’s also one of the founders of the Continuous Delivery Foundation, which operates under the Linux Foundation.

Hopefully that gives you a little background, so let’s get on with it. Here’s Tracy. Thank you so much for joining today.

Tracy Miranda: Thanks, Mike. It is my pleasure to be here today.

Joining CloudBees

Michael Schwartz: For 10 years, you founded and ran your own consultancy, specializing in Eclipse development – how did you end up getting involved in CloudBees?

Tracy Miranda: Yes. I think the common thread there is definitely open source. So, I think that’s something early on in my career I’ve always been drawn to, especially because of the innovation that you find with open-source communities. And it came at a time I was looking to just make a change in the career and focus a bit more on some of the community building aspects.

And as I was talking to people out in the industry, I got introduced to Kohsuke Kawaguchi, who’s the creator of Jenkins, and at the time was the CTO of CloudBees. And the more he talked about the next stage of CloudBees, and what he wanted to do with Jenkins, the more exciting it sounded to me, so I could not resist the opportunity to join his team and lead the open-source team and try that future direction.

History of CloudBees

Michael Schwartz: So, for the non-geeks in the audience, can you talk a little bit about the history of Jenkins, and how that impacted the development of CloudBees?

Tracy Miranda: Yes, yes. So, Jenkins is a built automation server. It is most commonly used for continuous integration and continuous delivery, which are big parts of delivering software. So, it’s a tool that’s been around for 15 years. Many might know it originally in its first incarnation as Hudson, but it evolved over the years and became Jenkins and became very rapidly adopted by developers and focused on delivering software everywhere, just because it gave you a lot of flexibility.

And it was the first tool that sort of helped you integrate and build your software. And it was really what we’d say is the start of this whole field of developer productivity engineering.

And around it, so companies like CloudBees emerged, offering more Enterprise version. So, when it came to scaling or features around governance and securities, and CloudBees would offer Enterprise Jenkins. And that’s just sort of evolved and evolved, and now the whole space is currently really doing very well as we deliver more and more software every day.

CloudBees Products

Michael Schwartz: So, CloudBees has a number of products and services. For 2020, what are the most important products, with regard to revenue, and what are the most important projects for your future growth?

Tracy Miranda:  In 2020, well – let me talk about the direction we’re going first of all, and then I can bring that back to the present – so, we see just everybody’s delivering a lot more software, and software has become critical to every industry. So, you know, whether it’s a bank or a travel company or insurance company – you name it – software’s a differentiator for them. So, the more software we have, the more we kind of start to talk about like software factories. And you can use the factory metaphor as well to apply it to this.

So, in that model, we talk about Software Delivery Automation, and Software Delivery Management automation is just – the name says it all – it’s everything you need to do to get the software delivered, pretty much like a factory. And then, the Software Delivery Management, or SDM, is the part where you have the business intelligence coming in, how do you make the decisions, what to release when, and to who. So, that’s the direction we’re headed in, and we’re building out all the different parts that contribute to integrating all the tools.

Today, what a lot of companies have is basically focused on continuous integration and continuous delivery, so, tooling around tools like Jenkins, we also have SaaS versions of CICD tools, and then, any tools that help you deliver faster. So, we’ve got a whole kind of portfolio, depending on your flexibility and what you’re trying to achieve.

Market Segmentation

Michael Schwartz: CloudBees is in a very horizontal market. As you mentioned, you are serving customers in basically every industry. Given that, does CloudBees segment solutions or the marketing effort, either vertically, or by use case, or in any other way?

Tracy Miranda: I think probably the most clear segmentation, which we will kind of see, is whether people want to manage it and have things kind of on-premise themselves, or whether they want software-as-a-service. So, that tends to be a key differentiator.

And oftentimes, it will depend on the industry. So, certain industries might have very strict compliance or governance around it. So, perhaps, it always has to be an in-house solution. But then, perhaps some new startups, so, in different segments can afford to go with much more as a service model, where they don’t really want to deal with the nuts and bolts, and the upgrades and the security patches – they’re just happy to focus on what they need to do to get their software out the door.

Why Open Source

Michael Schwartz: Without open source, there probably would be no Jenkins, at least as it currently exists.  And therefore, I guess perhaps no CloudBees. But going forward, why does continuing to invest and contributing to an open-source community materially help the business?

Tracy Miranda: This is my key role at CloudBees is, it’s kind of overseeing the whole open-source strategy. So, you’re absolutely right, CloudBees is based on this massive open-source project, and as we grow and continuing to evolve, we’re going to do a lot more in open source and in different ways.

I think there’s lots of different benefits we see to open source, so, on one side, if you take kind of just the engineering side, there’s obvious benefits from working with the community – you’d get fast feedback, you’d get people contributing.

A lot of the developers we hired in the early days would come from open-source communities, and then they’d even have the advantage of they are already up-to-speed with the processes and the ways of working and the code base.

But then, there’s also other kind of strategic science to open source as well. Open-source projects tend to spread like wildfire, I had someone using the term, kind of the open-source tsunami. And they have a tendency to change the direction of industries, to take something like Kubernetes, which caused a big shift in the whole sort of cloud infrastructure.

So, in that way, we also kind of look at technologies for them to be open and for them to drive the future direction of the industry and help us to get to an innovative place. So, we always want to be involved with open source and find ways to just create those kind of win-win situations for both the community and the company.

Open V. Commercial Features

Michael Schwartz: You mentioned previously that it was an Enterprise version of Jenkins, and I’m wondering about, today, is there still software that’s non open source, and if so, how do you decide what to open-source and what to keep private?

Tracy Miranda: Yes. I know that’s a key thing, and it’s constantly evolving. So, we have an internal process, and we’ll kind of look at the way things are evolving in the market. In general, like you take something like Jenkins, and we have a lot of plugins added by different groups and different individuals in some cases.

One thing that CloudBees do is, for the software like CloudBees Core, or CloudBees CI built on top of Jenkins, is we also offer kind of tiers of plugin, so we know which ones meet a certain level and meet the requirements for Enterprise type customers.

So, this is focused specifically on things like security and governance and running things at scale. So, typically features in those areas, or verifying plugins, will be the areas we’ll tend to kind of have as the more closed source. And anything developers tend to use, this tends to be pretty open.

Open Source Strip Mining

Michael Schwartz: I’m sure you’ve heard this term “open source strip mining”, where large companies take open-source software projects and commercialize them. You know, you have a SaaS, you are offering themselves, but is this something that you’re concerned about, or any thoughts about this sort of phenomenon?

Tracy Miranda: I’ve definitely heard the term, yeah, it’s a pretty controversial one. But I think it is something that is always a consideration. So, you take something like Jenkins X, which is a new open-source project. It’s not related to Jenkins, as the name might indicate, but it’s actually a complete new CICD tool based on Kubernetes. And it’s one of the best ways to do Cloud Native CICD.

So, a lot of Jenkins X is open source, and you could conceivably imagine another company taking it and wrapping it up and delivering it in a specific way, but I think the reality is that open source is always evolving. And it’s more about kind of the vision in the direction it’s going. And the key thing I guess from CloudBees’ perspective is, we have a lot of the people who are driving that direction working for CloudBees.

So, I guess that the people, at the end of the day, are a secret source. So, even if other people want to come and extend it or do it in a different way, I think we’re always kind of focused on what’s the vision, how is this going to evolve, how we’re going to keep pushing the industry forward. It’s a concern, but we try not to spend too much time focused on that, just more time focused on what do the users want and where are we headed.

SaaS V. License?

Michael Schwartz: In terms of monetization strategy, is the Enterprise license the majority of the revenues, or is SaaS the biggest part of the revenue stream?

Tracy Miranda: Yes. Enterprise licenses are definitely the main focus. I think that will evolve over the next set of years, but, for now, that’s certainly the case.

Pricing

Michael Schwartz:  Few questions about pricing, which is hard for a lot of startup entrepreneurs. Many organizations are using Jenkins for free – is it hard to move these customers to a paid offering? What type of gates do you define? Is it per developer? And is pricing still evolving with new offerings, or have you achieved some stability in the pricing area?

Tracy Miranda: Yeah. No, I think this is an area constantly evolving. You know, Jenkins is a great tool, and a lot of people can do a lot of things with that anyway. So, we’re always looking to add value on top of that. So, we find a lot of the customers who see the value of CloudBees, they’re focused on what they need to do as a business, they don’t really want to be messing around CICD is not their value add, so they want kind of the complete package. And that includes the ability to get support and the ability to know things are going to work for them.

When you are sort of doing things in open source by yourself, you tend to run the risks yourself. You can pick up plugins and you have to decide, are these going to work for me, are they going to have the security patches attached. And what happens if something goes wrong? You know, you can’t pick up a phone and kind of call up the open-source community and ask them to fix your thing in a timely manner. That being said, it is a constantly evolving space.

So, I think kind of the offerings and the bundling and the way that works is always evolving. And like we will do things as well, like offer kind of more analytics on top of that, which give people sort of more insights in what they can do with their systems, and yeah, that’s just constantly growing,

Partnerships

Michael Schwartz: What have been some of the more important partnerships for CloudBees in terms of specially impacting the business?

Tracy Miranda: In today’s world, I think you really can’t succeed as a company on your own – we had a recent kind of partnership program, which I think we’ve got a whole bunch of companies who we were working with. My main tendency is to be on the open source and on the Continuous Delivery Foundation – it’s not partnerships in the traditional sense, but a lot of companies on the open-source side we’re working with closely.

And the other big one today is the partnerships with the cloud providers, and with those we have really strong relationships. I think every cloud provider has a marketplace out there, and you can easily access all CloudBees products very easily from the cloud marketplaces. I think this year we’ve also named the Google Cloud partner of the year, so, yeah, a lot of strong relationships, especially towards a whole Cloud space.

Project Governance

Michael Schwartz: You have a lot of experience in this area, so I can’t resist asking, but companies can host their own open source and build their own governance infrastructure around their project, or they can move to a foundation that can help maybe attract a larger community. What’s the strategy of CloudBees there, and how’s that evolved over the years?

Tracy Miranda: Yeah, a great question. So, Jenkins itself pretty much had its own governance, and that worked well and served the community really well for the first kind of ten, fifteen years. You know, it is very alike with model software in the public interest, it provides some great services.  But, eventually, it got to a point where there was some kind of sticking points in the community. These were things sort of shared widely with the community.

Some key things like just having a business entity so that we could get signing certificates, having a more kind of ability to hire for roles that want developers, but other kind of things that are key to software projects, but you don’t necessarily get contributions for. And again, the ability to build a bigger community.

So, these are kind of some of the limitations that we hit. So, Jenkins got to a scale, where it needed to grow past that and to get companies interested and understanding it, they needed a really kind of known model, which is why it then looked at setting up Jenkins in an open-source foundation. And that led eventually to the Continuous Delivery Foundation forming, which is, as the more we talked to folks, the more it made sense, not just to have a single project foundation but to have something where a bunch of folks could come together and work towards a bigger vision.

So, that’s been the key thing. The creation of the Continuous Delivery Foundation is what have helped launch over the last year. And that’s been a major kind of change, both for Jenkins and for CloudBees as a business.

Fostering Diversity at CloudBees

Michael Schwartz: You have been an advocate for a diversity. And I am wondering have you been able to have an impact on how CloudBees builds the team?

Tracy Miranda: Yeah, I think diversity is super important for all sorts of reasons, but especially for business ones. I am very lucky in my position, I head up the open-source team, I’m a hiring manager, so, in a great position to kind of influence that at CloudBees.

So, I have a great team, and I’m happy to say very diverse on kind of multiple accesses. You know, gender and age, and from where we are across the world. So, that’s been really nice.

We also have lots of initiatives at CloudBees. One of the things I’m pleased to say is, there’s a lot of people doing things like CloudBees, and kind of constantly changing the status quo, which is nice, because it’s not always something I have to do, and then I can just kind of focus on my main job. But, yeah, a lot of great folks pushing things in the right direction.

Pandemic Impact On Diversity?

Michael Schwartz: We’re recording this episode in May of 2020, so the pandemic is on everyone’s mind. It’s easy to look at all the negatives, but being an entrepreneur, I think I’m inclined to look at positives. Is there any way we can spin the pandemic as a positive around creating more diverse teams?

Tracy Miranda: That’s really interesting. But I think by moving online and by a lot of companies had this almost artificial limit on, where people can be hired from and all having to live in specific areas, which are often cities, which often have big barriers to entry in some cases. I think by going virtual, you do remove some barriers, you do make it easier for people to be hired from wherever they are, and all of a sudden, that does open up the field for people you can hire from. So, I think, in that way, it can be very positive.

How To Catalyze Gender Diversity In Tech?

Michael Schwartz: Just speaking from my own personal experience, my company is very globally distributed in terms of team members, we have team members from like every continent, except Antarctica. So, we are doing an okay job in terms of diversity, but in terms of getting more women on the team, we’ve faced some challenges.

I know you’ve talked a little bit about this topic, but maybe you can share why do you think there aren’t more women in tech, and what are some of the challenges that women face? And how can we maybe help more women get into the tech business?

Tracy Miranda: I spent a lot of time over the last three or four years trying to understand for myself, because I think at the beginning of my career, I took it a bit for granted. I thought this is just the status quo, this is how it is, but I think it is down to kind of a number of factors all coming together. And you know, unconscious bias tends to be a big feature.

We’ve got just a ton of research that shows how lots of different things have compounded things over the year. I think there’s a great NPR Podcast as well, which talked about the times of women started dropping out of computer science courses. And it was almost because computers in general were marketed towards boys. And it was very difficult for them to sort of coming disadvantages to the courses, and there was not a lot of empathy for that. So, I think that that’s kind of one factor, but there’s a lot of other things in general that play out, just networks and how people bring people into companies.

So, the good news is I think we have more awareness than ever before of what it takes. And then, there’s a number of things we can do. The bad news is, you almost have to keep at it constantly, and things change very, very slowly. But we know, for instance, just representation matters hugely. So, having more women voices, having more women in higher position kind of modeling — I think there’s a great expression “You can’t be what you can’t see.”

And then, just having more not just mentors for women but sponsors who are ready to kind of pull them up in the right channels, help them to get and meet their goals much faster. And I think we’re getting a lot more systematic approaches in place to do this. And actually, I was really glad to see with your podcast, you have a lot of the recent guests have been some very frankly incredible and awesome women. And I think that’s places you start, just having that representation, having those people talking and telling their story.

Advice For Open Source Startups

Michael Schwartz: Thank you. We are doing our best. So, last question, you run your own company for a decade, and you’ve been around open source for a long time, so I’m sure you’ve seen some successes and failures of entrepreneurs who have tried to use open source as part of their business model. If you were starting out from fresh today, you wanted to use open source and build a business around it, do you have any advice for that person about how they should go about it?

Tracy Miranda: I think there’s a lot that gets said about kind of open source and the relationship with business models. I think I completely buy into it. Building off open source has so many efficiencies and so much kind of leads to a lot of serendipity.

I think you see a lot of startups today embracing open source and understanding that it’s not just open source in the sense of code, but what you’re really doing when you embrace open source is building out a community. And I think people understand more than ever how key developers are to any product and how key that community is.

So, not that open source is the only way to do it, but it’s such a great way to do it, and I think the main advice would be: if you’re doing it, you have to commit to it completely. You can’t kind of be half-hearted about open source, you have to commit to the vision and to the community and constantly growing it and tending to it like garden. And then, it will play huge dividends. And we have seen the companies who have done really, really well off open source. It’s just kind of really sort of impressive.

Closing

Michael Schwartz: Tracy, thank you so much for spending some time with us today. And best of luck with CloudBees and with the Continuous Delivery Foundation.

Tracy Miranda: Thanks very much for having me. It’s been great.

Michael Schwartz:  Thanks to the CloudBees team for helping us to promote this episode on social media. Editing by Ines Cetenji. Transcription by Marina Andjelkovic. Cool graphics by Kamal Bhattacharjee. Music from Broke For Free, Chris Zabriskie and Lee Rosevere.

The podcast Twitter handle is @fosspodcast.

Next week we talk to Ev Kontsevoy, founder and CEO of Gravitational. Stay safe everyone. And until next time, thanks for listening.

Episode 45: Continuous Deployment with Tracy Ragan, Creator and CEO of DeployHub

Episode 45 of the Open Source Underdogs Podcast: An interview with Tracy Ragan, CEO and Co-Founder of Deployhub.

Episode 44: Devops, Security, & Cloud Automation Puppet with Yvonne Wassenaar, Chief Executive Officer

Intro


Mike: Hello, and welcome to Open Source Underdogs. I’m your host, Mike Schwartz, and this is episode 44 with Yvonne Wassenaar, CEO of Puppet. Yvonne is the third CEO of Puppet. Luke Kanies was the founder, we interviewed him in the episode 22.


Sanjay Mirchandani succeeded him, and Yvonne took over from Sanjay in January of 2019, about a year before we recorded this episode. A CEO who takes over a company like Puppet needs a different skill set than your typical founder. Whereas the founder needs deep domain knowledge, usually a hands-on approach to business development, CEOs for companies, in later stages of growth, need this intangible corporate leadership ability. It’s hard to say what it is, but you know what it is when you see it. Yvonne has it, and she also has the values and an understanding of the culture that complements where Puppet is in its corporate life cycle. I don’t want to spoil any of the content, so I hope you enjoy this interview. Here we go.

Why Take On The CEO Role At Puppet?

Mike: Yvonne, thank you so much for joining us today.

Yvonne: Absolutely. It’s great to be here, Mike.

Mike: When you joined Puppet early last year, as CEO, why did you want to take on this enormous responsibility, steering the ship with hundreds of employees and thousands of customers?

Yvonne: You frame Puppet so well in terms of, it is a large employee base. We do have a lot of customers, and I’d extend it even further into we’ve got a massive community around the globe. And I did think really long and hard around was I the right person to take on the responsibility to bring Puppet and the impact of Puppet, the company, in the community to the next level.

And the reason I said yes to that that question, to myself and to the board, is, as I thought about the opportunity, Puppet to me represented a perfect place for my step, next step in my journey, for the following reasons.

One, the values that are represented by Puppet, and the Puppet community aligned really well with my own, in the sense that we are really focused around – you know, being open-source core kind of the democratization of technology diversity and inclusion, having impact at the practitioner level, and really making a difference in the world around us.

And to me, I feel life’s very short, and having strong value alignment is really important. And what Puppet represented resonated very much with me.

The second thing is really around the technology and the problem that we solve. I deeply believe that Puppet and the technology that we build and work, standing upon with the community and with our own team, makes a difference in the world around us, makes a difference not only in eliminating soul-crushing work, which is what Luke started with, but makes a difference in terms of enabling companies to achieve the agility that they want, in a secure and scalable way.

And as an ex CIO, the risk of cyber security I think sometimes is underestimated, and it’s really beholding upon all of us to think about not only how do we leverage technology to make the world a great place, but how do we do it in a safe way.

So, to me, if I think about the values, and I think about the actual product and offerings that we’re bringing to market through the community and with our commercial offerings, that resonated really well. So, the third component was, “Can I personally make a difference?”
 
Given my experience across companies like New Relic, VMware, and my time in Accenture, I felt I had a good breath of experience that I could, not necessarily bring the answer, but ask the right questions and bring the right team on board to really deliver our true potential as a company.

So, those three things combined, all aligned up, and having been here a year, it was definitely the right decision. It’s been a great ride, I think we’re doing amazing stuff, and I can’t wait for what’s yet to come.

Why Expand Product Surface Area from Configuration Management?

Mike: In the past, I might have described Puppet as being a Configuration Management Platform, but today, Puppet’s moving into areas like continuous compliance, incident remediation, and continuous delivery – why expand the product surface area? And I’m also wondering, how do you evaluate the risks that come along with that expansion?

Yvonne: Puppet as a Configuration Management Platform, I’d even say tool, has been the market perception of who we are. And that very much is grounded on where we started.

To me, the fascinating part of your question really comes down to the fact that the big shift that Puppet made in this last year was going from talking about what I would call “feature functionality”, which what Puppet does, is, really, we automate infrastructure in really, really powerful ways, to talking about the use cases and the business problems that we solve.


So, what’s interesting is, from a technology standpoint, what Puppet has built out over the years is going from a declarative approach to infrastructure automation, which is where we started, which is, we’re turning environment to a known, good state, to extending that into both declarative and task-based automation, which we leverage our open-source project, Bolt, to support and drive. And Bolt integrates with Puppet enterprise. So, it’s both declarative and task-based, both agent and agentless. Now, we are extending even further into workflow, event-based automation.

The tool has gotten more robust in terms of the types of things that people can do with it, but the real shift, I think, from an impact standpoint, is, we’ve started to really be able to harvest from our customers, what do they use that tool in capability for. So, you know, certainly some people are using Puppet truly to manage the configurations in their environments, and that’s the main driver. They’re looking for that efficiency and scalability of what they’re doing.

We also found, however, that some people are deeply dependent on Puppet for compliance. And that understanding that that’s the business use for the tool, or one of the business uses for it, allows us to better serve up and meet those needs.

And interestingly, from an incident remediation standpoint, again, there’s a lot Puppet does from a declarative model standpoint that was always kind of remediating your environments in some way, shape or form, if you think about it. But it’s a very simple extension into integration with security scanners like Tenable, Qualys and Rapid7, to really start to go, having a scan, and then, manual process, and sorting through PDFs and Excel files, to get to business impact to saying, “Hey, I can ingest that information, make it contextually aware in the environment, and allow people to act on it in a much automated way.” Which not only reduces the work effort, but very importantly, to my earlier comment on cybersecurity, reduces the time to remediation of a known vulnerability, which improves your security profile.

So, the big shift, I think Puppet for a while has been making the tool or the platform more robust, but the shift that I think you’ve seen in the marketplace perspective is more around how we characterize what our technology can do in the context of business problems and business outcomes.

Priorities After Joining as CEO

Mike: In your first few months as CEO, what were your priorities, and did you feel like you needed to pivot the business after coming in after the founder? And I’m wondering, was there really a pivot needed? Or did you see that it was more of a requirement to incrementally improve what Puppet was doing?

Yvonne: Yes, it’s always challenging when you take a company over as CEO, in part because there’s a huge piece of the culture and the connection with the people that comes with that top job that you have to be sensitive to.

When I look at the journey of Puppet – Luke actually ran the company for the first many, many years very successfully, and the creation of this new market, and the proliferation of the technology at that practitioner level, there was actually another gentleman, Sanjay Mirchandani, who took over from Luke and ran Puppet for three years. And what Sanjay focused on was really selling higher up into the enterprise, and kind of, to your previous question, looking at going beyond configuration management, what was important in the marketplace.

As I took Puppet over a year ago, the key things that I noticed, one was that we were very much on the right trajectory, and it was more some fine tuning and focus that we had to drive to the business. And my real time and attention in the first year, first and foremost, was on appreciating that a CEO change, no matter how great I may or I may not be, is an experience that you need to work through with your employees and with your community.

So, my first focus was on the team and the community and really aligning around purpose. And kind of your first question, why was I even there, did I care about the same things they did, were my values aligned, how are we going to come together as a team and really drive the next level of the journey – I think that’s important advice for anybody taking on a senior level role.

Start with the people, and then, really, from a business perspective, looking at how could we get the biggest impact with these things that we have, how can we simplify and focus what we are doing to those that would make the biggest difference.

So, we did trim the product portfolio a little bit, we doubled down on areas where we felt we had differentiated capability, we started to focus a lot more on the engagement with the community, we had drifted a little bit away from that which happens sometime.

So, really looking at, we did our first ever in person contributor summit, looking at how could we really nurture both, the community who has gotten us to really where we are, as well as being in meaningful service to our enterprise customers, who, at the end of the day, are a critical part of the business model as well, and scaling what is now a relatively large company that has a strong open-source base, and also has a sustainable, monetary business model to care as well for.

Puppet Value Proposition

Mike: What would you say the value proposition is for Puppet today?

Yvonne: I believe that Puppet has gone from being a kind of a practitioner tool that eliminates soul-crushing work, which is a really, really important thing that we have extended a prawn, that value proposition, to being a platform that enables business agility in a safe and secure way. And the way that I see us, really bringing this to market is, if you think about the modern enterprise and open-source projects, they are here to service to everybody. We really focus our commercial efforts on what I would call the Global 1000. And in that segment, those companies are going to be in a hybrid, or multi-cloud world for many years, if not decades, to come.

And Puppet is uniquely positioned to, in some regards, be their automation everywhere platform, be it in the data center or into the cloud, and increasingly across the Internet of Things. And we’re able to do that because we have a portfolio of automation capabilities, so different types of automation are actually required for different types of use cases in needs.

And so, whereas before, the world was a little black and white, you know, it’s either declarative or it’s imperative, and there were religious battles, it’s like now we realize that many different types of automation are needed when you operate at that scale. And we offer all of them in a coherent way. And we’re starting to build out the intelligence from that practitioner level up through the executive level, and helping people do things, all the way from, get the work done, to create the reports and the insights that the auditors need to get you through that compliance check.

So, for me, the real value proposition for Puppet in the commercial space is being that automation everywhere platform that gives you the action that makes things like your ServiceNow and Splunk implementations complete, because they might be able to tell you what to do or where the problems are.

But it’s really when they integrate with Puppet, that you get that completion of that loop, that everybody needs to truly get the business impact.

Market Segmentation

Mike: So, Global 1000 is still a very horizontal market with all sorts of different vertical segments. I’m wondering, from tactical sales and marketing perspective, when you’re trying to convey business value to these different segments, do you have to change the marketing a little bit? Or is there any vertical marketing or segmentation going on, and how you look at the customers, and how to sell to them?

Yvonne: Yeah, absolutely. I love the question that you asked because there are so many horizontal technologies in the world, and I work with many companies, back in the day, BEA, and VMware, all very horizontal in terms of a capability. What’s interesting, however, is the importance that you highlight, which is differentiating how a product is built versus how a product is bought and consumed.

And that’s when you do benefit I think from taking a more vertical or use case approach to a technology. And, for us, for example, we do a lot in highly-regulated industries, and financial services is a great callout.

So, even though the Puppet product offerings are the same, whether in service to retail, or financial services, or tech, or government, how we speak about the technology can start to vary in terms of those segments.

And at the enterprise level, referential buying is a real thing. You know, if I’m a large bank, I’m greatly comforted if I know five other large banks also use that same technology. And you can start to help them understand the financial services banking problems that you can solve, and as I mentioned, compliance or certain compliance requirements in those industries.

So, you can start to make it much easier for your customers to get value out of your technology and to trust your technology, when you can speak in their language, and when you can connect them with their peers, who are in a similar way using your technology to solve problems.

So, what we have done – to answer your question from a segmentation standpoint – one is, recognized where are our open-source solutions most relevant and valued, and continuing to feed and nurture those. And then, being really thoughtful on where our commercial offerings are most valuable, and drive the greatest impact.

And on the commercial side then, further sub-segmenting into vertical industry, and then, as we talked about use case, are you looking to solve problems around incident remediation and reduce time to vulnerability remediation, are you more interested in compliance reporting.

At the end of the day, I like to kind of joke, Puppet is a Swiss army knife, they can do a lot of things. That’s a blessing and a curse. And when you work with large enterprise, then, more specific you can be on the problem you solve – I kind of use the analogy of an IKEA furniture – at the enterprise level, they really don’t want the big box of IKEA furniture showing up in a bunch of little pieces, without an instruction manual they have to solve it themselves.

Some people like that and get a lot of joy. It’s usually not my customers, they want to have a simple easy way to get to business outcome. So, we’ve really done a lot to make that clear and easier for them.

How To Balance Open Source Investment

Mike: I thought it was interesting how you mentioned that you were, let’s say, investing a little bit in the open-source community, for example, an event for contributors. I’m wondering if you could talk about how do you prioritize investments in the commercial product versus the open-source product?

Yvonne: I think about open source a lot. For me, personally, I think we are where we are in terms of the rapid technological advancement because of open source, and how that’s really proliferated around the globe in so many ways. And I do believe that it is a great way to democratize access and contribution to technological development, particularly with underrepresented groups in countries and locations, where they may not have otherwise been able to participate at that highest level.

So, I’m a big believer in the whole concept, and I’m really proud to work at a company that appreciates and celebrates that, and invests in it. What I think is really important in the seat that I sit in is appreciating the fact that open source has in our case almost moral and principle value, but it’s also a critical component of our strategy. It is not the business model itself, but it’s a key part of our strategy.

And I think of open-source in a couple different components. We have open source tools, Puppet open-source Bolts, those are tools that our community members can contribute to and benefit from. We have open-source content, which, in our case lives on the forge, which makes the tools even richer. And we have some people who only contribute to content, and some who only contribute to the tool, and some who contribute to both. And then we have the users of that open-source content.

And to me, it’s important when I think about the open-source community, I think about all those constituencies because they’re all critical players even though they’re playing in different roles. And I’m very proud to say we have over 75% of our commits still coming from the community. We have a very active community.

For me, what’s important is that we are continuing to nurture the creativity, the innovation, the access, in what I would call that “ground level of capability”, and that we’re allowing people, who have interest in ownership and institutions that we’ve built, to be able to contribute and get the benefits over time.

So, we do a lot of things, from – we did a contributor summit in Budapest last year, we are doing Puppet camps again, so we’ve reinvested in that, more currently, in the process, we’re making them virtual just because of the environmental challenges, this coronavirus. But we are looking for ways that we can help people who are part of the Puppet community be able to have a platform to speak about, what they’re doing with the technology, the impact it’s having, and help others.

We have obviously community managers, we’ve got slack channels, we’ve got some interesting ways that we’re looking at engaging with the community from the support perspective. So, there are many different aspects to it.

And to me, one of the beautiful things is I think open source has evolved a lot in the last decade. And I like to think of Puppet as one of the folks who are leading through that evolution, and how you continue to give back, and you know, garner benefit in a very, very productive way. So, super-excited about what we’ve done. I’m sure we’re looking to evolve, but I do think it’s part of what makes Puppet special.

Evolution of Sales Motion

Mike: So, originally, I’m sure open source was one of the primary let’s say distribution channels for finding customers who are going to engage with you commercially. But I’m sure that the sales, you know, processes, and motion has gotten very mature as a company has grown. How does it work today? Would you say that the open source still really is a driver for business? And, if it’s changed, like, how have you adapted to that change?


Yvonne: The go-to-market side of Puppet has evolved a lot. And open source has, as you suggested, played a critical role, and I believe it still does, but it’s shifted.

In the beginning, a lot of people who bought the Puppet commercial products came from the community, and they were the practitioners who were bringing that technology into that environment.

Many of the open-source users never felt the need to actually go and buy commercial products, they scaled up, and they built their own UIs and their own ways of advancing the open-source project in their company.

And so, we did go through a phase, where, in the early days, there was a lot of inbound. And what I would say is, now, the two things that have shifted, one is, as our ability to drive impact across an enterprise has increased, as the maturity of our solutions have increased, we’re actually selling to higher-level individuals in a company.

So, what I’d like to say is, we’re not just selling to the hands-on keyboard people, we’re selling to people who may never actually touch Puppet, the technology themselves. And yet, the fact that there are Puppet practitioners in their company is super important. So, I think one open source serves us today because it keeps a rich set of talents in the marketplace that can work on, and scale and execute the technologies that we’re bringing to the enterprise customers.


The other thing that we found is, many of our enterprise customers have in some way, shape, or form, or division, used, or are using, open source. And they have just set a point where it’s no longer differentiating for them to do all the work around, upgrading the open-source and everything else, to do it that way. And they rather move to the commercial version, take advantage of the incremental feature functionality, have a simpler upgrade process, have 24/7 support.

So, for us, I would say, in some regard, open source is still the land, people are using it, and then they’re starting to realize open source isn’t free. You’re just making different choices, do you want to have the engineering talent work on, keeping your open-source implementation healthy and current, and to build around it.

That’s the right choice for some. For others they are saying, “Hey, open source was a great way to get something started. Now it’s starting to run a critical component of my business. Maybe I’m better off, from an opportunity cost perspective, to engage with Puppet, to have Puppet provide me those services of incremental feature functionality, and reporting and support. And I can spend my valuable engineering talents time on other things that might differentiate me as a retailer, or manufacturer, or a bank.”

Is Puppet Open Core?

Mike: Would you say that Puppet is open core?

Yvonne: What I would say is, Puppet has – and I think this has been the big shift in terms of how we think as a company – certainly Puppet open source is a very mature, very impactful projects that many people can build on top of, frankly, around globe, which is wonderful to see.

What I would say is, as we think about the broader Puppet, what we are looking at is, how do we create open-source capabilities that people can stitch together in different ways to self-problems. And we don’t just look anymore at, we have to be the sponsor of those open-source projects, we absolutely contribute upstream to other projects, we leverage other open-source solutions in some of what we do. For example, Terraform and Puppet work great together, there’s actually some great webinars on how you leverage Bolt and Terraform to drive provisioning, and configuration and actioning on that.

So, we’ve really taken a much more open-minded approach, and thought about open source, almost from a component or an ingredient standpoint, that can be stitched together into whatever solution that you need. And some of those solutions we stitched together in a commercial way for our large complex enterprise customers. And others were providing the componentry that companies can stitch together in the way that they need if they want to do something all open source, or put their own secret sauce magic to it.

Pricing

Mike: Pricing is I think really hard for every company, surprisingly difficult. And it seems like the impact and the value of Puppet is so enormous to organizations – how do you find the rate gate to figure out or to find the right strategy for pricing? And you’ve only been there for a year, but have you seen that change? Do you think that the pricing model that you’ve figured out is going to be stable?

Yvonne: Pricing is an incredibly challenging topic I think to your point for pretty much everybody, and to me, what I learned early on, back in my consulting days, is one of the best ways to think about what the right pricing model is, for your company is, to start with the value chain of what you’re bringing to your customers.

If I take an early-day example of like an eBay, you know, market place, you are bringing value creating community. You’re making value by letting people sell through that community, you’re making value by letting people buy through that community. You are making value by providing different ways to attract attention.


You can kind of map out all the different value points, and then, you can make decisions on where do you want to price to be able to get a return on the value you’re creating. So, eBay for example, could have chosen to say, “Hey, you’ve got to pay to get in, and then everything else is free.” Or, you can get in for free, “There’s value in there, but let me give you that for free, and you’re going to pay these other steps.”

So, I think every company needs to go through that process and figure out where the value is, their driving for their audience that’s worth having an exchange. The interesting thing is, it can easily become way too complex. So, simplicity is an important rule of pricing in my experience, and then longevity.

Particularly if you’re in the enterprise space, you don’t want to be changing pricing all the time, and it runs through your systems. So, I feel Puppet, in terms of where we’ve come from, that we have a pricing model that has worked well for us and for our customer base, on where we’re at. Are there opportunities to fine tune it and evolve over time? I’m confident there are. I’ve never seen a company that hasn’t at some point in time started to shift and think differently about their pricing.

But, to me, whatever you do with pricing, it has to center around what is the value that you’re bringing your customers, and can you come up with something that’s simple and easier for them to understand that will scale out for a meaningful period of time. Because a hard thing to do is change your pricing all the time. That’s an easy way to upset your customers, and make a lot of enemies in procurement. And nobody wants to do that.

How to Encourage More Women in Open Source Business?

Mike: Yvonne, you might have noticed that the male to female ratio in Open Source Underdogs is currently 41:2. And we’re trying to improve that ratio this year, but it does reflect the reality of the tech market, which is that men are overrepresented, especially at the C-level. What can we do as an industry, or even more tactically, what can I do, as a founder of a software company, to improve that ratio?


Yvonne: I love that you’re asking the question, what can you do to improve the ratio, because I believe at the end of the day, it has to start with individual ownership in action. And we can talk about really lofty things we could do, but at the end of the day, we need to create the future reality that we want. And we all have a role in it, whether we’re male and female, different types of necessities and so forth, if we want a diverse world, we have to create the opportunities for that, or diverse roles in leadership I should say.

And what I believe you could do, first and foremost, I appreciate this opportunity, just showcasing Puppet and myself, and having different types of role models in your podcast. I’ve had numerous women come up to me and tell me that they aspire to be a CEO, and in part, they aspire to be a CEO because they see me doing it. That’s incredibly humbling, but it’s also a great reminder that, for many people, if you can’t see it, you can’t believe it.


So, I think, first and foremost, showcasing different types of role models, that it’s not just one type that a successful leader looks like, but there’s many. The second thing is sponsoring and encouraging people to step up to that next level.

What I have found working with underrepresented folks is that – myself included – we can often tend to be much risk-averse. So, encouraging people to retire to build that confidence that they can go to that next level. Sometimes to give them that nice gentle push, maybe not so gentle sometimes, as I had in my career. Sometimes, you just need that.

So, I think creating the models, I think giving the pushes. And then giving the opportunities, take a risk on somebody. You’ll be amazed at what they’ll do with the right sponsorship and support. So, I think there’s a lot we can do across the board, but those are three tactical things that, at an individual level we can engage in, things that I try to do all the time.

Advice for Founders

Mike: Last question, any advice for entrepreneurs who are looking to use open source as part of their business?

Yvonne: Absolutely. I live in Silicon Valley, and I run into a lot of people who get really confused on open source, and – when I say “get confused on open source”, they confuse perhaps a desire and a belief around the power of open source as a way to democratize technology and bring important solutions into the hands of everybody, with the fact that somehow you’re going to have to figure out how you’re going to make money.


And so, to me, it’s really important to understand you can get both, I think Puppet does both, but you have to be really thoughtful what is the role that open source is going to play in your business model, because it is not a business model into itself. That’s kind of a rule number one.


The second thing that I would say is, community, community, community. I don’t think that you’re going to get a lot of benefit out of just open-source thing, the technology you build if you’re the only one building it. Certainly people might use it, they’re not going to pay you for it, they might benefit from it, they might like that it’s open source, but I think part of what’s made Puppet powerful from an open-source perspective is the community engagement, and the fact that we’re collaboratively building these different open-source projects, and that we are collaboratively building content – that is what I think truly makes open-source most powerful.

So, I really think if you’re going to do an open-source solution or have that be part of your solution model, how are you going to invest in, and engage, and nurture, and grow, and sponsor, and give a voice to your community, so that you keep them engaged, so that it truly is really executing open source at what I think is the most powerful level and form.

Closing

Mike: Yvonne, thank you so much for your time and sharing your great insights today.

Yvonne: Great. Mike, thank you, it’s been wonderful. And, again, I really appreciate the opportunity.

Mike: Special thanks to the Puppet team for helping to coordinate this episode. Audio editing by Ines Cetenji. Transcription by Marina Andjelkovic. Music from Broke for Free, Chris Zabriskie and Lee Rosevere.The podcast Twitter handle is @fosspodcast.
Please, tweet at us if you have any comments on this episode. Next time, we talk to Tracy Regan from DeployHub, a great technologists and founder CEO.

Stay safe everyone. Until next, time thanks for listening.

Episode 43: Native-Cloud Visibility and Security With Kris Nova, Chief Open Source Advocate at Sysdig

Intro

Mike: Hello, and welcome to Open Source Underdogs, the first podcast recorded in 2020. I’m your host Mike Schwartz, and this is episode 43 with Kris Nova, a Chief Open-Source Advocate at Sysdig.

Kris, who also goes by Nova, has contributed to Kubernetes and several other open-source successful software projects and startups. She’s currently a leader in the Falco project, a next-gen intrusion detection tool that is an “incubating” project at the Cloud Native Computing Foundation also known as CNCF.
My mission this year is to interview more women who are open-source business leader, so when the opportunity presented itself to interview Nova, I couldn’t resist. But this podcast was a bit of a challenge for me. I interviewed Loris Degionni, the CEO of Sysdig, a few episodes back, so I wanted to stray little from my normal business model format.

It was also really tough not going down the Cloud Native rabbit hole, although I think ultimately I couldn’t resist. So, it’s slightly more tacky than normal, but I hope you enjoy it. Personally, I found Nova’s perspective really thought-provoking, but you didn’t tune in to hear me, so without further ado, here we go. Nova, thank you so much for joining us today.

Nova: Yeah, thanks for having me.

Mike: So, how did you end up at Sysdig?


Nova: Well, I had come out of my third startup that had gone through an acquisition, and, you know, I took some time off from work, I did some traveling, and just kind of — it was the first time in my life and in my career, where I was able to take several months off of work and just kind of mentally reset. And I started to evaluate the industry I was working in, and I wanted to stay working closely with Cloud, and Cloud Native infrastructure, and Kubernetes, but I wanted to pivot a little bit.

And I started looking at the available spaces or sub departments of the industry. And one of the things that really stood out to me was the security. I felt like security was one of those things that you kind of look at it always as an afterthought.

You don’t really ever wake up and design new software on day one to be the most secure implementation. So, I felt like we were finally there with Cloud Native, and started having more involved security conversations. I felt like there was just a lot of room for innovation in a field that I already knew a lot about starting off, with a new spin on it, which was getting involved with security. And then, Sysdig reached out, and here I am.

What Is Falco?

Mike: Sysdig makes a ton of data available from the kernel, as I understand it. And Falco, the project that you’re working on, tries to filter that data to make some actionable security information, maybe about intrusion detection.

Nova: The definition that kind of really made it sing in my mind and resonated with me was, when Loris, our founder, I think you might have already spoken with him, the way he explained it to me was, basically we take the kernel as the new source of truth. Traditionally, if you look at how you would be auditing or attempting to observe a system, the network was usually kind of the most fundamental element you could get down to and, the thesis behind that was, if it’s happening at the network layer, we know it’s true, and we can trust it.

And as we moved into Cloud Native, we realized that TCP packets were not the smallest element anymore. So, we took it even down later further than the network, which is where the kernel comes into play.

I think you said it best yourself, we take a lot of information coming out of the kernel, and then we try to turn that into something meaningful for a human or a team. And that’s really what Falco does. It tries to be that connection point, that adapter between what would otherwise be an unreasonable amount of information coming out of the kernel, and then actually, trying to give you something that can help you tell a story.

Has Falco Been Good For Business?

Mike: Falco looks like a pretty impressive tool, and I’m wondering, has it been able to drive business opportunities for a Sysdig, the company?

Nova: I think if you look at open source, and what that means to anybody doing open source in any industry, it’s got a new way of thinking about how you engage with other people in the industry, other organizations in the industry, other folks in the enterprise.

And I think the easiest way that I can describe, the success I’ve seen with open source is, just looking at it as there’s fundamentally a difference between building a solution for someone and building a solution with someone. And I think open source is the latter of the two, is it gives you, and it gives your organization an opportunity to collaborate with other folks in the industry. And that’s where we’re seeing a lot of these hybrid solutions.

You know, we could have open-source software called Kubernetes running in a public cloud provider, using a CNI implementation from a startup in San Francisco, all of which being secured with Sysdig. So, we’re seeing these multi-level, multi cardinal solutions because people are building an open source, and realizing that it’s actually more effective to build a small tool that is easily consumable than it is to try to build this monolithic solution to every problem under the sun.

Has CNCF Been The Right Home For Falco?

Mike: Falco has been incubated at the CNCF. And I’m wondering if you have some thoughts about whether CNCF was the right home for the project?

Nova: I’ve been involved with the CNCF for years now. Like I mentioned earlier, I’ve worked at a few startups, we’ve donated, and built, and contributed to a handful of projects that ultimately ended up in the CNCF. And I think if you look at open source in the enterprise, and having a neutral third-party organization such as the CNCF, that can just help with things like governance, and infrastructure, and supporting the projects. And doing it in such a way that it’s neutral and unbiased for the project itself, ultimately just makes for a healthier project in a more wholesome experience for the maintainers and the end-users.

I think the CNCF does a really great job at embracing this idea that ultimately in open source the end-user is the new customer. They’re the new consumers of the open-source project, and giving them that customer-like experience is something that you really see with the CNCF, and I think really drives healthy communities.

Introducing Governance For Falco

Mike: So, one of your goals I guess, when you joined Sysdig, was to help build the governance infrastructure for the Falco project. Have there been any challenges along the way for making that happen?

Nova: I feel like when I joined, Falco was already on a trajectory to being a first-class security solution in Cloud Native that is open source. And I think I was able to come in with, you know, like I said, I’ve done this a few times, I’ve been involved with the CNCF for years, I’ve been working on other more household projects such as Kubernetes, or Helm, or Envoy. And I think I was able to come in and bring everybody together and kind of double down on our approach to open source.

I think there’s a lot of work that we had to do, that we have yet to do, but ultimately, it all comes down to this idea that, at the end of the day, Falco belongs to everyone. It’s not Sysdig’s tool, it’s a tool that was originally started by Sysdig and has already started to grow and be used in new and exciting ways.

We have end-users who are using Falco for things that we never even dreamed of originally. I think having that open-source governance, that open-source model of “We’re going to make our decisions in the public, and we’re going to give the broader community an opportunity to get involved with these decisions as we’re making them.”, has been a really big part of the direction that we needed to take the project over the past maybe six months or so.

Falco Ecosystem

Mike: In addition to end-users, have there been any other vendors who joined the Falco ecosystem? Maybe who are looking to commercialize Falco as part of their product or make an offering?

Nova: I mean, that’s something that we’ve tossed around with at Sysdig. And I think any time you have successful open source, somebody’s going to automatically go to, “Okay, how do we wrap this up and stick an SLA on it, and then start offering some sort of first-class support for a project.

And in my mind, once an open-source project reaches that stage, like that’s a sign of success. That’s ultimately where you want to end up. I think Falco is right on the cusp of us getting to more of an enterprise open-source solution.

I’m excited to see both, how my company Sysdig is able to take these new ideas and run with them, and potentially see other organizations and other companies in the industry do the same thing as well. So, I feel like we’re on that horizon of this finally happening for the project, which is pretty rad.

Trade-off Of Moving To A Foundation

Mike: I guess moving your project to a foundation, it’s a lot of bull thing to do for the governance of the project, but not all open-source companies do that. What are some of the trade-offs that you have to make when you decide to move your project to a foundation, and to move the governance to sort of a more open process?

Nova: In Falco, we always talk about exchanging of velocity for altitude. And I feel like in open source, we have that same paradigm of, as you go either more on the foundation side of things or more on the agile side of things, you’re going to be exchanging enterprise opportunity with the ability to be agile.

In other words, if we, as a company, had an open-source project, and we didn’t have open-source governance and open community around it, we would ultimately be able to iterate much quicker, and it would be a much more simpler and less complicated process for us to drive features, and to deal with debt, and to build a new functionality. But we would be sacrificing this ability to build with other folks in the ecosystem.

If you look at Kubernetes, if you look at a lot of the sub-projects of Kubernetes, they do operate at a less agile speed or less agile velocity, but ultimately, that has empowered many different companies in the enterprise to come together and start working on building holistic solutions for everyone.

I think a great example here is, there’s an infrastructure project called Cluster API, I had helped start this project, I think two years ago now, when I was at Microsoft, and the whole point of the project was, for us to come together and start to standardize how folks install and manage Kubernetes. And it’s taken two years for us to get where we are today, so it’s happened a little bit slower than most people might be used to.

But, we now have a standardized holistic API that anyone in the ecosystem can use. And we’ve actually seen large Cloud providers, VMware, Microsoft, Google, they’ve all come together, and they’ve actually started building to this new interface. So, again we’re exchanging that velocity for that ability to be collaborative.

Coalescing Ecosystem

Mike: Remember, when I interviewed Matt Mullenweg from WordPress, he mentioned something very similar how we could build it faster if we just build it ourselves, but the community slowed us down, but we ended up with better software.
And one of the other things I remember from that podcast was, well, just thinking about it, WordPress is really such a central part of so many ecosystems. They’re not monetizing Automattic, the company behind WordPress isn’t monetizing every user of WordPress. There’s companies that do WordPress hosting and WordPress development, so there’s this big ecosystem around WordPress, which is really impressive.

And I’m wondering, do you see the Falco project as coalescing that kind of ecosystem? And how do you get there? Or, is that even desirable?

Nova: I think the CNCF enables this type of collaboration. If you look at the projects, this is something that is baked into the governance model. When we were proposing Falco to move from the Sandbox, which is the most introductory level a project can be at, to incubation, which is where we are now, there is an entire section and an entire conversation around this concept of vendor independence, which is effectively this idea that if one vendor, who is working on a project, decided to take a step back, or take a break, or pull resources back, would the project still be able to grow, and prosper, and be healthy in the same way it is now?
And that’s a fundamental philosophy in the CNCF. So, I think you’re going to see that with every project. I think us doubling down this for Falco was really critical to us getting where we are with Falco.

Surprising Falco Use Cases?

Mike: So, you alluded to some of the interesting business use cases that maybe you didn’t anticipate when you designed the product. I’m wondering if you could share with us what some of those are? Because I was also wondering, it seems super interesting, but how do people actually use it?

Nova: I did a presentation of KubeCon in San Diego, with a gentleman named Abhinav from a company called Frame.io, and he went into a lot of detail about how they’re using Falco in a very limited way, which is funny, because I spend the first half of the presentation talking about how Falco can audit the entire kernel, and how we can start to process and assert various signals in the kernel that go for every system call that would potentially be running in Linux. And then Abhinav walks on the stage and says, “Oh, we only use it for three.”

And it was just kind of this funny moment, where it’s like, if that’s what they needed in their pipeline, which if you go, and you watch the video, you can see the use case, and why they were only interested in a subset of these metrics here.

You can actually see that Falco is dynamic and configurable enough for them to use it very concretely in a very small, but very precise way for exactly what they needed. So, I think you see that in a lot of different open source, but especially in Falco.

Can Falco Consume Non-Kernel Data?

Mike: Can Falco consume information from other sources, other than the kernel, and make sense of it in sort of the same way?

Nova: Yeah, absolutely. One of the things that we’ve been circulating in the Falco community, and I think this is a great example of us not being able to move as quickly as we wanted, but in exchange, we’re getting feedback and insight from the community is, we’re working on a long-term supported release called Falco 1.0.

And one of the things that we learned pre 1.0 was that there was actually a lot of value in taking other input sources other than just the kernel and enriching the Kernel information with these other input streams.

So, a big feature of 1.0 is going to be making secondary input streams much more dynamic and much more configurable, so that folks can start to plug other information into Falco when it comes time to building that story or that alerting system that they’re looking for, when it comes to detection, and anomaly detection, and insecurity.

Is There A Marketing Strategy At Sysdig For Falco?

Mike: Is there a marketing strategy at Sysdig for Falco?

Nova: Yes and no. So, we obviously have our corporate marketing strategy, we have an entire department here. And we have a lot of similar goals, but I feel like they’re implemented in different ways. I think the easiest example here is Sysdig targets customers and users of our platform, whereas Falco targets end-users, which effectively are customers, but the relationship is a little more like, “We’ll give you a foundation in the scaffolding to come and build with us.” And you’ll be able to do that effectively for free, but you’re not going to be getting a lot of the first-class features that you would be as like a commercial partner, or a commercial consumer of what Sysdig has to offer.

So, again, depending on your use case and what you’re looking for, it kind of gives us an opportunity for folks to get involved with — it’s going to cost more, but it’s going to be easier and more resilient, more reliable and more powerful. Or you can take the free open-source approach, which is going to require rolling up your sleeves and getting involved in the community.

And I think what’s really interesting from a business perspective is watching as different implementations change from one side to the other over time. And seeing how 2019, it was a commercial user, and then moving forward, they moved over to open source. Or flipping that around and going from open source to commercial.
So, it’s exciting to have that flexibility, as departments grow, or their organizations, as their needs change, as their systems change, what they might be looking for from us – it could potentially change. And having sort of an array of opportunity and avenues for them to get involved has been really powerful for us.

Difference Between End-User / Customer

Mike: What is the difference between an end-user and a customer?

Nova: I think the easiest way to say “This is an end-user.” is someone who takes advantage of open-source software in its most raw form, whereas a customer is an exchange for goods and services, where we’re willing to provide some sort of monetary compensation.

So, again, we’ll use Kubernetes here. Kubernetes is open source. If you or me wanted to go and go to github.com/kubernetes, we could potentially download Kubernetes and install it on some servers, and then try to go sell those servers that have a working version of Kubernetes running on it, with some sort of service agreement. But there’s nothing that’s really preventing us from doing this.

And in the same way, other folks who have been contributing to Kubernetes for years and maybe even were, like Google, the original creators of Kubernetes, they have both the open-source avenue as well as the more commercial avenue. And I think you see that with tools like how GKE is Google’s Enterprise version of the open-source software that you could go download for free.

Who Ideally Would Join the Falco Community?

Mike: So, if you could see more partners join the ecosystem, what kind of partners would you like to see join the Falco community?

Nova: Honestly, I would like to see the security industry come together and start working together as a community more and more. Like I mentioned earlier in the interview, moving to security, I had to relearn a lot of things. One of the things that hadn’t really been in my career up until recently, after joining a security company, was this concept of very strict competition, and this concept of, if I have some piece of intellectual information, I’m going to kind of withhold that. And that becomes part of our IP and what we have to offer. And I think we saw the same paradigm infrastructure in Cloud

And, ultimately, if you look at the security industry, following applications, following infrastructure, following DevOps, it’s ultimately in my mind going to end up in the same way, which is the industry coming together and realizing that it actually makes more sense for us to work together on something that it is for us to fight each other.

I would love for more folks, whether their security vendors, or security consumers, or even just users of security tooling, at the end of the day, to come together and start exploring different ways of securing systems, and open-sourcing, and collaborate on that.

Is Open Source Security a Trend?

Mike: I think that’s actually true. I remember speaking with Michael Howard from MariaDB, and he mentioned to me that – I don’t know if it was on the interviewer or after – security software is not inherently open source that normally it would be commercial, proprietary, licensed, all the above, to keep it closed. And so, I do think it’s the idea of, there aren’t tons of open-source security tools, so, are there other open-source security tools that maybe you can identify that you can think of this as a trend, or is Falco really at the forefront of this?

Nova: I think – and if I get too often with ranting about security, please, please feel free to stop me – but I think if you look at security, having a holistic approach to two main categories is really what you want to see, when it comes time to taking security seriously and fully locking down a system.

So, I think to give a really simple example of this. If we look at solutions like Kubernetes RBAC, which is role-based access control, just describing who can do what, and when, and how they can do whatever it is they’re trying to do. And potentially rejecting requests if they do not meet whatever criteria you set forth.

But we also see this in Linux with things like Seccomp and SELinux. And it’s this idea of, we’re going to try to prevent somebody from doing something if they’re violating some sort of policy we have in place. So, there’s other CNCF tools like open policy agent as a great example here. There’s an open-source tool from Microsoft called Gatekeeper. That is an implementation, a concrete implementation of open policy agent. That attempts to effectively do the same thing pod security policies do, and Kubernetes, but from concrete implementation of OPA or open policy agent.

But, again, we’re in the situation where these solutions, everything I just mentioned, all attempt to prevent somebody from doing something that they shouldn’t be able to do. Or to prevent some application from doing something that it shouldn’t be able to do. But if you look at the history of security, that’s only part of the story. One of the things I’ve been saying that I really feel like it’s a powerful statement is, at the end of the day, there’s no such thing as perfect software.

Even Linux, the most well-known open-source operating system in the world, the largest open source project in the world, we still get CVEs, there’s still exploits. There was Heartbleed, there was a handful of critical CVEs that have happened in my lifetime. And those are fundamentally never going to stop. And anomalies and things that you aren’t expecting are fundamentally never going to stop.

So, I think having this preventative side of things that you see with tools like access control and policy enforcement, running those in concert with tools like Falco that are more of a detective side of things really gives you like your kind of coming at the problem from two different fundamental perspectives, which kind of I wish you to double down on your security approach.

So, short answer, yes, we see a lot of other tools, but we don’t really see anything that’s as focused on runtime detection, has to do with something say like Falco, or maybe even Wireshark, which was Loris’s original project.

How Can Companies Adopt Cloud Native?

Mike: So, you’re the author of an O’Reilly book on Cloud Native infrastructure, which I just ordered?

Nova: Thank you. You should buy several copies of it, for all of your friends and all of your family.

Mike: Makes a good Christmas present. But this is a very new knowledge domain for enterprise IT staff, and reading your book is a good place to start. But I’m wondering if you have any more thoughts on how companies can get up to speed on Cloud Native infrastructure?

Nova: I think the book is a good starting point, but more importantly one of the things that I really want to stress with folks, to really have an understanding of what this phrase “Cloud Native” even means. And you can go to cncf.io, and they actually have like an entire essay that was put together that attempts to define what Cloud Native means to them.

But I feel like it’s kind of like a personal choice or a personal journey you have to go on. It’s like buying a car. Ultimately, at the end of the day, you’re going to buy the car with the features that you need, that you like, but that whole process starts with, doing test driving things, and doing research, talking to people, and going to look at cars, and spending time understanding why this car may be better in this situation or might be better in this situation.

And I think Cloud Native infrastructure follows the same paradigm of, you have to look at the ecosystem as a group of resources. And you can take these raw resources that are available in the ecosystem, my book included, and those raw resources become part of what you would use to potentially build out your finalized system.

What To Look For If You Want To Join an Open Source Project?

Mike: A couple last questions about your experiences as a veteran of being a part of open-source startups. If you’re looking to join an open-source startup, what would be some of the things you would look for that would be good signs that this company knows how to use open-source as part of their business model?

Nova: I guess there’s two answers here, coming at this from somebody who’s — I’m in a very senior, very high visibility role, here at Sysdig, so I almost wanted to join a company that needed some guidance and needed some help. If I was to join a company that was perfect and open-source was already solved. You know, they were already doing everything “by the book”, it wouldn’t be very interesting or exciting for me, and I would hope that they would not be as interested in having somebody like me come in. And for lack of a better term, do what I do best, which is helping to drive open-source adoption and collaboration.

For me, I wanted to find something that had opportunity to grow, and had opportunity and potential for us to move into really, really great things. And I felt like Sysdig was that perfect intersection of high potential with the right place at the right time with security.

Now, if somebody isn’t as insane as I am, looking to get involved with something that’s going to be a lot of work and a lot of effort, I would say the first thing I always look for is, how are decisions made, both at the company, both on your team and both with open-source projects. And another thing that I always kind of view as a red flag is this concept of open-source announcements.

If you think about it, an open-source project by design should be open to the community, you should be able to go, and read, or watch, or listen to the decisions that are made, the features that are driven, the choices that the community is deciding on. And you should be able to at the very least observe these, and if not, potentially shape and govern these things.

So, anytime I see somebody doing some sort of open-source announcement, to me, that’s just evidence that it wasn’t an open-source project to begin with. That it was built behind closed doors, and then ultimately, hand it over for the sake of publicity, and not originally built in open source, as you would see with a lot of the other CNCF projects, like Kubernetes, like Hellman, like OPA, like Falco.

Advice For Open Source Entrepreneurs?

Mike: Last question about open-source entrepreneurship. So, if you were in the shoes of an entrepreneur who wanted to use open source as part of their business model, do you have any advice for that entrepreneur?

Nova: Get in there and roll your sleeves up. At the end of the day, open source is, you’re not going to have that first-class experience of, “Click here, put in your credit card number, and then poof.” Everything works like it’s going to take understanding what’s going on, it’s going to take contributing to the code, contributing to the project. And you’re really going to have to accept the fact that you are just as responsible as the open-source project as everyone else working on it.

Mike: Nova, thank you so much for joining us today – first guest of 20/20, yay! Thank you so much.

Nova: Thank you. It’s been really nice talking with you.

Closing

Mike: Special thanks to the Sysdig team and Amanda McKinney, 280blue, for helping to coordinate the episode.

The link to the presentation that Nova mentioned can be found on the episode webpage on opensourceunderdogs.com. Transcription by Marina Andjelkovic.

Music from Brooke for Free, Chris Zabriskie and Lee Rosevere. The podcast Twitter handle is #fosspodcast.

I have a big announcement: I just found out that my talk about the podcast was accepted to OSCON in July. If that happens, I’m really looking forward to sharing some of my thoughts on what all these episodes mean.

The next episode features the current CEO of Puppet, Yvonne Wassenaar, who brings us up-to-date on Puppet success in business models. Don’t miss it.

Until next time, thanks for listening.


Episode 42: EnterpriseDB, Collaborating with the community to make Postgres enterprise ready, with Ed Boyajian, CEO

Ed Boyajian, CEO joined EnterpriseDB and helped it pivot from a small organization, to one of the leading Postgres database companies. The company has figured out how to run a profitable business, while embracing and respecting the community and open development process that has formed around Postres for more then two decades.

Episode 41: Apollo GraphQL, revolutionizing how developers write modern applications, with Geoff Schmidt, CEO and Co-Founder

Geoff Schmidt, CEO and Co-Founder of Apollo GraphQL, says you don’t get to pick your business model, you get to pick your problem. As part of the team who authored one of the most popular monolithic JavaScript rapid application development frameworks, MeteorJS, Geoff describes how they applied their experience to address an even bigger challenge–how to build more flexible backend data services.

Episode 40: Pivotal, enabling enterprises to manage a unified multi-cloud software infrastructure with James Watters, SVP Products

James Watters, SVP, Products at Pivotal Software, is a veteran of the unix and open source software business. With a broad breadth of products, including Java Spring and many other essential tools for developers, Pivotal has built a business of enormous scale in record time.

Intro

Michael Schwartz: Hello, and welcome to Open Source Underdogs. I’m your host Mike Schwartz, and this is episode 40 with James Watters, SVP of Products at Pivotal.

Pivotal is probably best known for the success of Spring, the most popular way for developers to write Java applications, but they built a great business around the Pivotal platform, which enables large businesses to manage a unified, multi-cloud software infrastructure.

Pivotal is a little different than your typical open-source startup. Spun out of EMC and VMware in 2012, and IPO in 2018, and shortly before I recorded this episode in August of 2019, VMware announced the definitive agreement to acquire Pivotal, a combination that’s expected to close in 2020.

James makes the case that open source is winning because it’s innovative feature-rich and enterprise-ready. He has a deep understanding of both the technical and business mechanic that make open-source companies tech. I’m sure you’ll enjoy this interview, so without further ado, here we go.

Pivotal Background

Michael Schwartz: James, thank you so much for joining the podcast today.

James Watters: Great to be here, Mike. Hi.

Michael Schwartz: So, you were trying Pivotal in 2012 when it was formed, and for the listeners who don’t know the backstory, maybe you could just drive a little bit about how that came about, and perhaps about how it’s coming full circle to some extent.

James Watters: I was fortunate enough to join a open-source research and development team at VMware in 2010, working on an open-source project named Cloud Foundry, and we didn’t really know what it would become as a business. It ended up, they decided to spin that out along with another open-source project called Spring Source, or Spring, into its own company, and that was one of the foundational product elements of the company called Pivotal.

Michael Schwartz: What’s your current role with pivotal?

James Watters: I’ve done a lot of product work at Pivotal. I’m currently SVP of Strategy, focused on new parts of our product. I’ve been focused on things like streaming, container-as-a-service, function-as-a-service, all the emerging areas of our product.

Size Of Product Team

Michael Schwartz: Just to give everyone a sense of the scale, could you give a rough estimate about how many product managers are Pivotal, and the total size of the product team?

James Watters: It’s pretty expensive. There’s hundreds and hundreds of engineers that work on the platform at Pivotal, and I would say 50 full-time product people working and supporting them.

How The Product Management Has Changed In The Last 15 Years

Michael Schwartz: When you were at Sun a while back, you were a product manager of Solaris, which is a pretty epic assignment for those of us geeks who revere Solaris. Since then I’m wondering, could you comment about a little bit about how has been an open-source project manager evolved? Like, what’s different now?

James Watters: That’s a great question. The cycle time was so different on Solaris. And that was an 1100-person engineering team. And then, on the kind of customer-facing product front, I think we were under 10 people. It was very much engineering organization, product provided a bit of input and amplification of key customer themes. We worked on often multi-year release cycle.

In the new world of open-source, the community input comes so fast. It’s a different release cadence. Our core platform PCF at Pivotal, we released every quarter. And that was a big mindset change for me versus some of the older world at Sun. It was just how fast everyone expected you to respond. It’s not uncommon now to meet with a client. And in a matter of weeks, we will have a feature changer update shipped to them.
It’s a completely much more iterative world of continuous delivery, both at the platform as well as what we’re trying to inspire our customers to do for their end users. So, I think that’s dramatically changed since.

How Smaller Organizations Can Improve Product Management

Michael Schwartz: If you’re not Sun, you are VMware Pivotal, but you are so much smaller. Do you have any suggestions for some of the little things that you can do, or that it open-source company might do around product management?

James Watters: I think that’s really opening a question, and I don’t want to speak conclusively on it, but I think what I’d say is, there’s kind of two ways of coming at it. And my specialty is always being understanding the enterprise organization that the product fits into.

There was a point in our journey, where we felt adding additional features around security would probably be neutral to the developer audience that was using the platform, but what actually bring like the chief security officer and her team deeper into the conversation.

Suddenly, we approached a few banks, and we said, “What if we could rebuild this entire platform infrastructure every day for security?” And we had a really brilliant product person at the time named Justin Smith, who let this initiative to articulate the idea of the much more ephemeral approach to the platform.

I think the reason I mention this is, you could have gone deeper on just developer experience, but by finding that other constituent in an enterprise that come to the negotiating table around why we’re giving money to this company, that really changed the game for us and a few clients, because the chief security officer was now also an advocate.

I think it’s challenging you doing open-source products because you might get a lot of feedback from your immediate community and immediate users. But in order to sell the products to a larger organization, you need to think about articulating investments to a broader set of constituents.

Pivotal Products

Michael Schwartz: You mentioned PCF for Pivotal, Cloud Foundry. For those who don’t know, maybe you could just tell us a little bit about what that is, or also walk us through some of the other product offerings at Pivotal.

James Watters: I’ve been fortunate enough, Palmer at VMware hired couple of Google engineers in 2009-10, to come build this platform out. It was really like what you might call the Cloud Native platform world today.

At the time, there was no such thing as container-as-a-service, and at the application level, there really was no micro-services, and continuous delivery was sort of a very radical idea of enterprise. It was sort of the first platform built with the container first design, built to enable continuous delivery of things that look more like micro-services than monolithic applications.

And kind of was the first investment in this Cloud Native space, in terms of application platform and culture, all coming together in a platform.

That was really what PCF did, and we were able to scale it from zero sales in 2012. Or the spin that was first contemplated to hundreds of millions of dollars in sales, and ultimately the background of a public company.

Market Segmentation

Michael Schwartz: Cloud Native is a broad horizontal market. Do you segment the market at all by vertical industry or use case?

James Watters: This is another thing around products. For me, products strategy is that I do think that vertical use cases are critical. I’ll give you two examples. In the banking world, there is a huge focus on Java, because it’s traditionally a Java-centric custom application world.

Banks were always willing to invest in the high-end applications that often was built by Java developers.

When I first started and till this day, banks are, I would say, the number one language in banking is Java. They are very security-centric, they operate in a highly-regulated world, and they tend to be very hybrid cloud. There’s very few banks that run public only.

They were a tremendous fit for the design of PCF, both from support for Spring Boot as well as its core security differentiation.

We absolutely thought of a lot about banking, insurance, regulated industries. Then, manufacturing and industrial was a little bit different space. There you had a lot of the IoT world, you had streaming data, you had a completely learning how to build software for the first time way of engaging, where industrial companies were just getting started on major software investments.

I definitely think about vertical segmentation. I think for anyone who’s contemplating a sort of customer first approach to product thinking, vertical segmentation is a good early model to take on.

How To Decide What To Open Source?

Michael Schwartz: Pivotal has 73 projects in GitHub, and I’m sure that there’s more in private repositories – how do you decide which projects to open-source?

James Watters: I think, by and large, we tend to be an open first-style company, as I mentioned on the Andreessen Horowitz podcast awhile back, I am an advocate for sometimes keeping the UI, closed-source can be a simple way of differentiating between the pure-community efforts and the final enterprise products. But in general, we’ve tilted towards open source first.

That’s also been a key part of our relationships, like I mentioned, with certain banks.

A lot of the core security infrastructure of the platform was all kept open source, because the banks felt more comfortable consuming a platform that was opened first, even in those core areas.

Value Prop

Michael Schwartz:  When you have a lot of projects, is it difficult to position the value proposition of the company?

James Watters: That’s a great question. If you think about how many projects you want to take on, like say, MongoDB is a fairly focused company. One core thing, Elastic are fairly focused company, but you get into the platform world, companies like HashiCorp are very successful at doing multiple projects. I think Pivotal is probably one of the broader breadth open source company is out there, certainly Red Hat has a pretty broad breadth. You hit a point where you become the platform provider of choice for their next generation of design, and actually the pressure comes to do more and more and more.

One of the biggest pressure points for us was always like, “Okay, we love this as an application platform. Now, provide us the whole universe of data services on the platform.” And so you have to achieve a certain critical mass to have the scale to invest like that.

But I do think that in enterprise segmentation, it’s powerful when you can start to have people accept the offerings you do have. And then, the biggest pressure is, “And now add this, so I can have one coherent approach. And I think that that’s something really important for open-source companies to think about it. Like, “Look at how Amazon operates. They are not a federation of hundreds of little hosting providers all coming together. They really have that sort of single point of interface to all of their abstractions.

I think that’s an interesting dynamic in the world right now. Open source is like, how broad you should go in your portfolio, do enterprise buyers favor that, is it better to be lower and single products – that’s something we discussed.

Pricing

Michael Schwartz: With a lot of products, containers, Cloud Native services, it seems like it’s harder than ever to figure out how do you price. There’s more things you could gate on and the more elasticity is given, I know us, at my company Gluu, a lot of challenges because of CPU that depends upon the time of day. Can you talk about the evolution of pricing, and did you get it right initially, or did you have to make some tactical adjustments along the way?

James Watters: I think that’s a great question. I think it’s never easy or straightforward, we made a decision that we were going to go after the largest thousand companies in the world predominantly. We were going to supply a lot of technical resources to them, to ensure that they were successful with our product, and very much be an outcomes-focused company.

I think we intended to price at the higher end of the market, and that was a very deliberate choice. And I think as we’re growing now, we’re seeing more opportunity to start to segment the offer. To have a more transactional approach, we reintroduced the container-as-a-service product that didn’t have as many features as the full platform, but was something that people were ready to pay for more on a transactional basis.

I think that there is this tension between the desire to have a broader platform versus to be more transactional, and that very much comes back to customer segmentation. I would think of pricing in terms of how transactional you want to be, and then what the customer really expects out of you to make them successful.

Like, what does customer success really look like – it has to be at the core of your pricing model. If the prices are really low, and they’re not successful, that’s actually not on either of your interest.

Competition

Michael Schwartz: Does Pivotal actually have competitors?

James Watters: I don’t think that Pivotal has a company that is assembled just like us. We have some unique assets, one of the reasons we were successful in enterprises is, we have the number one way that enterprises build apps in the Spring Boot.

So, when it comes to like how enterprises are building applications in the Spring Boot, it’s probably easily the number one, and it might be over 50% market share of net new enterprise applications today.

There’s not another company that has that. We also had a very big git, and we were owned by kind of the Dell VMware family of companies ultimately. So, we’ve always been able to go to market with them, but we really still did have to earn our own way. But we could get introductions.

I think all of those things came together in a way that allowed us to build a higher-end platform to focus on the top 2000 companies in the world, and to go make them successful, and to price and package accordingly.
I think one of the challenges right now for smaller open-source companies is, these cloud platforms that are open-source, they keep adding features that are pretty high rate. So, you may think that one day, you have a company, and the next day, that’s a feature of a cloud platform. And I think that’s attention.

Certainly, in the service mesh world, you see disruption of kind of traditional networking and API management, coming in the way that people are adopting a service mesh, etc. Is that a company, is that a platform – I think that’s a very dynamic part of the market right now. It’s pretty important, and I don’t talk about it too much, but I really do enjoy working on open-source projects because they can have a breadth of impact that’s pretty unimaginable to something that you have to commit a sales transaction and for software before someone can use it.
We have an asset at Pivotal, Spring Starters, and they’re the number one way that people get started with a new job application. And that’s start.spring.io. You start a new job project there.

Every two seconds a developer on average is going there to kick off a new project.

And the top three countries for it are China, United States, and India, but these are the kind of impacts that open-source can have worldwide, deep into developer impact that you can never do with closed-source only, enterprise sale only products.

I think just the unimaginable breadth that open source can get you in ubiquity, that it can get you in the modern world is stunning. So, that’s what I’m humbled to work on. I think the challenge is then like, “Well, how do you make sure that the largest 5,000 organizations in the world are contributing to that?” And that’s where I do have a passion for enterprise monetization of open source, and finding ways of partnering with those organizations, and packaging, and pricing things, such they feel that there’s good value. And partnering with these open-source companies and making them their most meaningful platform.

I think I’ve got there two minds, number one, open source is super important just from a long-term impact the world, it’s harder to work on projects, they can have a bigger one than open source ones.
And then there is the challenge of like, “Well then, how do you build the economic model around that when it’s so ubiquitous to begin with? That’s the kind of challenge that I’m taking on, and I’m humble to be able to work on open source for enterprises for that reason.

What Types Of Software Should Be Open Source?

Michael Schwartz: Do you think that certain types of software lend themselves to being open source?

James Watters: I would say that the developer workflow today – and that’s not my line but I like it – it starts with “Git clone.” And I think any saying, where a developer is initiating a project in this era, it better be either a really easy to use API, I think Stripe certainly has proven that, or, it better be something like start.spring.io. Or, git clone, something that a developer could just go grab in a permissionless kind of way.
And Adrian Cockroft at Netflix said that, back when he was at previous companies, there were these big architectural debates for months before a project would start. And that in Netflix you really implemented the running code talks. It’s all about running code. I think that that is the reason why open source is really powerful for anything having to do with developers.

And then, on the infrastructure level, open source has become the most profound way that large vendors collaborate. If you look what’s happening in the Kubernetes community, where you have every major public cloud contributing to Kubernetes, IBM acquiring Heptio to make major contributions to Kubernetes, in infrastructure, open source has the way that these, what you might have had standard bodies before, there’s sort of like a running code way that large vendors are collaborating. Both, in the end-user developer space as well as in the infrastructure space, open source had a huge impact.

But if you think those worlds are slightly different, the dynamics of start.spring.io, which is very end-developer focused versus the way that every public cloud is normalizing how they run Kubernetes are slightly different, they’re all open source but they have slightly different behaviors and attributes. And it’s kind of fascinating to see database companies like MongoDB a little bit different than the way that the Kubernetes community is operating.

Do Enterprises Care About Open Source?

Michael Schwartz: Do you think that customers actually care about open source? I mean, large enterprise customers?

James Watters: I think large enterprise customers absolutely have seen the tremendous benefits in just frankly the innovation velocity of open-source products. And I think the biggest change is that in the early days, open source was a cheaper version available for free of the enterprise products. That’s what I think it was especially hard to monetize.

If you’re just going to be the cheaper thing and the low-cost provider, and not the premium product, a lot of enterprises might look at that and say, “Hey, we’re an enterprise, we can afford to buy whatever we need. We just really want innovation leverage, like we want the best product.

But I think there’s a new whole category of products, or there’s only an open-source player that is creating it. Like PCF was the kind of first micro-services platform in the world for enterprises. And it was built a 100% open source. It was both the market leader in terms of features and the open play.

I think the open-source market is changed, where there is room to be both innovative, or the expectation is that they’re both innovative, higher-end, feature-rich as well as enterprise-ready – all of that is expected from open source today. I think that’s where the innovation is happening.

If you look – here’s an example – Amazon has a service Kinesis, which is how they were doing messaging, and it did a pipelines. And now they’ve switched that to a managed Kafka service. They had to do that because the innovation was really happening in the Kafka community in open source. Even on Amazon scale, they couldn’t keep up with it.

I really find that to be the best part of the market right now is that you can’t out-innovate the open-source players.

Cyclicality Of Centralization

Michael Schwartz: It seems like there’s sort of a cyclicality between centralization and decentralization. For example, a couple years ago, everyone was at full tilt towards “Go to the cloud.”, and now, it’s almost like with Kubernetes and other technologies – is there any shift away towards maybe bringing more of this type of functionality in-house, and does that help a company like Pivotal?

James Watters: When I talked to CIOs about this, I tried to help them deconstruct the current cloud market, and what I told them is, “Public cloud is not one thing. It’s really three different zones of features that you need to think about. The first is the commodity layer, which is, “Hey, I’m just buying virtual machines, networking disc, the basics, and that’s kind of where public cloud started.

There, you can use a platform like Kubernetes, and run those system resources in similar ways, if not identical ways, across public-private, hybrid multi-cloud. So, I think Kubernetes has done a tremendous job of making those system resources normalized across all the clouds.

Then, I think there is this emerging space within the Cloud Native community around the open-source developer focused projects that run on Kubernetes, like Kafka, like Spring Boot, really like Pivotal’s platform. That’s where the developer innovations come. That’s like the open developer innovation community, that’s number two.

And the number three is, they selectively are these managed services like Google Spanner, Google Machine Learning, or you might be ahead of the market, where there might not be an open play there yet, where Spanner requires dedicated fiber networks between data centers to make the database magic work. So, there are areas we are the managed cloud or head.

Our perspective is that innovation in the core, where you are really arming your developers, continues to happen in open source. Commoditization can be achieved through technologies like Kubernetes running in a normalized way across clouds.

And then, technologies, like the Open Service Broker, relay to buy these managed things. Long story short, I think what’s happening is, the CIO’s are getting smarter about deconstructing cloud from this monolithic idea of “I go all in one cloud.” to like, “How do I selectively use what’s best about each cloud?” I think open source is playing a huge part of that.

Should Open Source Be Less Expensive?

Michael Schwartz: You touched on this a little bit before, about how open-source software maybe should be cheaper. I think that there is a sort of perception for some reason that even though you get more rights with the license that the software should be less money – do you think that that is changing, or is that something that is an industry we need to work on with customers?

James Watters: I’m a maybe a contrarian here, my dream was always a very open product that generated a lot of value that enterprises were excited to invest in the platform partnership in. And, essentially, I don’t think that open source should have to have cut rates levels of investment into research and development vs. closed source.

My contrarian nature there says, “If you really have the right relationships with these customers, they’re going to be just as happy giving an open-source provider money as they are giving Oracle money.” I mean, if anything, I think that open-source partnerships are valued in a more profound way in the modern enterprise that might be even happier to give you more money than Oracle.

I do think that that something is happening. That also comes back to how these open-source companies engage with these large enterprises, are they focused on them, do they understand their vertical needs, do they put security first, are they able to measure the outcomes that are achieved with their platforms?

Closing Advice For Entrepreneurs

Michael Schwartz: Last question. Do you have any advice for entrepreneurs who are starting new ventures based on open-source software?

James Watters: I think my advice would be, if you really develop a community around your open source, you’re one of the luckiest people in the world. That’s a tremendous gift. Save and invest in that community, but also spend some time understanding how that technology fits into the value chain, in the largest thousand companies in the world, and investments they are making in technology.

Try to balance the needs of the developer who’s approaching it from a ‘git clone, let’s get started’ perspective, as well as the more complex matrix or matrices of a large enterprise organization, and what they need across security, operating, certainty SLAs, etc. If you can get those two forces right, then I think you’ve got a remarkable opportunity. But I do think that monetization, and ultimately funding a great R&D team behind your open source project, takes a balance side towards both.

Closing

Michael Schwartz: James, thank you so much for taking your time today in this really pivotal moment in Pivotal’s trajectory.

James Watters: One last pivotal word joke.

Michael Schwartz: Thanks, James.

James Watters:  Thank you, Mike.

Michael Schwartz: Thanks to the Pivotal team for making this happen.

Transcription and episode audio can be found on opensourceunderdogs.com.

Music from Broke For Free and Chris Zabriskie.

Audio editing by Ines Cetenji. Production assistance by Natalie Lowe. Operational support from William Lowe. Transcription by Marina Andjelkovic.

The Twitter handle is @fosspodcast.

Next week, we have Geoff Schmidt, Co-Founder and CEO of Apollo GraphQL.

Until then, thanks for listening.

Episode 39: Rancher — A support-based business model that scales, with co-founder Shannon Williams

Shannon Williams, Co-Founder and VP Sales of Rancher lays out how a great team with deep domain knowledge can actively identify a product market fit in a crowded space, and emerge a winner. It’s an inspiring story of a plan perfectly executed. This is a MUST LISTEN episode of Underdogs!

Intro


Michael Schwartz: Hello, and welcome to the Open Source Underdogs podcast. I’m your host Mike Schwartz, and this is episode 39, with Shannon Williams, Co-Founder and VP Sales of Rancher.

Let’s go for a minute into the land of hypothetical. If I can ask all 38 previous podcast guests a question, “Is monetizing support a good idea?”, I think there would have been virtual consensus that support doesn’t scale. Except, Rancher is perfectly executing a business plan to do just that.

I hope you’ll enjoy this episode. Tweet your comments at @fosspodcast, and we will asynchronously discuss in the Twitter sphere, but for now, here we go with the interview. Shannon, thank you so much for joining us today.

Shannon Williams: Thanks for having me, Mike. It’s exciting to be here. Looking forward to our conversation.

Origins

Michael Schwartz:  Can you just fill us in a little bit about how Rancher got started and what was the mission?

Shannon Williams: We’ve been going now since 2014. In a lot of ways, it feels like we started before that, because my co-founder Sheng Liang, Will Chan and I, the three of us started another company called Cloud.com back in 2008. And, for all intents and purposes, we’ve been working together every day for 11 years now. That company was an early developer of open-source infrastructure-as-a-service software.

We built a product called CloudStack with the founding members of the OpenStack foundation. I had a really fun run there for about three years before being acquired by Citrix, and spending another three years at Citrix.

In our work on CloudStack, we learned a lot about, as you can imagine, managing infrastructure at scale, building out private clouds, helping a lot of large companies build public clouds. At the time, everything we were focused on was how do we deliver virtual machines to developers quickly from anywhere.

But over the course of working on a lot of private clouds, we noticed that we had a lot of conversations with people trying to figure out how to blend their on-premise infrastructure with this growing amount of cloud infrastructure.

One of our early customers was GoDaddy actually. They were looking at building a public cloud, and Darren Shepherd, our fourth co-founder of Rancher, was a Chief Architect there. We got to know Darren really well.

We started talking in 2014 about what could be done to bring together the on-premise infrastructure, the cloud infrastructure, into something that overlaid it all, and to really allow people to treat infrastructure like Cattle, like a disposable commodity. And Docker was just getting started, the concept of Containers was emerging, and we thought there was a really cool opportunity to look at leveraging that, to build out management tooling, infrastructure services, and kind of imagine the next generation of infrastructure management, which would hopefully enable people to do computing anywhere, with really consistent deployment experience, management experience, monitoring experience, all these types of things.

And so, Rancher was born. For almost 5 years now, we’ve been working on continuing that journey, how to build open-source products that are available to anyone, and really allow them to run workloads anywhere. So, that’s really where we came from.

Value Prop

Michael Schwartz: This market, it’s really diverse. There’s a lot of tools and tooling in this area. I’m wondering, what’s the exact value proposition for Rancher service?

Shannon Williams: Rancher is open-source software, we have a number of open-source projects but our most famous is called Rancher, and it really sits at the management playing around Kubernetes. Organizations use Rancher because they are deploying and managing more and more Kubernetes clusters.

Rancher provides distros of Kubernetes. We have one called RKE, which is a pretty typical, upstream distro, it’s really good for deployment, automation. Then, we have one that’s optimized for the Edge or other low-resource utilization called K3s.

We provide distros of Kubernetes to people that need to run Kubernetes, but Rancher itself actually sits above those distros, it’s the management client. What’s cool about it it’s really distro agnostic. It actually manages any Kubernetes. And by managing, what that means is an organization implements Rancher so that they can deploy and control, and then grant access to dozens or hundreds of Kubernetes clusters – some running in the clouds, some running as hosted services like GKE, and EKS, some running on premise, maybe on the Edge.

By bringing all those clusters together, what Rancher allows them to do is, dictate policy, control access, monitor availability, manage deployment of applications, manage catalogs, attach additional open-source services, like Prometheus for monitoring, or Fluentd for logging, or Istio for service match, and so, Rancher sits at that next. So, how do I manage Kubernetes everywhere according to my organization’s policies.

By doing that, it enables them to then really deliver their service reliably. For organizations, they think of Rancher as the Kubernetes platform, it’s Kubernetes as a service, it’s how they deploy apps and run anywhere.

Monetization

Michael Schwartz: The Rancher GitHub repository has 14,000 forks, which is really a lot. But there’s only around 60 something developers, which I could see is probably primarily being the people in your organization – can you talk about the relationship between the open-source project and the activity there, and the SaaS service?

Shannon Williams: Just to be clear, we don’t offer a SaaS service. Rancher is open-source software only. We only provide open-source software that people use, but what we sell is support for those open-source projects.

On any given day, there’s about 30,000 teams around the world running Rancher. Those teams, they may be a smaller group that’s deploying it for one application. There’s maybe somebody doing a Dev lab, or test lab, but of those about 1%, about 300 enterprise customers, these are companies that deploy Rancher, and whatever they are running on it, it’s critical to their business.

They contract with us to provide enterprise-grade support for Rancher, RKE, K3s, and really their whole Kubernetes stack up and down. By providing that Enterprise-grade support, what they get from us is the confidence to run really important workloads on the open-source Rancher, but what they like is that we don’t have your classic open-core only model, we don’t sell version that’s different to them. They just pay an annual support subscription, and they use it.

A year later, if they are no longer using it, they are not paying an annual support subscription. They can keep using the software, but they would be using it again without support.

Our model is geared around helping organizations that need support, get the best possible support in the world for Rancher, Kubernetes, Prometheus, and Istio, and all the pieces of technology that we deliver to them.

Why Open Source?

Michael Schwartz:  Has open-sourcing the code really made a meaningful contribution to the company?

Shannon Williams: It’s at the root of our success. By open-sourcing the code, we enabled a startup with relatively no name recognition obviously, to come into, in a lot of ways, it’s a very crowded market.

Think about the companies that are dealing with application management platform as-a-service. When we started, you can imagine Docker, Mesosphere, Red Hat, Pivotal, these companies were already out there. You know, Docker, in their sense with having released the Docker project, orchestration and building different types of management tools, and with enormously more funding than us, much, much, much bigger brand recognition teams.

We had to find a route to market with limited funds, we needed to let our product be our best piece of marketing, and so we took that approach. We believed in this for a long time. In our last company, we had a very similar approach. We made Rancher fully open source and free because we felt that it was the best way to get adoption, to plant seeds in organizations that would need this technology.

By putting it out there, we really bet on two things. We bet that people would like it, and that they would want to use it, but we also bet that this technology was crucial. And that at least a good chunk of people who use it would find value in getting support for it and find value in having SLAs that they can rely on for that application. And we’ve been thrilled. I mean, our company’s now almost 200 people, we’re more than doubling this year. In terms of revenue, it’s really worked out really well.

People really do love Rancher. It’s something that makes me really confident with the model as you have to believe in your engineers, you have to believe that products can be great. We also spend an enormous amount of investment of time working with our open-source community. We have a huge Slack community of thousands of users who come in with suggestions and ideas on how to make the product better. We get thousands of issues, and feature requests, and bugs filed by the community.

I don’t think we have more of a user community then of a contributor community. I love it because they come to us with real problems that need to be solved, and I identify them. Often, their use cases sometimes are pushing the boundaries that we may not see out of a Fortune 500 company that’s using Rancher. So, it all sort of pushes forward with the hopefully creating a great product for everyone.

More On Why Open Source…

Michael Schwartz: So, just to sort of dive a little deeper on that. If you made the software commercial tomorrow, do you think the 300 or so Enterprise customers, who are using the software, do they really care about it being open source? Or is it just a non-sequitur, or they just want the best software? So, if you made it commercial tomorrow, do you think that that would be bad from where you are today?

Shannon Williams: Yeah, I do. When I talk to organizations about our business model, they get really excited because there isn’t one of them which hasn’t been in a position of really limited leverage against their current vendors. Everybody has been staring at just massive renewal orders.

We closed, just this quarter, today is the end of our third quarter, and we closed three deals with organizations that are spending a lot with us, half a million a year in recurring revenue, for example, to support environments. And their frustration in some cases was platforms that they had built, PaaS platforms, where the cost had grown exponentially. And they just had no ability – even though these were all based on open-source, they weren’t themselves open source. I mean almost everything is based on something, open source at this point.

What people really like is, they like an open-source product, because they always have the option to leave it there, let it run, support it themselves, hire some engineers and figure it out. In the end, if you are running a proprietary tool, and you don’t pay, you have to yank it out of production. And that is impossible for most companies.

I think our business model, yes, some people would still buy a Rancher, and be fine with it, but I think a lot of the smartest CIO’s I talked to are really excited to see a company like us, that embraces open source for commercial purposes, provides really good support, and is committed to building open-source products. For us, it’s allowed us to grow faster than any other approach I’ve been able to come up with.

Pivot To K8S

Michael Schwartz: Seems like Rancher made an epic pivot towards Kubernetes at some point, I guess, fairly recently – what did you learn from that process?

Shannon Williams: Well, the hardest part about getting into any market is making bets, and then figuring out where they come down. Rancher started about the same time as Kubernetes. Right around 2014, Kubernetes was starting at the same time we started our company.

At the time, we really thought Docker and their Swarm and stuff were probably more likely to win out. They had so much momentum. But it only took a year to realize that Kubernetes was actually really well-built piece of code.

So, when we first started working with them, we were kind of thinking we would be managing Swarm clusters and Mesos clusters, and then, even before we launched our 1.0, we decided to support Kubernetes, because it was a really good piece of software.

So, we released our 1.0, our first product to the market in 2016, Rancher 1.0, at the time, if I was talking to them, I would have said something like, “You know, it seems like different companies are choosing different orchestration approaches to containers because they need different things from them.”

Some people want to scale really big, like Twitter. So, they’re using Mesos, other people really focused on the developer experience, and they’re choosing Swarm. And it wasn’t really clear yet that one standard was going to emerge, but what we started to see was some stability issues with some of the other orchestrators that we saw as a manager. It was like, “Ah, these things aren’t stable as I would have expected them to be.” What we found is that Kubernetes is really reliable.

So, as we imagined our business, and trying to support these technologies and helping companies implement them, we felt like it was safe to bet on something reliable, and that did require pivot that moved away from messaging, and product development had gone into supporting, we built our own thing, we had Swarm, we had Mesos, we weren’t really sure what orchestration was going to take off. But as we got more comfortable with Kubernetes, and luckily, we started working on it early, it made it really easy for us to honestly commit to something we liked.

By that point, by 2017, we were all in on Kubernetes building on that. And since then, we already had a lot of people using it in our 1.0 product, we also had a really nice base installed, we didn’t just lose.

So, a lot of times, you have a pivot, and it means almost starting from scratch. But actually, we didn’t really lose hardly anyone because it was very much in line with the direction that most of our customers wanted to go as well. Even if they maybe chose a different orchestrator, they also saw the market going this way, so they were really, really appreciative that we gave them a path to get to Kubernetes off of maybe something else they had chosen when the market was still a lot less clear.

We found that that wasn’t nearly as big a problem. Now, what is hard in pivoting, especially, one of the things we built was our own orchestrator called Cattle, and one of the hardest things was actually convincing our own engineers that the Kubernetes was actually superior to what we had developed ourselves.

That’s a hard thing to do because no matter what, if you built something, you’d always love it. And at the same time, in an early market like we were in, lots of people loved the thing we built, a lot of people telling us, “Hey, we really like this Cattle. It’s really good and you should just keep improving that.”

But as an entrepreneur trying to build a business, you have to be really, really honest with yourself, and you have to really look at all the signals, not just the ones that maybe are giving you the positives you want to see.

All the signals told Sheng, and I, and Will, and Darren, that we needed to really focus our business on solving the problem that we thought most organizations were going to have. And that was, how to take Kubernetes to scale, how to bring together a really complex ecosystem around it, how to build a platform that would work.

That meant really having long conversations with our engineers, convincing them if they weren’t excited about this, that maybe there are other things they could work on in our team and finding the team focused on doing this.

It worked out great, but it was not trivial. We have a small team, I can only imagine when you see big companies today trying to pivot to Kubernetes, you’ve got years and years of customers install base, and how difficult that might be for them.

Pricing

Michael Schwartz: Great. It takes a lot of leadership. Most sizable organizations are using Containers today, so if you can sell to anyone, it becomes sort of challenging, so who do you sell to? I’m wondering, do you segment the market at all?

Shannon Williams: One of the nice things about open source is, it has allowed us to, give an idea most, I would say the 300 Enterprise customers, like every quarter now we’re closing about 50 new customers. Every quarter we are closing, we look at what the source of those are. I would say 30 of the 50 came from open-source Rancher users.

They started with open source, they used it at a business-unit level, or line-of-business level, and it became important to them, and they needed support. Those deals, they are not very competitive, they’ve already kind of looked at Rancher, they have a relatively short sale cycle, they’ve done the proof-of-concept – we don’t have to go in and prove that Rancher is the right solution for them.

What we found is that we don’t really need to segment that. The product pricing was probably the most important thing to segment. We did find that with such a huge install base, one of the mistakes we couldn’t do is, we couldn’t support everyone for free, for a small amount of money. We needed to kind of keep a relatively medium-sized bar, to ensure that people who needed support had to make an investment to get it.

For example, we could have gone with a lot of SaaS models, $10 a month or something like that, but the reality is, infrastructure and Containers, Kubernetes – these are all really complex. The support is quite real. We provide a lot of advice, a lot of architectural help with these organizations doing it. So, there was a real risk that we would price the product so low, and that we would then be trying to do this for lots of companies with very different levels of technical skills.

I’d say, the closest thing we came to segmenting the market was providing a lot of free open-source support for people who are trying to figure it out themselves, but then, charging a reasonably significant fee to come in and get support. Our customers had to invest tens of thousands of dollars on an annual basis to get support with us.

By doing that, it allowed us to work with companies that really valued this. We’re investing their time and the money into making it successful. That was really the best qualifier. It allowed us to focus on teams that really could help us grow the business at the same time.

We’ve seen some industries become really big with Rancher, but it’s more just a sign of who uses Containers. It’s companies, and certainly the internet, and the technology industry, but there’s a lot of financial services, companies, fintech companies, biotech companies, universities, research organizations, we’re seeing adoption in government and military use cases. It’s really broad now.

Retail, Edge’s driving, all sorts of interesting use cases, oil and gas, all sorts of interesting use cases in manufacturing, automotive – just lots of cool things that people start to imagine, a model where Kubernetes becomes this grand unifying theory for computer, where it runs everywhere. It runs in their single node, base station, it runs out in the windmill farms, it runs in Chick-fil-A shops, it runs in factories, it runs on cruise ships, it runs in data centers, it runs in the cloud. It’s a really exciting time to be working on tech, I would definitely say that.

Pricing To Value Ratio

Michael Schwartz: Normally, it’s really hard to get pricing right. Did you have to pivot your pricing model a couple of times? Or how was your experience like, figuring out what are the right price points?

Shannon Williams: Oh, man, that is a good one. We learned a lot from our last company. I made every mistake you can make last time. This time, we definitely had to pivot a little bit to be quite sure what the right element was to scale on with the number of clusters, or containers, or nodes, or CPUs, or things like that, but we decided pretty early on that the size of the implementation was probably a good way to judge how the cost should change from a small deployment to a large deployment, the number of hosts and servers, things like that.

Actually, I would say we learned a lot, we’re fortunate, that were a lot of indicators from the market, as people talked to us I would say. Your first 10 – 20 customers give you a lot of feedback on pricing, whether you want it or not.

Usually, I think most people price to low, just by nature. We all want to just make it both amazing and cheap prices. Like, who wouldn’t love this thing? It’s the best and it’s the cheapest. But you have to be realistic about what it takes to fund a business, what it’s going to take to build a profit, and what you can do with those engineers you can hire, and then you have to convince people of the value. It can be tough.

I remember I walked away from a lot of deals in open source. I just said, “I’m sorry. I totally appreciate that you’re telling me you could use the software for free, so you couldn’t possibly pay me more than $10,000 or $20,000. But if I did that, I wouldn’t be able to build a business, I wouldn’t be able to write open-source software, and I wouldn’t be able to give you the level of support you demand from your other enterprise software vendors. So, I’m sorry, we can’t do business with you.”

And sometimes they come back, sometimes they don’t, but being willing to walk away from deals – for our business model, it is absolutely critical to have to be able to do it. Otherwise, again, the car I’m selling you is available for free. You can take the same car with the exact same features, you’re not paying for a special version, it doesn’t have a better horn or better tires –it’s the exact same car. What I’m offering you is the confidence of working with me on it, and the world’s best support for that technology. If you don’t value those things, then, we can’t come to any business relationship between us.

Technology Partners

Michael Schwartz:  Have you used partners to help you deliver to customers, especially globally? Or are there any other business partners that have been important for you to build a business?

Shannon Williams: Yes, yes, yes, yes. Over and over again – yes. The critical partners for us have been really two big buckets. We have found that the other companies who are building critical technology for teams adopting containers. It’s a company that’s called Portworx that builds a really nice storage, and a company Aqua that builds great security, Sysdig who creates monitoring, Gitlab who does really cool tools for CI and Git deployment – all really commonly chosen by our customers.

But partnering with those companies, companies that fit into the same solution stack, we have been able to do two things: we’ve been able to build a much more credible solution for our Enterprise customers. And we’ve been able to align messaging and go-to-market together, and take maybe a couple of other organizations who are our size, venture-funded startups, and take our stories, and show them to larger organizations together.

And we would’ve done this through, we’d run online meetups, where our partners come and present to our users about their technology, and how they work with Rancher, and how they work with Kubernetes. That gives us a lot more credibility, and helps those company succeed, which helps the market grow because the market is vibrant. So, we invest a lot in partnering. We’ve also partnered really closely with the cloud providers.

We work really closely with Amazon, Google, and Microsoft in the U.S., and large providers around the world, to ensure that their implementation of Kubernetes works really well with Rancher. And that’s been fundamentally critical, especially because what we see is we see a market where, if you are in the cloud, you are probably going to use the cloud providers Kubernetes.

So, we want to make sure that we’re not trying to convince you to use Rancher’s Kubernetes on Google, take Google’s Kubernetes engine, which is great. Let us provide you with the common frameworks, whether using Google’s in Google, and Amazon’s in Amazon, on premise and Edge, or different types, everything is consistent, everything is managed the same way, everything is deployed, monitored, upgraded consistently. And you have a platform that really is this UberCloud we set out to build in the beginning anyways.

Integration Partners

Michael Schwartz: If a customer says that services aren’t enough, they want on-site engineers, they want sort of higher-level design consulting – do you do that as expert services, or do you work with delivery partners to do that?

Shannon Williams: We tend to work with delivery partners. We work really closely with both big and small delivery partners who had built expertise. In Rancher, we have a platinum partner program, which is made up of some amazing companies that have implemented Rancher for others multiple times, and really have deeper understanding often not just of our ecosystem.

So, companies like RoundTower, CloudOps, Readapt, Accenture. We work with quite a lot of the large multinational services companies. We work with different regions around the world. These companies, BoxBoat and other really good ones, these guys, they’re really staffed to provide ongoing services for organizations in a way that we’re not.

Like, we are great at coming in and giving you a ton of information about Rancher and helping your architect your Rancher deployment, but a lot of times, technology is only a chunk of the solution. The solution needs to include some transformation of how you do things, how you do DevOps, how to train all your developers around microservices, how they start thinking of some of these new service matches, and how they might get into solving business problems for your company.

We can point you in the right direction and help you with those things, but we’re very laser-focused on the Kubernetes platform. And these companies are much better than we are at providing the transformational experience around there. So, yeah, we very much partner, especially in those longer-term things.

What we have found as really critical is the actual investment of our own on customer success. I would say, one of the things that’s got a lot better as we’ve grown is, we’ve invested more and more in — I think it was like the first 90 days when an organization becomes a Rancher customer.

I think this is really important for open-source companies because if you are a SaaS provider and somebody’s using your product, you have a pretty good idea what they’re doing with it. But as an open-source software companies, especially ones that support that open-source software, organizations can have very different processes, they may have more or less mature implementations, they may or may not have built-in an HA deployment. And they’re coming to you to provide support. You really need to make sure they understand best practices, that you reviewed their deployments, you helped them understand how we recommend doing things.

We invest a lot more now in customer success than we did in the early days. When a customer comes on board, we really spend a lot of time going through their architecture, helping them make improvements that they will achieve their goals, whether it’s stability, multi-cloud implementations, or they might try to do something, there’s a lot of scale. And then, there might be something we’ve learned already that can help them. I would say customer success has been a big learning for us.

Net Retention

Michael Schwartz: Has that investment in customer success also translated into increased revenues per customer year-over-year, so they’re buying more, or other products, or other divisions?

Shannon Williams: Well, it’s still new enough that I wouldn’t say if I know how correlated those two things are, but we certainly believe they are. We are investing in it because our bet is helping a customer be successful, with even a departmental implementation or a single app deployment is going to pay dividends for both retention of that customer and that workload.

So, a year later, when they decide they want to renew that support they bought last year, they have a really good feeling that, “Yeah, that was a great investment. Partnering with these guys has been useful.”

But certainly that also works internally. As they use it, they seem to spread the word. I mean, we have seen over and over and over again the power of the success of a Rancher deployment spreading within a company.

Users love Rancher. It’s a user-oriented product. What’s so cool about a product that has 30,000 open-source users is, it says something about how usable it is. It’s like terraform, you use it, it’s pretty straightforward, you like it and you go, “Cool. This is easy. I can get this.” You tell your friend, “You should use terraform. It would help you do something.” It’s kind of same with Rancher.

If all those users are using it, they are clearly getting some value from it. When somebody in your company says, “Hey, use this.”, and you’ll probably benefit from it. And there’s no barrier. I don’t have to start by going and getting a license to try it. I can just use it. It tends to spread the same way. It’s just the word of mouth and the power of it kind of spreads.

So, we found that making them successful and making sure those early champions are well-armed to explain why they chose Rancher, and they got a really good implementation, they don’t get bitten by a bad config, or maybe not knowing the best practices, it helps us in the long run for sure.

Cloud Strip-Mining

Michael Schwartz: I’m sure you’ve been hearing about open-source strip-mining from large cloud vendors, but what I’m wondering is, do you think it would be good or bad if some mega cloud company offered a Rancher-based service?

Shannon Williams: I think it would be great personally. From our perspective, the value of these mega cloud providers is always tied into a big ecosystem that they’re trying to build around. What we find is that organizations want to live in those ecosystems, and leverage those ecosystems, but they know they’re not going to live in just one of them. So, they want lots of them. And the more that those ecosystems interact or work together, or do things that help them work together, the better off they are.

In so many ways, I think the strip-mining analogy is that it’s a rough analogy because, well, it’s true that some of these providers don’t put a lot back, and there’s definitely been some ugly competition between open source and commercial. For the most part, I think their relationship has actually been pretty beneficial, mutually beneficial between the cloud providers and the open-source software developers.

It’s often where it’s really struggling, where you‘ve seen it’s struggling is when organizations haven’t had a great business plan our route to market, or they haven’t been able to commercialize their own products. And then, all of a sudden, it gets embedded into something larger. And then, the only monetization of it happens in the cloud.

I think that’s where we see most of the problems. I think that’s going to continue. I think that that was happening before as well. You know, ideas are developed, but are never really taken to market fully or are not pushed into the market aggressively. Organizations build upon those something new, or something tangential, or something that accelerates them. And that is what ends up being the big success.

To me, that’s business. That’s something that’s going to happen in any space, whether it is open source or not. And, yes, in our world, people can take and build on it very easily, but that’s what you know you’re getting into when you’re starting an open-source software business. And if you don’t, you really should research a little bit more.

This is a knife that cuts in many ways, from a business perspective. And I certainly would look at the world, and I certainly wouldn’t call foul if that happened to an open-source project. I’ll give you a feel, in China, Rancher is incredibly popular.

From early days, my co-founder Chan grew up in China, and so, you have someone who can speak Chinese and talks about it in China – Rancher became really famous. We’ve had multiple times where startups have kind of emerged competing with us in the market, selling Rancher and providing support around it.

Our experience has been that that, as long as we continue to push forward the innovation and organizations really value what we do, they’re going to want to work with us. They are going to benefit from working with us.

As long as we keep pushing it forward and building the product better, that will continue to be the case. But you have to know what you’re getting into. I don’t feel like there should be a huge shock if you build an open-source product, and someone forks it, and does something cool with it, that’s kind of the idea.

When To Use Open Source

Michael Schwartz: Moving to slightly higher level, do you have any thoughts about when entrepreneurs should use the open-source development methodology to develop a commercial product?

Shannon Williams: For me, I think it’s about the product you’re trying to build, and what you think your route to market needs to be. If you’re entering a market that you think is pretty competitive, and has a lot of different products, and you know you’re going up against much more well-funded organizations than you, then, I think open source is a really, really important one to consider and to look at. Because it allows you to get adoption in what would otherwise be a really hard market.

If your only feedback is going to come from a handful of companies you can convince to POC you or pay for it early on, you are going to have a hard time building momentum. And you’re going to have a hard time having good conversations with users who either like or don’t like what you’re building.

To me, I don’t know, I’ve been building nothing but open source for 11 years, so it kind of feels to me like everyone should just build open source. I don’t find that it’s ever slowed down our monetization. It’s always been a benefit. But I certainly would say that if you’re building something that you think is transformational, that actually has a broad audience that will adopt it, open source should very much be what you’re considering.

If you’re building something that’s probably a service, and it’s going to be hosted, I think open source can be enabling capability, but I wouldn’t worry too much about the open-source side, I would just focus on building the SaaS platform product tool that you are building a cloud service.

Because I think in those cases, open source is less important than it is an on-premise software or fundamental software. You’ve seen with Docker, open-sourcing, and having an open source success is not by any means enough to guarantee a commercial business success, but it puts you in a position where you have a great chance to engage with users, listen to what they think is necessary. Next steps, what they’re excited about your platform for, your product for, and what they’re willing to pay for, and build on that.

Advice For Entrepreneurs

Michael Schwartz: Last question, any advice for new entrepreneurs starting a business around an open-source platform?

Shannon Williams: Of the four of us who started Rancher and started Cloud.com and everything, I’m the non-engineer. My role in the early time of building a company, I was considering my role then to be how to connect with users, like how to connect to people even before you have a product.

When we were in our first 6 months, our first year, I spent all day, every day, thinking about who are potential users could be, based on the direction we think we were heading, and reaching out to people, introducing myself and introducing the idea we’re building, and getting feedback.

You always have to be thinking about the next milestone of users, “My gosh, how do we possibly get to 10 companies using our product?”

And the only way I can ever found that works to get to 10 is to find them by hand. To think, “You know, I think this makes sense for somebody in that space.” I really believe that if you as a founder can’t explain your value proposition enough to get someone to sit down on the phone and talk to you about it, and maybe watch a demo.

Especially when you can tell them, “Hi, I’m Shannon. I’m one of the founders of this new startup called Rancher. We’re trying to solve this problem, and I thought it might apply to you guys. I really love your feedback. We are not trying to sell you anything, we just want your feedback on what we’re doing.”

If someone doesn’t want to talk to you with that pitch, you might be barking up the wrong tree with your idea. That initial response, if you can’t just explain what you’re trying to build to someone right away, and if you can’t get a meeting, it’s probably worth reflecting on what you’re doing, and maybe tweaking, and then trying some different approaches, trying some different messages.

Because if you can’t get a meeting, it’s going to be really hard to get a sell. It’s going to be really hard to get a user, it’s going to be really hard to convert them into a paying customer.

But if you explain to someone, most people love to talk to entrepreneurs starting companies, especially if they can really clearly communicate what it is they’re trying to solve. And that validation early on goes enormously towards then calling that person back in three months, and saying, “Hey, we got a first beta ready, would you like to take a look at it?” And getting those first 10 is hand-to-hand combat.

Really the first hundred is hand-to-hand connecting to people, showing them the product, showing them the value, and getting to use it. Every once in a while, you have these runaway crazy successes, where everyone’s like, “Oh, my gosh, I can’t believe – how did we live before this existed?” But most of the time, it doesn’t work like that. Most of the time, you have to connect, talk, demo, listen to the feedback, and go back and consider how far on or off your strategy you are.

Closing

Michael Schwartz: I said it was my last question, but now you just raised another question, and I can’t resist. Previously you mentioned that a lot of the leads for customers were from inbound, from customers who use the software, liked it, and then called you to purchase a support subscription. But 50 deals a quarter – that’s a lot of business. That’s really pretty stellar. And I’m wondering, what’s the right mix of inbound and outbound marketing sales to push for, or how do you balance that?

Shannon Williams: First step for all of this is find a real market. When you find a real market, things get a lot easier. Because you have to have something going on that’s causing people to look for a solution, they have to have a problem.

So, to your question, if I had my druthers, I’d have a 100% coming inbound, so everything coming inbound means that the market is actively looking for solutions. My brand is well enough known, we are the company they should at least talk to about this to get a demo. Ideally, it’s open-source, just download it, and install it, and try it, and see what you think.

I, from day one, believed in inbound as our goal. So, that meant, instead of spending a lot of our early dollars on advertising, for example, I spent almost everything we did, online communication to users. And that meant, oh, my goodness, we wrote dozens and dozens of pieces of content explaining how to use Containers, and Kubernetes, and Docker, to help people find us.

They may not be looking for Rancher, but they were looking to solve a problem. And so, we really tried to build a list of the lots of the problems they were trying to solve.

We hosted an online meet-up every month that grew to have thousands and thousands of people register every month. It was crazy. We just run them today – I just did one last week.

And what we said was, “Hey, come, it’ll be our smartest technical people. We will stay as long as you need. We’ll demo whatever it is we say we’re going to do. I won’t just show you a bunch of slides, we’re actually getting this code, we will teach you how to do it. And we will stay until every Kubernetes questions are answered.”

So, these things would run two hours, three hours, but they allowed people to cross hurdles, to learn how to build the CI/CD Stack on Kubernetes, or how to do monitoring on it, or how to deal with logging, or how to use containers and the cloud – whatever it was we were trying to solve that month, we really focused on it. It was really that. It was education, community, content that, coupled with early references that we built by hand, in that hand-to-hand phase, got the word out.

By continuing to invest in that, we were able to kind of sow so many seeds of open-source users that as they matured, and liked what they usd, they contacted us. The right mix for me is a 100% inbound from the open-source community. But what we did find was, as we grew, we started to run into bigger organizations. They have entrenched vendors.

All of a sudden, we might have won a line of business users, and then they just said, “Hey, we love this Rancher. We are going to use it for application A, B, and C.” But 80% of the company was using something else that they’ve maybe built themselves, or maybe they bought something, some other product a couple years ago to do PaaS, or something.

And so, because those organizations started to look and say, “Why aren’t you using this? Why are you using Rancher?”, we had to support them and show other people in the organization, “Well, actually, this isn’t the same. It’s different, and here’s why it’s different.” What we did find was there was longer Enterprise sales cycles, so we needed good high-quality sales people to work with bigger companies.

But the positive was, we found that those companies actually really appreciated that it was open source. And the fact that you already had one over, a group of people who really loved it internally, meant that you kind of solved, in a lot of cases, the biggest problems these IT teams were facing, which was, they were building stuff and no one was using it anyway because they were just going to the cloud, they were building something themselves.

So, when we could tie together, the IT organization, which is like doing everything they can to support forward-looking development while still being secure and still being cost-conscious. And teams that have usage and feel like they’ve got found something cool, it was just like made it for a much easier sales motion than your traditional either selling top-down or kind of getting some executive buy-in, and then hoping people use your product once it was brought in.

I don’t know, does that answer to your question, Mike? I kind of feel like I ramp up there.

Michael Schwartz: Yeah, that’s lots of great info. Shannon, thank you so much for joining us today, and being so honest with your answers.

Shannon Williams: Mike, it was my pleasure. Thanks for doing this. I love your idea of open source entrepreneurs just sharing and talking about what we do. I think it’s a phenomenal business model. It is a real transformation of the relationship between the developer of a really powerful software and the consumer of that software. So, it’s something I have enormous passion for.
Michael Schwartz: Best of luck with Rancher, and congratulations on all the success.

Shannon Williams: Thank you so much, Mike. You too. Have a great one.

Michael Schwartz: Thanks to the Rancher team for making this happen. Transcription and episode audio can be found on opensourceunderdogs.com. Music from Broke For Free and Chris Zabriskie. Audio editing by Ines Cetenji. Production assistance by Natalie Lowe. Operational support from William Lowe. Transcription by Marina Andjelkovic.

The Twitter handle is @fosspodcast. Rate us on iTunes if you like this episode.

Next week, we have James Waters, SVP of Product at Pivotal. Until then, thanks for listening.