opensource

Episode 65: Scaling Data Pipelines with Nick Schrock, Founder/CTO of Dagster Labs

Intro


Mike Schwartz: Hello and welcome to Open Source Underdogs! I’m your host Mike Schwartz, and this is episode 65 with Nick Schrock, Founder and CTO of Dagster, a platform that helps companies create data pipelines, which is critical to transform and update data in order to make it useful, for example, to generate reports, content, or other actionable information.
Dagster might not be a blueprint you can emulate. Like all start-ups, there are some hard to replicate serendipity that enables Nick and his team to build this amazing company. But as Machiavelli says, “Great leaders need both – fortune and virtue.” In other words, you need to be good at what you do, i.e. virtue, but they also need some good old-fashioned luck.

But what separates a really successful founders, like Nick, is the ability to harness fortune and virtue and combine it with some deep insights about the market, and turn it into a profitable and fast-growing venture not easy to do.

So, with that said, let’s cut to the interview, and let Nick tell you, in his own words, how Dagster evolves.

Early Career

Nick Schrock: Great to be with you.

Mike: Nick, thanks for joining us today.

Mike: Can I just go back a little bit and ask you to share some of your story about how you ended from going from the University of Michigan Computer Science to working at Facebook? So, that early period – how that happened?

Nick: Oh, I wasn’t expecting to talk about the preface book days. I’ll do the quick version of that. I graduated from Michigan in 2003, and I actually went to work at Microsoft, right out of school. And Microsoft’s a great company, and they treated me well, but… 

And actually, the division I was in was the developer division. And I thought that they were just extraordinarily talented, but at that time of my life, that wasn’t for me, in terms of working at a big company.
I wasn’t actually sure if I wanted to do software anymore, so I went to the London School of Economics for a year, because I thought I might want to go more into finance, or even government service – you know, I was a young man kind of searching around.

But I ended up getting back into software. I worked for a healthcare start-up out of Ann Arbor, which is where Michigan is, for what – 2 and a half years.

And then, I went to Chicago to try to do a start-up. That was very quickly spun down because me and a friend, who had worked in the finance industry, we wanted to do it, but then, it was about 6 months before the financial crisis.

So, that was incredibly poor timing. I spun that down, and actually, turns out a friend of mine, who I knew from Microsoft, kind of heard that was on the open market, and he just reached out and was like, “Hey, I’m working at Facebook, it’s really a special place. You should consider looking at it.”

And I was looking at staying in finance in the Chicago area. And I flew out to Facebook, and it’s just the vibe difference between a place like Facebook and a hedge fund in Chicago cannot be overstated.

You know, everyone at Facebook was young, super excited, idealistic, the office was incredible – there was just all this energy versus all these miserable people working in the hedge fund. So, the choice was obvious from there. And then, off to the races after that.

Why was Facebook so innovative in 2009-2015?


Mike: So, what was it about Facebook in 2009 that made it such a hotbed of innovation? Like, what new problems were they trying to solve?

Nick: The engineering-driven culture there, combined with the actual product that was being built. So, the product grew at unprecedented rates, it was used in unprecedented ways and was data intensive also, in kind of an unprecedented way.

We were forced to kind of do a lot of innovation on the fly in incredibly constrained environments actually, both in terms of resources, timing – you know, we had to get stuff to work. And I think that it is true that those constraints do breed innovation.

And that time of period was interesting because in 2009 – how to put this – we weren’t really taken seriously as an engineering organization, I felt. And then, fast forward say 4 to 6 years, and we were taken very seriously as an engineering organization.
It was really cool to participate in that. And in the end, if you look at the output from that eng org at that time, it really is pretty extraordinary in terms of what systems were built internally as well as what was open-sourced.

Technical Origin

Mike: So, few years back in 2018, after being at Facebook for, I guess, maybe 8 or 9 years, you decide to start a company called Elementl, which becomes Dagster Labs. Can you talk a little bit about how that came about?

Nick: Near at the beginning of my tenure at Facebook, I helped create this team called Product Infrastructure, whose mission was to make our application developers more efficient and productive. So, concretely what that meant is that we build internal frameworks and abstractions for the engineers who actually built the site and the mobile apps to build product.

That team did a lot of great work, and we ended up externalizing about a bunch of that work in the form of open source. So, React came out of that group – I had nothing to do with React, but kind of the people across the hall from me, so to speak, produced React. And that obviously went on to be an extremely successful open-source framework. And then, what I’m personally more affiliated with is, I’m one of the co-creators of GraphQL.

I’ve lived and breathed developer tools for a long time and also seen the impact that open-source adoption at scale can have. So, that was definitely on the mind when I left Facebook in 2017, and figuring out what to do next.

And in fact, I was going around the Valley and talking to companies, both inside and outside the Valley actually, about what their biggest technical liabilities were.
And this notion of data, an ML Infrastructure kept on coming up over and over and over. And I decided to dig into this, and very quickly I discovered that this area kind of pattern matched to what I care about and the types of problems I want to work on, typically the things I like to work on is to share a bunch of properties.

One are just engineers in pain. Like their dev workflow is broken, they have bad abstractions, they’re not productive, and purely because of tooling and abstraction reasons – that actually kind of makes me angry and frustrated on their behalf. And on a personal level, I feel that is really motivating.

Second involved finding – yeah, I like to call it like “a problem that matters”. I like working on really broad horizontal problems that could potentially have impact on millions of developers, kind of core essential problems that matter.

I was data engineering adjacent at Facebook, I wasn’t a practitioner. Data pipelining is extraordinarily important actually. People like to dismiss it as data cleaning, or they are kind of data janitor work, but when I looked at it, from kind of fresh perspective and I really thought about it, I was like, listen, data pipeline, they produce these assets, these data assets that drive all analytics, all the dashboards that you work with, all the ML models.
And if you really think about it, these data assets drive a huge proportion of human decision-making and automated decision-making in our entire society. Who gets mortgages or not, how do we price health care, what kind of news do you see – these are fundamental essential things, and it needs to be built on solid foundations.

And the fact that it – in my opinion – like, it was not built on the appropriate tools and processes, and everyone felt it was like chaotic and out of control all the time, was deeply disturbing. So, things were fundamentally, and still, in some ways, are fundamentally broken in data ML engineering. So, that’s really motivating.

Another thing, another property is that I like working on technologies that are sort of a strategic point of leverage in an organization. GraphQL fits that bill. Because if you kind of can intermediate all client-server interactions with a common software layer that has rich scheme information and stuff like that, it’s like an enormous point of leverage for tooling.

And in the data space, I quickly gravitated towards the orchestration layer because I felt it had the same properties. You know, orchestration orchestrates data pipelines. That means, it invokes every single runtime, it touches every single storage system as a result. And then, likewise, any practitioner that wants to put a data asset or pipeline into production has to interact with orchestrator in some way shape or form. So, a strategic point of leverage, I thought that was super, super industry.

And then last, like some feeling that you have a technical insight that’s novel and interesting, and that’s kind of how we got to this notion of — at the beginning we called it Software Structure Data Sets, but now we call it Software-defined Assets in data pipeline.

And the basic idea is that instead of just writing a bunch of imperative tasks to string stuff together, you instead think about it, you write a software representation of the data asset that you end up wanting to ship to production and be consumed by our downstream stakeholders.

So, that was a very long answer, but I found a problem that kind of checked all the boxes, for what I like to work on. And it’s not just checking boxes – if those boxes are checked, I’m like deeplypassionate about it. That’s kind of how I got here.

Business Origin


Mike: You started working on this problem at Facebook, but then you said at some point, you sort of hit this critical mass of like pattern matching, like you said. And you’re like, “Okay. I’m going to start actually a business. Maybe in Silicon Valley, it’s not terrifying, but it’s a big step.” How did that actually work? When did you decide, “I’m going to start a company.”?

Nick: It’s funny. I’m struggling to recall exactly when it happened, but I knew founding company was definitely something I was very interested in doing. Both in terms of working on a product, but also building a culture, and especially engineering culture.

In terms of company building, that part was very motivating. In a lot of ways, I was talking about how I thought the kind of the output and culture of early Facebook engineering was pretty extraordinary. And replicating the good parts of that in an independent organization was super appealing to me as well.

I think I just started talking to people and my message and the problem I identified really resonated. And then, I was talking to some investors, actually not with the goal of doing a fund raise – it’s kind of funny how it works like that – but there was like, “Nick, you want to look at data pipelining, with your background and, you know, work on something, that we should really think about formalizing this with some capital and a company, so you can accelerate your progress.”

It’s one of those things that almost just kind of happened. And I’m a big fan of, “Be an opportunistic.” It’s also true that from the time I left Facebook, I knew that founding a company had a lot of appeal to me.

Transition to new CEO


Mike: One of the podcasts previous guests, Sytse Sijbrandij, once asked me, “Do you love the product, or do you love the business?” And it’s an interesting question. I think I know were you following that spectrum. And can you talk a little bit about how you came to work with Pete Hunt, the current CEO, and do you have any advice for founders on how to navigate when there’s a pivot in the leadership?

Nick: I might like the business more than you would expect. I obviously – I don’t want to put words in your mouth – but I’m assuming you think I like the product more than the business. Actually, I did a bunch of economics and business in college and then the grad year in LUC, and I thought about doing MBA, so I’m definitely a business-minded. I imagine I annoy our FinOps people because I always like dig in about all the financial metrics and whatnot.

Yeah, we can get to Pete. I knew Pete from the Facebook days. He was one of the co-creators of React. We didn’t work really in-depth with each other then, but we met each other socially and through each other’s work, and really kept in touch for a long time after Facebook.

He wrote a small seed check into the company. We also collaborated actually on some podcasts because we were kind of obsessed with this Facebook engineering culture, and we actually put together a podcast series, Software Engineering Daily, with like 15 ex Facebookers, and we learned a lot about each other during that process.

Pete had started a start-up and sold it to Twitter, and he was working on Twitter. And I was also talking to him on and off about the business. And I was in the market for a head of engineering in early 2022, and Pete and I discussed it. And I was privileged enough to bring him on board. And given his experience, formerly being a CEO of a Dev tools company, he had built a marketing organization, and the sales organization and scaled to $5 million ARR.

I knew he was going to be much more than a head of engineering – I even had super high expectations for that – but he really dramatically exceeded those expectations. And I think, it became very obvious to me that he was just way better operationally than I was, in terms of like the mechanics of management, organization building, managing marketing, managing sales – he had done it before, and it was pretty clear.

I, at the time – just to be transparent – I was solo founder CEO, I moved around the country a couple times, I had 2 little kids. Now they’re 2 and 4, but I’ve also started a family during the course of this journey – I just needed like a co-founder figure to share the load.

Because I didn’t have the time to work on what my superpowers are, which is kind of this cross-product of Engineering, Dev Rel and Marketing I think is where I excel. And the other stuff is like, he could do a much better job with that. So, it just made a ton of sense.

I think I’m very lucky in that I don’t think it’s a repeatable process for a lot of founders to do what I did. Because you need that other human, who you know well, who would have been I think if Pete had his own company at the time, we might have just co-founded something from day one, and had like enormous trust context in – like, the transition to bring him in and then move him to the CEO position was like super smooth. I think it was like super obvious to everyone they knew it wasn’t going to be like this massive culture shift. Because like Pete and I are still aligned on so many issues.

I think the entire team was super excited about it, and the transition was really smooth – no leadership changes, no attrition, the company started performing better. I think it was obvious pretty quickly that that is the right move.

Monetization


Mike: So, diving into the business a little bit, how does Dagster monetize? I see a cloud offering, is there also a license enterprise distribution?

Nick: No. We only do a cloud product. So, just for context for the audience, Dagster is a data orchestration platform. And you can think about it like, you write data pipelines in this Python framework for building data pipelines and orchestrating, meaning, ordering computations and modeling the assets that get produced by those computations.

You can install it open source, and people have deployed that to production – a ton of people, I should say we have thousands and thousands of users – but the cloud product allows us to do a ton of the hosting on your behalf.

Most of our enterprise customers have this hybrid product, where we host the control plane, which you think about it like everything is complicated – the metadata database and long-running processes that monitor things and whatnot. Then, they run their actual compute, it’s their data pipelines and their infrastructure.

So, yeah, there’s a cloud product you sign up for, we can host a bunch or all of the compute. And then, also, we add enterprise features on top of it – SSO, alerting, gobs and gobs of features that generally deal with complexity in the Enterprise that companies typically pay for.

So, that’s our primary business model: you sign up for Dagster cloud, you swipe your credit card or talk to our sales people, and you can have the best experience of a data orchestration platform in the world in our opinion.

Why sell small customers?

Mike: I noticed that Dagster sells to small teams – like you said, you can sign up for like 100 bucks – and also to large enterprise. I’m wondering does the small teams’ business actually add up to real revenue, or is it just a pipeline for enterprise customer?

Nick: I think in terms of what investors care about, and what the long-term trajectory of the business is, we certainly conceptualize it as mostly a driver of pipeline – yes – but a broader adoption as well. So, there’s tons of users that use our hosted product that wouldn’t use our open-source product. And simply because they don’t want to host their own computing infrastructure, which is totally reasonable.
So, I guess, if you kind of boil everything on the business, yes, there is – it is a source of enterprise leads, for sure, but it’s also a source of more adoption, which means more people talking about the product. More people having being passionate about the product.

Because an underlying flywheel adoption is also essential for the long-term commercial success of the company.

I think like that’s the most interesting component of it. It used to be, say 10 years ago, that you’d have an open-source product and you’d be like really pulling teeth to use the commercial or the hosted product.

I think the pendulum is really shifted now, where tons of people wouldn’t consider adopting an open-source technology if it didn’t have hosting options. Just because of the way that the entire world has shifted towards more hosted services, which is I think a win-win for everyone involved.

Pricing

Mike: One of the underappreciated challenges of a tech start-up is how to price your offering. I saw a note on the pricing page about an old plan and a new plan. The new plan’s a little complex – not being an expert, I couldn’t really quite follow it. Can you talk a little bit about the pricing journey and where and why you ended up where you are?

Nick: Totally. I like to say, if building an infrastructure company were a video game, pricing is the final boss. And that actually even undersells it. Because iterating on your pricing model is a continuous process, where you have to make sure that it’s working for everyone involved, that we can run a healthy business and that the customers feel like they’re getting a fair deal in terms of — because in the end, they need to get more value than they paid for.

You are correct to point out that the initial pricing was simpler than the current model. Initially, we started out where we wanted to have like no seats limit and just charge on consumption. I felt that a very fair way of doing consumption was to just charge on the number of minutes your pipelines run.

So, the issue with that – and I think this is a good takeaway for your audience – is that customers have to morally accept the pricing plan. Like, it has to make sense to the underlying way that they think. And the problem in a data pipeline solution, if you’re charging by, say by runtime, is that frequently what you’re doing in orchestration is that you are like calling out to Snowflake or Databricks or some other heavyweight computational system that does all the heavy lifting of the compute.
So, from the standpoint of the customer they’re paying us just to kind of wait for an API call to complete. That shifts the mind of the customer to think of us as just a compute hosting service.
And if you’re just doing that, the value proposition of our product doesn’t make sense.

So, the pricing impacts the way that the customer perceives the value of the product, which is obvious when you say it out loud, but isn’t obvious when you’re kind of in it.

We’ve really stepped back and looked at this – the real value in an orchestration system is in the kind of the control signals and the metadata. Like, concretely, you open up a orchestrator, or our orchestrator, and you see all these fancy Gantt charts of what’s going on, you have a ton of visibility, and then the words that our users often use is, “Ugh! Dagster is like the single pane of glass that consolidates my entire data platform, I have visibility into all this stuff.”

So, that’s where they perceive the value. They do not perceive the value like it’s a hosted compute service. That had the benefit of being simple, but didn’t actually align with the product value that the users perceived.

We switched to charging based on metadata and control plane events that drive our UI. I think the other thing is that for founders in the audience is that you have to have a pricing model that works for sales. And early on, you don’t have enough data to know how much consumption there’s going to be for a customer, for like say the next 12 months. And with the way sellers work, they have to hit their ARR number ― that adds up to their quota, that determines whether they can feed their children or not. So, it’s very important to the sales team.

We had to also add sort of a per seat component that effectively acts as a platform fee for our enterprise customers that allows us to kind of project and forecast ARR that would be appropriate to the value it’s going to deliver to the customer.

You also have to think about the internal incentives and how it’s going to work for sales people, who are reliant on selling your product in order to send their kids to college.

Why Audience Selection is Important?


Mike: I am going to pivot a little bit back to tech for a second, but really more to talk about the open-source community. What’s interesting about Dagster is that it reminds me a little bit about the battle between Perl and Python. They were open-source tools in your area that existed before, but they were a little bit hacky or more challenging.

Can you talk about what are some of the challenges of building an open-source community in an already competitive market, where you needed a lot of features just to get the baseline of functionality? And then, how did you focus on either getting new, or getting some of the developers to switch into your platform?

Nick: You need to make sure that you have an audience that cares about what you care about, and it is very differentiated on that dimension, to the point, where they are willing to take a risk to bet on you, to work around missing features or missing integrations that might exist in a more mature solution. So, identifying that small subset I think is extremely critical.

There’s now, I think, a kind of standard reading for Silicon Valley founders, which is Peter Thiel’s book Zero to One. And he talks about how you start with a small market and then dominate it, and then move on to progressively larger markets. And I think that really, really resonates with me, especially in developer tools.

One kind of approach – and this is kind of the nature of tools that I like to work on too – is that what you can do is pick the audience that you think has the most leverage in the organization. And for us, it’s like the data platform engineer. Like, there’s engineers whose entire job in life is to serve stakeholders who build data pipelines on top of a data platform that they build.

And a huge part of that is setting up a great developer workflow with CICD and testing, so you can actually maybe know if you’re going to break something before you push to production, which is very frequently not the case in data pipeline.

I think our early audience was really people who really got it that testing, and fast feedback loops, and developer life cycles, is like the baseline foundation of productivity. And productivity is just huge in working in the software. Because productivity is not just about doing tasks more efficiently, it’s about making an entirely new things possible.

So, yeah, I guess I kind of went for a field there, but to circle back to the beginning of the question, I think it’s audience selection and being deliberate about that, it’s really what’s important.

Governance

Mike: Recently HashiCorp has changed their license, and I see that Dagster’s published in its own GitHub repo, so you’re under the Dagster repo. Dagster is your trademark. How can you assure the community that if the board decides to sell the company to Oracle, for example, that they won’t change the license immediately? And have you considered moving the Dagster open-source project to community governance and making it safer to use for the future?

Nick: As someone who’s gone through a foundation process for another technology, we moved GraphQL to its own open-source foundation with community governance. I have a pretty deep understanding of the trade-offs here. I think it’s a question of maturity and life cycle. The risk that you said exists. There could be a boardroom coup, and I’m out and Pete’s out, and then, we’re sold to Oracle or something.

By the way, the probability of that is approximately zero, but let’s theoretically do it. And then, Oracle could change the license―that is possible. I don’t think that’s a realistic risk in any sort of near-term.
So, if we had community governance, it would eliminate that risk. However, community has a ton of it overhead. And where does the beginning of our journey for innovating, and we want to be able to move quickly and respond to feedback quickly, build features, have complete control in that way.

And that’s definitely the right trade-off for us right now. Compare and contrast that to the GraphQL story, with GraphQL, we open source the spec, a document that was meant to be very stable from day one, and evolved pretty slowly over time. So, in terms of the technical artifact there, it actually matched like having a foundation process and governance over it made a ton of sense. But for Dagster and the immediate future, we’re having more centralized control, and increased pace of execution definitely makes the most sense to us.

2023

Mike: I’m going to move to a temporal question about 2023. A lot of tech companies struggled in 2023. The Times reported that 3,200 venture-backed tech companies went out of business in 2023. Of course, I don’t know how many normally go out of business, but still it seems like a lot. I was wondering, was 2023 a good or a bad year for Dagster? Did you buck the trend and grow 100%, or did you also feel pressures on budgets from enterprise customers?

Nick: We had a great year. So, not only did we grow 100%, we grew 400%, and our NDR was north of 150%, which means, our existing customers were also increasing their contract sizes. I feel great about the business, especially being able to grow this quickly in this environment. I am also grateful that we didn’t raise round of financing in a wildly inflated valuation, with too much capital in the FED bubble in 2021.

Because, at the time, certainly, it was frustrating – a bunch of my peers were  — you know, all of a sudden, the CEO has a billion-dollar company, even though they in reality weren’t that far along in the journey.

Now, I think a lot of those people kind of are in a pretty tough spot, and they’ve had to do layoffs, and it’s painful. We kind of stuck to our fundamentals there, so, I feel very good about it.

I still think the pain is going to be very real for the industry through 2024, maybe even into ’25. Because, yes, there’s an advantage to raising a bunch of capital too, in that you have a long runway. A bunch of these companies, they have so much cash on the balance sheet, and the interest rates have gone up that their interest is actually a meaningful source of income too.

There are more waves of company death coming in ‘24 and ’25, I guess I’ll put it that way.

But we’re in a great trajectory, and I think we’ve raised an appropriate capital to the progress in the business. And we were able to raise a B in 2023, which was a very challenging process, but it felt great to be able to do that. Not many of the companies were able to do that.

Open Source R&D v. Commercial R&D


Mike: Here’s a question, and it’s a little bit about engineering priorities: you have an open-source project of which your team contributes a lot of code to, and you also have a commercial cloud product. Can you just talk sort of at a high level, from an R&D perspective, like how much of your budget gets invested into your product versus how much gets invested into the open source? And how do you balance those priorities?

Nick: It’s actually hard to tease apart. Because, if you’re an engineer who is working on a feature that will have manifestation in cloud, often you’re kind of spanning the entire stack and like working on the open source, but then also working with some proprietary features. So, it’s difficult to cleave it that way.

The other thing is that we reorganized the engineering, the R&D organization around company objectives fairly frequently. I actually can’t give you a precise number at any point, or historically/cumulatively, about how much we’ve devoted to both open source and the cloud product specifically.

I guess what I’ll say is that we still invest a ton of our eng resources. I would say like 40% of engineers effectively work exclusively on the open source, and then there’s another tranche that kind of spans the entire stack, and then there’s another tranche, like people who work on our cloud platform, and all the DevOps and SRS work around keeping that alive and operational.

I don’t know, I guess you can call 50/50, but it’s actually really difficult to put it even semi-processed number on it.

Dog Years


Mike: Well, it sounds like it’s really been an amazing journey. And I’d like to remind you that it really hasn’t been that long either. Only 2018 doesn’t seem that long ago to me.

Nick: Well, it seems like a long time to me, man! That’s the old joke. It’s like dog years in a start-up, one year feels like seven. I have to pinch myself. I only moved away from the CEO seat like 15 months ago or something. And it feels like a lifetime.

Founder Advice


Mike: We covered a lot of topics, but I guess, my last question is, is there any advice you have for entrepreneurs, who are launching a business around an open-source software, product or project?

Nick: I think one of the things that founders need to think about — I mean, this could be an entire hour podcast about all the advice that I would say, but couple things to think about: one is, know when to go slow and know when to go fast, especially when you’re talking about so-called “one-way doors” in Jeff Bezos speak, where you’re making decisions that are either extremely costly or impossible to undo. Company branding is challenging to change in terms of the specifics of open source and dev tools, API decisions, especially in open source, last forever. You need to be deliberate on that.

And a commercial product, you can actually iterate extremely quickly. So, I think it actually is important to kind of have two cultural muscles. One is much more upfront design-oriented and collaborative with community, and deliberate and thoughtful on API design, but you still want to have that super-fast feedback and development when you’re developing the commercial components to your product that are hosted.

The other thing I would optimize for – if I was traveling back in time and talked to myself – is optimize for getting yourself into a situation where you can have a super-fast feedback loop, with early users and customers, where you still have the opportunity to change things, and do so quickly.

If you’re in a super-fast feedback loop with a single customer, you can make API changes much more easily. And the ideal situation still is, if you are working on a technology internally at a company, where you have access to all the code that uses it, that is just super valuable.

You’re also basically getting a seed round for free, because, often you’ll have people around you, and you’ll be working on it.

So, I don’t think I truly internalize what an advantage that was, to have it done the core R&D internal at a company. Yeah, I think like there’s a little more resistance now to open source the internal tech with kind of — it’s a less idealistic environment these days. But those are kind of the top-level things that come to mind.

Closing Notes

Mike: Well, great. Thank you so much for taking time out of your day, Nick, and best of luck with Dagster Lab.

Nick: Thanks. It was really a joy to be on this podcast. Thanks, Mike.

Mike: Special thanks to the Dagster PR team for reaching out and helping with logistics. Cool graphics from Kamal Bhattacharjee. Music from Broke For Free, Chris Zabriskie and Lee Rosevere. Next episode recorded at the State of Open Conference. Peter Farkas, Co-founder and CEO of FerretDB. Hopefully, I’ll have that out in the next week or so. So, until then, thanks for listening.

Episode 64: API Service Mesh with Idit Levine, CEO and Founder of Solo.io

Intro


Mike: Hello and welcome to Open Source Underdogs! I’m your host Mike Schwartz, and this is episode 64 with Idit Levine, Founder and CEO of Solo.io, an API Gateway and Service Mesh company with a product called Gloo – not to be confused with Gluu – the company that I lead, who sponsors this podcast.
I’ve been trying to get Idit on the podcast for many years ever since I spoke with her at an Open Source Conference in 2019, and finally, her PR agent reached out to me a few months back, and, of course, I agreed immediately.

Solo is not your typical startup journey, it’s sort of a miracle it got off the ground, but once it did, they didn’t waste any time – they’re already breaking 10 million in sales.

To avoid spoiling the story, I should just stop here, so let’s cut to the interview.
Idit, thank you so much for joining us today.

Idit: Thank you so much for having me, Mike.

Did Solo Join an Incubator?


Mike: My first question, and this is sort of a different one, but it’s something I’ve been thinking about, is when you first started Solo.io – which was not that long ago, I think five or six years ago – did you join an incubator and why or why not?

Idit: I did not. I wasn’t even aware that they exist, honestly. When I started the company, what I knew is that I had some “technical” friends that I knew that I can start it, and basically started doing this – the software was more about the technology. So, I needed to learn that while I was raising money, and so on.
Honestly, Mike, I think the first VC that I met, they asked me about a pitch, and I asked, “What is a pitch, what am I supposed to do?” I really didn’t know much, I needed to learn.
I wasn’t aware of a long incubation, definitely not in those days, because it’s not very popular.
I just basically started the company around software and just tried to get some money in order to kind of like bootstrap the company. But that’s basically the things I would do. Honestly, mainly because I wasn’t aware of it.

Mike: Do you think if you could do it again, you’d use an incubator?

Idit: No. Now, I feel that they learn so much from those processes. I think it’s very good if a first founder maybe is not aware of a lot of stuff, that’s really helpful to be kind of like protected by team that has done it before and knows how to help you and guide you.

Today, I think I learned enough of the process, and I’m doing it for a while right now. I made a mistake, I learn from them, so now, I’m feeling that I’m more free to actually do it myself again, if I need to.

State of Company at Seed Funding

Mike: At the time you raise your seed funding, was the open-source project started, did you have any technology, did you have any initial customers or team? Like, what was the state of the business when you closed, let’s say, that seed round?


Idit:  No, there was nothing, honestly. Before that, I worked in the EMC. Part of the EMC, my job was to basically do cool stuff on open source. I was in business, I was in the city office, and my job was to basically, if I had a new technology and we had to figure out how we can play that. Basically, we did a lot of open source and invent development. We immediately knew that we were playing back then, in Kubernetes, Mesosphere and Mesos, and all that great kind of technology. Docker was just a new thing back then, so, again, playing in that ecosystem was immediately a thing that we’ve done.

When I started the company, there were two things that I started pitching in the beginning. The first thing that I was pitching was unikernel. It took me a few months to understand that that’s something that I would not be able to ever raise money on. Probably for good reasons.

By the time we were at home, I was pretty bored, so I built another open-source project called Squash. And that was an open-source project that related to debug microservices in Kubernetes.

And that was relatively successful project, but mainly, as I said, I think that there is a good money on it because the work that I was doing before in the open-source, I literally built a reputation of someone who is capable of doing a cool project.

How Many VC’s Pitched?


Mike: How many VC’s did you pitch in your initial seed funding round?

Idit: Oh, man, a lot. I mean, as I’ve said, again, you remember, I was on the east coast, but once I decided to do it seriously, I left the EMC, and then, I basically went to the west coast, where there is VC that is more in that space and that, yeah, I got a lot of those, a lot. I think like every founder as well.

Products?


Mike: I don’t want to go too deep into the tech, but when I look at the Solo website, I see there are a few products. I am wondering if there’s like an 80/20 rule here, where one of the products accounts for 80% of the revenues?

Idit: We don’t have 20/80, actually, that’s interesting. I think it’s probably 50/50. And the reason is because of the packages, a lot of time we’re selling them together. If you look at all the projects, the main two markets that we’re going after is, the Gateway and the Mesh market. We started with a Gateway mainly because the Mesh wasn’t — you know, we couldn’t sell it.

So, we started from the Gateway, and we knew that this is kind of like an entry point and kind of like a stepping stone to a Service Mesh, so that felt very in the area. And I believe that in the future the Mesh will grow more.

First Customer

Mike:  So, one of the challenges of a start-up is always the first customer, especially if you’re selling in the Enterprise space. How did you convince this customer to be first? What did they actually buy? And whatever they bought, does that resemble your current offering today?

Idit: Yes, actually, as I said, we started selling the Gateway, and that was a flagship product of the company. When we started, basically what we did is, we had three design patterns in a way. I didn’t do it the regular way, we did it from open source. We didn’t go and talk to customers and say, “What do you want us to build?” And then, we built it. We were more like, we’re in the open-source and kind of like say, “Okay, that seems like the right thing to do.”

Kubernetes came, you needed a new API Gateway, you wanted probably an Envoy – that’s what we believed people wanted – and then, we went to pitch.  And a lot of those customers came to us from the open-source community.

So, we learned a lot from that process. What we did, and we did it differently, because we are coming from open source, we basically managed all our relationships with our customers through Slack. Then, understood what we need to do in order to make that very, very successful in their infrastructure. And we basically got all those requirements and built them into the product. It’s very different to build an open-source project versus an Enterprise environment.

Value Prop


Mike: So, what would you say is the most important thing that motivates your customers to buy your product?

Idit: I think that today Solo is kind of like three things that we are very good at. Number one is, we really, really understand the marketing really, really well, and the technology in it, so we know what’s coming up. We know what is 20 and what is not, we’re looking at adoption – we really understand that very well.

So, we always compromise with the customer that we will bring them to the edge of the technology. If there is a new technology that is relevant, we’ll probably put it in our product. I think that’s one thing that customers like, so the perception of Solo is that it is an innovative company, which it is – it’s what we are.

The second one I think is customers in sales, which was always one of the things that is the most important to us. This work with Slack, when I started it, everybody told me that’s not going to scale. And surprisingly today, when we have hundreds of customers, it is still scaling, and the technology itself, if you look at it right now, there was a lot of shifts in the market in terms of the infrastructure that you’re running, most likely running in something like Kubernetes.

So, it makes sense that you would have a Cloud native Gateway, and when you start scaling and scaling and scaling, it makes sense that you will take care of something like MPLS and Security and Zero-Trust and Observability, and all those microservices – it’s just that this is the needed technology when you are going to scale. And that’s where the market of microservices like Kubernetes is right now.

Is Solo a Distribution of existing Open-Source Components?


Mike: Solo is an interesting company in that, in a way, you write software, you write a lot of software. But you also have a curated distribution of open-source components that you give your customers a control plane to manage and take advantage of. So, it’s not just the software that you’re writing, but without Envoy and without Kubernetes and without Cilium, you really maybe couldn’t even build a product. So, do you think that maybe this is a new model, where you add a little software on top of this huge curated distribution of other very complicated components?


Idit: Instead of creating the open-source project – we do have one, for instance, Gloo Edge is a technology that is an API Gateway based on our technology, and it is based on Envoy. I think that what we were good at was identifying, pretty much at the beginning, which of those technology would be better on Envoy, when honestly Envoy was relatively a very small community no one really knew about it, and NGINX was the chosen proxy.
We chose Istio, even though we could have competed like everybody else and tried to build a better service mesh, but I knew that that will be the choosing mesh, even though when we looked at it, it was pretty messy, and we knew that it would take you a while to get there.

I was very, very aggressive to my team saying we are not going to be competitive, we are going to use that.

And the reason is because the software that wins is not always the best software. It is the software that most people are leaning to because they will make it eventually the best software. And I think that that was something that Solo has recognized very well. All that technology, all those products that we are doing is basically we are building – and I will not say a little – we are building quite a lot of logic, ease of use and enhanced technologies on top of those — let’s call it basic component that you need.

There is a lot of complexity actually in the control plane, way more than in the data plane, for instance. But, yeah, as I said to you, this is my model, hopefully sellers will succeed with it, but yeah, I believe that open source is building an amazing technology, and that we should leverage the best.

We are also contributing a lot of those technologies. I mean, if you look at the Istio right now, the new thing that we did with Ambient that we and Google contributed to it, it’s mainly we are the main contributor to it. And Istio, we are contributing a lot to it, we have a full team that is responsible to contribute to it. If you look at this, probably I think the most engineers that are working today on Istio are coming from Solo.

How to Decide What Features Are Open Source?


Mike: I was looking at the open-core model, but I’m actually more curious about, there’s always this friction between what do we put in the community version and what do we open-source. What’s the decision process behind deciding whether a plug-in will be commercial or non-commercial?

Idit: In the beginning when we started, we had nothing, we put everything in the open source, but then at one point, we understood that that’s a problem. Because eventually, somehow, you’re not going to exist as a company if you are not going to make a little bit money at least. So, we needed to figure out that what we’re putting on to double it will make sense, we are not hard to open source because it’s very important to us that open source will be successful.

It’s why we continue contributing constantly to the open source, but we also need to make sure that we will have something that differentiates it on top of it. And the decision in the beginning when we thought about it, the Enterprise feature that people actually really, really wanted to have a provider helping them was security or stuff that will let that do. You know, Enterprise feature like HA.

So, that’s the stuff that we put in Enterprise. The question is, you are usually around technology, would it make sense to be in the core open-source project because that is where it belongs. It’s kind of like a core feature, or it’s actually an extension to that open-source project.
And therefore, it’s going to be that Enterprise edition. To us, it was very important that the core should be open. That’s the way we’re doing it.

Pricing

Mike: I always worn entrepreneurs that pricing is one of the most challenging aspects of a tech start-up in particular. Can you share maybe some of the lessons you learned about how to price in the first few years, did you get pricing right initially, did you have to do a major pivot – what was your experience there, and do you have any lessons learned in pricing?

Idit: As I said to myself, okay, maybe the real unit of contribute for instance in the Gateway is supposed to be the API call, but honestly, that will take a lot of time for me, and it’s also going to be a pain for my customers, so how can I still value how much they use it, without actually interfering too much with the customer and with my engineering team.

And what I came with in the beginning is that the data plane is usually a good assumption, because if you have a lot of call, you’d probably want to scale that data plane. And in the data plane, it’s easy to call, the customer tells me I have five clusters, this is a data plane I am using – it is very easy to measure it and if people use it more, that’s fine.


So, that was the beginning. When we added the service mesh, there was a way more data plane and there was also a way more potentially change. Because you have cycles, and the cycle is basically going directly with the application, the microservices. The microservices going up and down, so very hard to basically figure it out. We needed to change that model and we went to the cluster model.

We said, just let’s keep it simple, we don’t want it – again, it’s all about keeping it simple. That’s what was important to me. I don’t want my customer to need to have a PhD in order to understand the way we were pricing.

That’s what I did. And again, it’s probably cost me some money. I probably left some money on the table and that was fine. But again, it was all about and it is still all about Solo as the partnership. It’s all about the relationship that we have with our customers, it is a real partnership, we are seriously the extension of their team.

But, you know, stuff changing all the time, so you always need to adjust. And honestly, you are learning that from your customer. So, for instance, what we saw right now is that some of the customers that are basically using us, it is more like advanced development center kind of thing.


Innovation centers like city offices or the innovation center on the ITN, and when they are starting, usually what they want, their job is to basically build something to offer to the businessmen. So, the question is, the money is not going to come from them, you cannot expect them to have tons of budget to pay you to run it.

So, what they really want is more of the consumption model. What they want is to create something and get the platform available everywhere, without paying millions of dollars, but then, they will basically enable teams to come after. And that’s different. The model should be different, it can be how much clusters you’re running. Because it could be that you’re running an empty cluster in the beginning. So, we needed to adjust based on the customers. So, it’s always moving kind of like we are learning from the customer how we can make it better.

But again, to me, the way I’m looking at this and that’s always my motto – whether it is truthful building, writing software or selling product – I want to take the challenges on my team. For instance, I prefer right now to build a sophisticated metering that will make the best customer end-user experience for my customer, even if it’s harder.

How to Maintain High Growth

Mike: You know, I was reading an article, and it said that you were projecting five to six times growth for the next year, what is a key to obtaining this high rate of growth? How is that possible?

Idit: First of all, the market – and that’s very, very important. Like for instance, when we started, we had the Gateway that was very popular and everybody needed it, and then the Mesh came, but it took us a while until Mesh would be everywhere. Right now, there is a lot of stuff that is going really, really well for us, and that’s what is allowing us to go.


What number one is, for instance, that is still going to the graduation. So, we actually choose the right service mesh, and not only this, it is going right now to graduation which has shown maturity.
So, that by itself means that there is more demand from the market. You just need to have the right market product to sell, and when a customer wants it, it would be really lazy to grow. But I’m not going to say that there are no challenges, in economy, it could be that we have an amazing product, we have tons of money – that’s not really helpful if our customer doesn’t have money. They’re not going to buy it. Again, that point – you need to make sure that the product is a necessary, that people will need to spend money for it.

Just, again, listen to the market, make sure that you have the right market fit, which I think is the most important, thinking about the packaging, make it very, very easy for people to consume your product.

Metrics and Data?

Mike: You’ve mentioned that you’re data-oriented, and I’m wondering, what are some of the most important metrics that you track?

Idit: This is a good question. I mean, if you ask my CFO, who is a very, very data-oriented person, a lot of the metrics that is running is metrics is numbers – how many VCs we are doing, how much of it is in production and that kind of stuff. Data that I’m looking at is different than the data that my CFO, the metrics that they’re looking at. I think in every business, it’s all about people, it’s all about the people in the business, it is all about the people in the market. Why has AWS decided to do this, why has Google decided to do this, what’s going on inside this organization – all this information is not metrics, but it’s data that you need to collect in order to make the right decision.

How do I predict it five or six years ago that there is going to be a lot of clusters and that people will need a service mesh for each and Istio will be that service mesh. That was pretty crazy to do five years ago.


But I had enough data that would lead me to believe, a lot of data that would lead me to believe that this is the direction that we need to go. So, we do have the metrics of how many customer success, otherwise you cannot scale – you need to know when something is wrong and, you know, big enough organization right now that “I’m not everywhere and I don’t know everything anymore.”

What Gives You Joy as CEO?


Mike: What gives you the most joy as a CEO?

Idit: It is always your job to basically kind of like try to cover the gap that you have in the company. As in the beginning, we had engineers, but we didn’t have anybody to do evangelism, and kind of like after that, we grow, and then we got that evangelism, so I’m not doing evangelism anymore. You are always doing more stuff, and to me, the way I’m looking at this, honestly, when I’m waking up in the morning is, what is the next fire that I need to put off, like where do I have a problem with, what is not working well the way it is working right. It is seriously like that’s how you should think about it – where is the next fire will come from and how am I covering it.

And to me, I’m a person that is easily being bored, so, I like learning, I like seeing what the problem is, I’m dangerous in every position in the company, potentially. I’m dangerous enough now after six years that I learned all of those.

So, I think that, the fact that it’s never boring, but I wish it was a little bit more boring. I mean, I heard a joke from someone that said, “A founder that started a company in the last five years, what did they need to overcome?” We needed to overcome Covid, we needed to overcome the SVB with the Silicon Valley Bank fall, we needed to overcome the fact that all our competitors suddenly could have raised 100 million dollars, you know, like crazy variations with seed money.

And so, there was a lot to overcome since then and it is never boring. And I think that as someone that likes challenges, that drive “I want to be the best, I want to win.”, so, that’s what I’m enjoying.

And I’ve got an advice from Diane Greene, who was the founder of VMware. And she was one of the people that started Google Cloud, so, one of the feedbacks that she gave me when I started. She basically said to me, “You can decide which type of CEO you should be.” Keep the stuff that you really like to do or you really feel that you’re a huge differentiator. And my guess is, it is that technology is the strategic, that is my strength.

And bring strong people next to you to cover the stuff that you can give away. So, my advice is to go to market. That to me is kind of like the way I’m looking at this, but honestly as a CEO, you really do a lot of the stuff that you don’t want. I mean, your job is to fix the problem or to cover stuff and to enable the other teams. If I need to help my engineers, I will do that if I need. You know what I mean? I will do everything I need to enable the team base. That is I think very important.

What Advice Would You Give Yourself If You Could Go Back in Time?

Mike: If you could go back five years or six years and give Idit some advice, what would that advice be? It doesn’t have to be at the very founding, it could be in the early stages too.

Idit: Wow. I learned so much. It’s very challenging to run a big team and make everybody aligned. As the company’s growing more and more and more – that’s become more than another. I think that the advice that I would tell my younger Idit is basically, just follow your instincts, listen to people, but eventually, make your own decision. I think the thing that I was doing wrong in the company was, a lot of times, I’d hire a leader for market and he’d go to market. And I knew that this is not my strength.

So, even though I didn’t believe always that what they thought were doing is wrong, I let them do it because I said, “Look, they are the expert. I’m not an expert in marketing, so let them do this.” I paid a big price for it because I felt that actually a lot of times, they were wrong and it’s within the company.
So, I think that what I learned today and why I think that I would be a better leader than I was back then is because I’m going to die or succeed on my mistake, honestly. Because there’s nothing faster than us to come and take responsibility for someone else’s mistake.

Again, it doesn’t mean that you’re not going to listen, but after all the data at the beginning, if you believe, like trust your instincts, don’t assume that someone else knows your business better than you. I think that this is something that I made a mistake a lot of time, actually multiply times. Before I said, “Okay, that’s it.”

Close

Mike: Idit, thank you so much for sharing all that experience and know-how and best of luck with Solo. Although it doesn’t look like you need it, you look like you’re doing amazing, so, congrats.

Idit: You always need more luck, but thanks.

Mike: Special thanks to Idit and the Solo team for reaching out. Cool graphics from Kamal Bhattacharjee. Music from Broke for Free, Chris Zabriskie and Lee Rosevere.

Next episode’s expected Jan of 2024, an interview with Nick Schrock of Dagster. I’m slowing down a little bit, but I’m still trying to do four episodes a year.
Don’t forget the State of Open Conference is returning to London, Feb 6th and 7th. So, until next time, this is Mike Schwartz, and thanks for listening to Open Source Underdogs.

Episode 63: EBPF Networking Isovalent with Liz Rice – Chief Open Source Officer

Intro

Mike: Hello and welcome to Open Source Underdogs! I’m your host, Mike Schwartz, and this is episode 63, with Liz Rice, Chief Open Source Officer at Isovalent, the software startup behind Cilium, an eBPF-based Networking, Security and Observability project. 

This episode was recorded in early February at the inaugural State of Open Source Conference or SoCon, which was held in London at the QEII Center in Parliament Square. The force of nature behind SoCon was Amanda Brock, CEO of Open UK and editor of the essential book Open Source Law, Policy and Practice, 2nd edition. Check it out on Amazon if you’re an open-source founder. Don’t miss SoCon next year in 2024, especially if you’re already in Europe for FOSDEM.


If you think eBPF or enhanced Berkeley Packet Filter sounds like a geeky low-level technology that you don’t need to know about – well, you’d probably be wrong. It enables developers to safely write code that runs in the Linux kernel. And safely is the key word here, because if you crash the Linux kernel, everything on the whole server goes down, all the containers, and everything else running on that server.


However, by exposing the power of the Linux kernel, developers can write code that runs faster and consumes less energy, and faster and cheaper has always been an attractive feature. Cilium combines three products into one. It’s like an old-fashioned firewall, an API Gateway and Wireshark, and it’s Kubernetes pod aware. It’s used by a number of successful products like Teleport for access management or Solo.io Service Mesh.
Simply said, eBPF is going to fundamentally change our infrastructure.


I met Liz at the SoCon conference, and after learning a little about Cilium, I was really impressed, and I asked her if she would come on the podcast, and luckily, she said yes. So, here we are with the interview.

Mike: Liz, thank you so much for joining me today.

Liz: Thanks for inviting me.

Tech Overview


Mike: As I understand it, Isovalent leverage’s a kernel technology to build a product called Cilium Enterprise. The upstream Cilium project on GitHub has over 22,000 commits and 14,000 stars – these are really impressive numbers for a project that started in 2016. How did this happen and how does this relate to the origin story of Isovalent?


Liz: Yeah. So, Cilium is built on a platform called eBPF, which is the kernel technology that you referred to. And eBPF allows us to run programs that are triggered by events that happen in the kernel, and those events could be Network packets, they could be a system call being made by user application – pretty much any sort of event in the kernel can be used to trigger an eBPF program.

Cilium was the first networking project to take advantage of eBPF. And it was always designed with the idea of container networking in mind. And the folks who started it are the founders of Isovalent, as well as being the originators of the Cilium project. So, Thomas Graf, Daniel Borkmann, who’s a kernel maintainer looking after eBPF, within the kernel.

And eBPF and Cilium, particularly eBPF in Networking and Cilium, kind of grew hand in hand since 2016 thereabouts, as we – the many, many contributors to the Cilium project – as it grew and as it gained functionality, sometimes that’s required additional capabilities in eBPF.

So, it’s been really almost like a long game. I think when Daniel and Thomas and Dan, the CEO, when they were first thinking about using eBPF, it was such a cutting-edge kernel technology – nobody was using it in production.

You know, when we add something to the kernel today, people won’t be using it in production for probably three, four, five years to come, so really, anticipating what the future was going to be.

I first saw Thomas presenting Cilium and the underlying eBPF technology back in 2017, and at the time I thought, “Well, this is revolutionary, this can change so many things.” Because not only can we see Network packets being manipulated by eBPF programs, we’ve also got this incredibly performant way of observing those Network packets and reporting on them that we can use for observability tooling. And like you mentioned network policy – we can implement network policy in eBPF.
Just making policy decisions about whether an individual Network packet is permitted or denied by policy, based on Kubernetes identities – this is the other real strength of Cilium.


It knows the Kubernetes identities, the labels of every pod. And so, you’re no longer just looking at network flows in terms of IP addresses and the port numbers you’re actually looking at them in terms of “this is a flow between service X and service Y.” It is so much more meaningful for a Kubernetes’ user.

Why the name Cilium

Mike: Just out of curiosity, do you know what Cilium means?

Liz: I think they’re little hairs in the inner ear – I’m not entirely sure why that was used as the name for the project.

Origin


Mike: I understand the eBPF technology is mind-blowing – Cilium is quite a project as I said. I mean, you’re not one of the co-founders, but do you know anything about how did it become actually a business?


Liz: I think pretty early on, as Cilium, the project, was getting established, and this sort of understanding that eBPF was going to be a really great foundation for efficient networking. That idea of building a company around this technology was probably in Thomas’s mind right from the get-go – I don’t know that for sure, but I imagine it was. And he and Dan Wendlandt, who I mentioned earlier – this is Thomas Graf and Dan Wendlandt – Dan had the background in software-defined networking, he’d worked at Nicira.


And I think they really saw the future of container networking being built on eBPF, so it was kind of natural to build a company. But, for the first few years, really the focus was on building the Cilium open-source projects, getting that really well-established and really well-known in the Kubernetes community.

It’s now been adopted by the CNCF, so we’ve actually contributed the project to CNCF, we’ve recently applied for graduation status there. It’s probably the most widely adopted in production networking plugin for Kubernetes now.

That kind of path from open-source projects, we really need to see this widely adopted, and then, a business that can provide, not just support, but also some Enterprise features that really large adopter is going to need. And just makes a lot of sense.

What does a Chief Open Source Officer do?


Mike: Your title is Chief Open Source Officer, and that’s a title I’ve never actually heard before. How is that role defined at Isovalent and why were you so excited to take on this mission?

Liz: It’s a particularly interesting title in a company where the vast majority of the engineering is open-source engineering, but I don’t run the engineering teams. My role is much more about how do we continue adoption of the open-source project, and how do we interface with the foundations, the community – I do a lot of work with the CNCF as well. How do we both act as good citizens towards that community and do the right thing in the open-source world. But also make sure that we’re taking advantage of everything we can.

You know, foundations like this offer us a lot of roots to speak to people who might become users and how we can do that in a way that is beneficial for people who want to learn about Cilium, or who want to learn about eBPF. So, that kind of educational role also falls within my team.

Open source v. Enterprise

Mike: This may sound like a silly question because Cilium was so powerful, but from a business perspective, what would you say are the main value propositions of the software?


Liz: So, from the open-source perspective, it’s a highly performant networking solution with built-in observability and security features. And we could dive into more details on what those are. From our perspective, it’s fantastic. If people are satisfied using the open-source version of the code – that’s great – we never want to make it such that — we don’t want to curtail the functionality, so that it always wants to be useful to open-source users.

That said, there are some features that particularly larger Enterprises are particularly interested in that you won’t need if you’re not a big Enterprise. So, for example, integrating with Legacy workloads. Some high availability features that you don’t really need unless you’re at a certain scale – those are the kind of features that we provide in the Enterprise distribution at Cilium.

Isovalent v. Sysdig?


Mike: Do you see yourselves competing with a company like Sysdig?

Liz: On the security front – yes. There is an element of competition there. I think we’re sort of speaking with slightly different customers there. Because, to my understanding, Sysdig is very much a security focused solution, whereas Cilium really applies more to a platform team who’s establishing, I would say Networking first, with this incredible set of security capabilities that you can then show to the security team, these amazing capabilities that they’ll get all that they already have by using Cilium.

I think we’re probably talking to different people within our respective customer organizations, but there is a certain amount of overlap around particularly the kind of runtime security, which we have a sub-project of Cilium called Cilium Tetragon. And there’s the ability to create profiles for the kind of things like accessing sensitive files or running certain executables, privilege escalation, suspicious network activity – these are the kind of things that we can detect at runtime using eBPF.

Why contribute project to the CNCF?

Mike: You mentioned that Cilium was contributed to the CNCF. What was the reason you brought the project to the CNCF? Also, what does that mean for the governance of the project?

Liz: It’s a big step to contribute a project. Because we hand over the intellectual property to the CNCF. That is something that Isovalent used to own and no longer owns. And the governance of the project really needs to be in the hands of the community. So, Isovalent remains the most prolific contributor, but – and this is again part of my role – encouraging more people and more organizations to get involved in not just code contributions and not just documentation contributions, but also the kind of broader evangelism of what Cilium is and the advantages of Cilium.

So, yeah, we’ve really embraced that community. And I think the phrase that we’ve used internally is “paved the world with Cilium”.

And the best way to pave the world with Cilium is to give it to as many people as possible, and the CNCF gives us a really great route to reaching all those people who are using Kubernetes. It gives those people confidence that it doesn’t matter what happens to Isovalent, the Cilium project is in the hands of a much, much bigger organization at this point.

And then, you know, that subset of people who are using Cilium, but then, find themselves needing Enterprise features. We won’t necessarily be the only Enterprise distribution, but there’s no doubt in my mind that we have the greatest expertise. So, hopefully, we will be the obvious choice for someone looking for Enterprise features or Enterprise support agreements around Cilium.

Trademark


Mike: This actually leads into my next question, which is that CNCF actually owns the trademark for Cilium, but your product, the Isovalent product is called Cilium Enterprise. And so, hypothetically, another company could make a product called Cilium Pro. I mean, I looked at the contributors and I went down eight contributors, they all work for Isovalent, I didn’t have time to go any further, but, obviously, your company has a lot of expertise, but still, the prospect that company spent a lot of money defending their trademarks, I almost never heard of anything like that – is it sort of terrifying, though?

Liz: I mean, at one level, yes, it is kind of terrifying. And Cilium is a brand name that is better recognized today than Isovalent is. And that’s a challenge that we have to embrace. And there are rules around what you can and can’t use – I think that there are probably still a few instances of documentation and use of the word Cilium, which we’re not really allowed to do any more, that we haven’t managed to tidy up everything.

There’s limitations on what you can and can’t use around a name based on what is now a Linux Foundation trademark. But everybody understands there’s a transition between us having a trademark and then giving it to the foundation. It obviously takes a little while to tidy up all that options around that, yeah. So, Isovalent Cilium Enterprise is the Isovalent distribution of what is a CNCF-owned community project.

Outside Contributors


Mike: I mentioned that there’s a lot of Isovalent engineers who are contributing code, but are there other engineers who are also contributing?

Liz: Absolutely! Google is quite a prolific contributor, Cilium is actually used in Google’s Dataplane V2, we have maintainers from Datadog, again a huge adopter who has been using it. Enormous scale – there’s some really good talks from Datadog talking about the scale of which they’ve deployed Cilium, we have contributors from Palantir.
Yeah, there’s several what we call committees, so maintainers of the project, who come from lots of different organizations. And then we have – I think it’s around 700 contributors in total. Isovalent today is just over a hundred people. The contributor base is much, much wider than just Isovalent. That said, we probably have the largest group of people working full-time at Cilium.

Market Segmentation?


Mike: On the commercial side, for infrastructure, the marketing is very horizontal, but have some natural segments worked out in terms of the customers who convert from open source to a commercial relationship with Isovalent? And are you figuring out that there’s any ways to segment the market here or the messaging?


Liz: I think that’s something we’re learning – I have just mentioned that we’re about a hundred people now, so we’re growing in our capabilities for how we target different customers and different verticals. We’ve had a lot of success in financial verticals media, quite a few transport, strangely enough. Yeah, so there’s a pretty wide breadth of Enterprises who have adopted this. I guess, the prerequisite for nearly all cases is that there are Cloud Native Kubernetes users, or that we do have some users who are using Cilium in a standalone load balancer scenario.

Have we figured out how to market to all of these different types of businesses? We’re absolutely still evolving and learning. But I think the fact that we’ve for many years had this very community-based focus, a very community-based approach, means that we can establish relationships and have trusted sharing expertise on a technical level that then encourages those engineering teams to recommend us internally.

And when it comes to making a choice about an Enterprise product or whether they need commercial support, those engineering teams already know who the experts are, and have potentially already had help from our team through the open-source community.

Team Location


Mike: Is there an Isovalent headquarters office where engineers go in, or is everyone like spread around the world?

Riz: We are fully distributed. We do have offices in Zurich, where Thomas is based, and in the Bay Area, where Dan is based. And I think that the timing, you know, really around the pandemic, just at the point as Isovalent was growing was sort of around the same time as the pandemic hit. So, inevitable that we were going to be remote based.

And as people have joined, they joined from countries all around the world. We have people from as far as long as Japan, or Alaska, Australia, throughout Europe and across the U.S. So, our team is really now fully distributed, and the culture has to embrace that. So, we’re very much focused on being remote first.

We do get the team together, and we try to get the whole company together, at least once a year. And we have a lot of encouragement around getting teams together in what we call hive time. Because we’re all about kind of bee-related metaphors.

Monetization: What features are enterprise?

Mike: I’m curious about monetization. It sounds like it’s open core, and what are the extra bits that you’re offering, I guess, in the Enterprise? And how do you decide what to make open source and what to add as an extra feature in the Enterprise distribution?

Riz: I see that the term open-core can sometimes come with a bit of a negative connotation. Sometimes people think of it as an open-source software that’s got some kind of, you know, been cut off at the knees, and that’s absolutely not what we believe in.

We absolutely believe in the open-source product being genuinely usable, and there are some pretty large organizations who continue to use just the open-source version. The kind of things that people will come to us for will be — there are some high availability features, there are things like BGP support for connecting into your legacy data center workloads, some Telco specific protocols that we’ve worked on – we very much don’t want people to feel that there’s something that’s core to their basic use case that they can’t do with Cilium.

Unless they are big enough that they’re the kind of organization that wants to pay anyway. You get to a certain size of organization, where you really don’t want to be just relying on open source with no sense of who’s going to support it when anything goes wrong. And they may come to us for features, they may come to us because they just want to know that somebody will be there to help them, you know, with a contract in place, should anything be needed.

Features for Growth


Mike: We mentioned that Cilium is a really broad product. Is there one particular product feature that you see driving the most growth, going forward in the next couple of years?

Liz: That’s a really great question, because we do have you know really, really powerful features in a number of different axes. So, for example, we just did a partnership with Griffon, where we’re building some really great dashboards, again a big part of this is available, completely open source.

There are also going to be some additional Enterprise features here. Perhaps the thing that strikes people is that they get this amazing visibility. And you know, that could be the moment when they realize, “Huh, look at the power of Cilium!” And the fact that we can see all these latency metrics or security information being shown in a visual way. So, that could be one thing that really drives growth.

It could be Service Mesh. We have a very efficient approach to doing sidecars Service Mesh in Kubernetes. Service mesh is one of those features that when it first started being talked about in probably 2018 – huge hype, huge excitement – the reality of people adopting Service Mesh, they found that it’s actually quite resource-heavy, there are issues, instrumenting all your workloads with these Service Mesh sidecars.

I think some of the realities of deploying Service Mesh had not quite lived up to the initial expectations. And then, last year, we announced the sidecarless approach that Cilium can bring. And mostly through the power of eBPF, it’s incredibly efficient. We can shortcut a lot of the path that a network packet has to take through the Service Mesh.

So, I think that’s another area that can be a real driver for growth, as people realize they can get all the benefits of Service Mesh, but without the overhead that they’ve come to associate with it.

And then, finally – security. I think I mentioned earlier the runtime security tooling that we’re able to provide through eBPF and through the Tetragon project, combining in a really performant, efficient security tooling. At the moment, everybody’s focus in security seems to be on supply chain, but they also still have firewalls. I’m quite a big believer that we have runtime security, everybody has runtime security in the form of firewalls.

We just were on the cusp of people understanding how powerful this new generation of runtime security tools can be to essentially firewall, not just Network packets, but things like bad executables or unexpected privilege escalations, that kind of thing.

Mike: Does the breadth of the product ever feel like a curse? Wouldn’t it be so much easier if there was just one application, and we can focus the marketing message and the sales, and all is just this one thing?

Liz: I’m sure the marketing team tasked with coming up with a tagline would find it a curse, yes.

Lessons for Open Source Startups?

Mike: So you’ve been in the techs business for a long time, taking off your Isovalent hat for a second and just as an observer of the startup scene, and other than the open-source scene in, do you have any advice for particularly entrepreneurs? Because this podcast is really designed first for founders, any advice for founders?

Liz: Yeah. This is actually something I’m getting increasingly interested in and I’m working with the CNCF on how we can encourage businesses on how to operate and be successful with open-source based businesses. There’s two sets of vendors who I would say have quite a lot to learn, particularly if they come into like a Cloud Native community audience.

There’s one class of vendor who is open-source based, they have an open-source project that they’re building their business around. The second class is people who are not open-source, but they have a product that they want to sell into the primarily open-source based Cloud Native community.

I think for both those sets of people, really understanding how powerful community is, Cloud Native community is kind of where I’ve lived for the last, I don’t know, half a dozen years. And it’s incredibly powerful, the relationships that you can build up – not just between individuals, between organizations, can be a really solid foundation for the business relationships that you then build on top of that.

And I think the real lesson for a lot of vendors is: don’t just expect to turn up at an event, pay for a booth or a table, and expect people to come and buy your software. Invest in time as well, invest in contributing, get involved in our project, get involved in the cigs and tags.

Don’t just expect people to immediately think that your open-source project is the one true amazing solution. Take the time to learn what other people are doing around that, and then, have those conversations about why your solution is great and what its strengths and potentially weaknesses might be. Learning to get involved in a community is really, really important.

Closing Notes


Mike: Well, I think that brings us to a close. Liz, thank you so much for sharing and best of luck with Isovalent and Cilium.

Liz: Thank you so much.

Mike: Again, special thank you to Amanda Brock and the whole open UK team for launching the State of Open Conference, where we recorded this episode. Cool graphics from Kamal Bhattacharjee, music from Broke For Free, Chris Zabriskie and Lee Rosevere.

Remember how Liz said that eBPF and Cilium are really good for Service Mesh? Well, remember that, because next week’s guest is Idit Levine the founder of Solo.io.

Until next time, this is Mike Schwartz, and thanks for listening to Open Source Underdogs.

Episode 54: Justin Borgman, CEO of Starburst, the Company Behind the Presto Project

Intro

Mike: Hello, and welcome to Open Source Underdogs. I’m your host Mike Schwartz, and this is the episode 54, with Justin Borgman, Chairman, CEO, and Co-Founder of Starburst, the company behind the Presto Data Access Project.

Before we get started, I have a quick request – we all want to help open-source founders and startups. I make the podcast, but I need your help to get the word out, so tell your friends, post on LinkedIn, tweet out a link, post on Hacker News, or follow me and share one of my posts on LinkedIn, whatever you think makes sense, go for it.

One of the themes of Machiavelli’s the Prince is Virtu e Fortunavirtu meaning excellence in your domain, and fortuna meaning luck, whether good or bad. I really like how the story of Starburst exemplifies this 500-year-old insight.


Justin has a ton of domain virtu. He has deep technical knowledge, but he’s also on the lookout to harness fortuna. He’s one of the few podcast guests to acknowledge it. And Starburst earns its name because it’s one of the most stellar open-source business success stories I’ve heard in the last few years.
There’s so many great insights in this episode, a lot to think about. So, without further ado, let’s get on with the interview.

What Is Presto?

Mike: Justin, thanks for joining the podcast today.

Justin: Hey, Mike, super glad to be with you.

Mike: Before we dive into the business stuff, I find it’s helpful to talk a little bit about the technology. Can you start by giving a brief history of the Presto project? What it’s good at, and how the community coalesced around it?

Justin: It was really back in 2012 for developers at Facebook, Martin, Dain, David, and Eric came together to create a new infrastructure project that would be a faster way of querying data at Facebook. Facebook, of course, collects massive amounts of data, hundreds of petabytes worth of data , and needed a faster alternative to a prior project that they also developed and they called Hive.

Hive was a SQL engine for Hadoop, and it just wasn’t fast enough. So, Presto was created to be a faster means of accessing that data. But it has one really important differentiation in addition to the speed, which is the ability to access data anywhere. So, it’s like a database without storage – that’s kind of one way to think about it.

So, it looks at storage in other systems, which could be Hadoop, it could be S3 and AWS, it could be a traditional database, like Oracle, or Teradata, or Snowflake. And regardless of where that data lives, Presto can reach it, query it, and deliver SQL-based analytics.

So, that’s kind of what makes it special, is the ability to access the data everywhere. And that’s gained particular momentum, I would say more recently, as many large enterprises have data silo problems, where they have data in a bunch of different databases, and are now perhaps moving to the Cloud in some fashion.

Mike: And if I’m not mistaken, high concurrency is one of the areas that make sort of this data access plain different?

Justin: Yes, exactly, it’s very fast, and can support high concurrency. And in a lot of ways, this technology was sort of, I like to say built in reverse, in the sense that it was tested at ridiculous scale from day one. You know, very often, when you start something new, you don’t really know how it’ll work at scale until you get people using it. But because it was really born out of the internet companies, Facebook, and Uber, Airbnb, and Netflix were all early adopters to use the technology, it was really tested, and at scale, and as a result delivers great performance and concurrency.

Origin Story

Mike: Starburst is not your first company, you are part of a team at the company called Hadapt that’s sold to Teradata in about three and a half years, I think.

Justin: Yep.

Mike: How did that experience lead you to Presto?

Justin: In a lot of ways, this is really a continuation of that journey that began 10 years ago. So, that was 2010 that I started Hadapt. Hadapt was a spin-out actually from Yale University and the computer science department – there’s some research called HadoopDB, which was pretty pioneering research at the time, in terms of thinking about Hadoop as a data warehousing solution, and being able to deliver fast SQL analytics on top of Hadoop.

So, we spun that out, raised Venture Capital, built that business over nearly four years, as you mentioned, and then sold it to Teradata. We had ups and downs, definitely lessons learned through that experience. And I think, really, my discovery of Presto after arriving at Teradata in 2014 was kind of an exciting opportunity to reimagine the strategy that we had with Hadapt.

So, Hadapt was the SQL engine for Hadoop, Presto is a SQL engine for anything essentially, allows you to access data anywhere.it was an opportunity to basically take all the lessons learned from the first experience and start to apply them over again.

It was actually my team from Hadapt that ended up contributing a tremendous amount of software to Presto, and working with the guys at Facebook, who created it to really make it an enterprise-grade piece of technology. And I think, as we started to see Presto get more and more capable, and see more and more people use it, that was what created the idea in our head that maybe there was a business to be formed around this.

Community Engagement

Mike: It’s a really interesting opportunity, and I can’t actually think of another example like it, but when I’m talking about open source, I sometimes talk about three types of open-source companies. One would be volunteer, where a bunch of guys or girls get together and write some piece of software that they love, but not necessarily for a business.

And then, I talk about corporate open source, where there’s some piece of software, where a company funds it, but it’s not their core business, but then, they realize that makes sense for them to collaborate like Kubernetes, let’s say ,and Google, and these pure-play, open-source companies, where the company behind it is developing it, and they’re the main contributors.


And so, lots of great open-source projects come out of this corporate open-source area, the podcast that is mostly focused on pure-play because they were trying to help entrepreneurs and founders start open source, use open source as part of their business model. But you’ve sort of, like, created a very interesting situation, where you have a mix of corporate and pure-play because you’re benefiting from, not just the community, but, really, Facebook is a big contributor to the project to — I heard almost 50/50. So, how’s that really evolved, and how do you continue to encourage this very symbiotic relationship?


Justin: You’re right. Preston has a very interesting history to it, an interesting journey. It started as a small project at Facebook. When we got involved at Teradata, we were able to apply a few million dollars a year of R&D budget into advancing that as well. And then, of course, you’ve got a few other companies contributing also along the way.

And, as a result, all of that kind of accelerates the development of the project. And I think that maybe what’s most unique here is not only that Facebook created great infrastructure software as a byproduct of their business – they’ve certainly done that before – but rather that there was kind of a commercial partner very early on, and myself, and my team at Teradata thinking about the commercial applications of this.

So, you know, back in 2014, Presto was still in its early days, Facebook wasn’t trying to monetize it obviously, that’s not their business, but we were already thinking about how this could be used by Fortune 500 customers, and what difference this could make to their business. And I think that led to its very enterprise-applicable evolution, and set us up really well to eventually commercialize this in 2017, when we left Teradata, the creators of Presto joined us from Facebook. And we went off on our way to build this business.

Idea Incubation

Mike: So, you were working on Presto while you’re at Teradata. And did Teradata ask for any equity, or how did that work when you told Teradata, “We want to start this company basically working at Teradata? Like, what was that like?

Justin: Yeah, well, what was interesting about that – and I guess just to set the context, I think Teradata, from 2014, when they acquired my company through to probably today, has gone through various iterations of kind of rethinking their overall strategy, in terms of how they evolved into this next generation of sort of Big Data platforms. Because they had great success in the ‘80s, ‘90s, and early 2000s, as this kind of monolithic data warehouse, where you would ingest everything and store it in one place.

But obviously that became very expensive over time. And the appliance model, hardware and software combined, wasn’t necessarily set up for this future as people move to the cloud. So, they’ve gone through a lot of iterations. And it was really in that iterative process, where they weren’t really clear where they wanted to go, that they actually felt like Presto is maybe a distraction for them.

So, that actually created the opportunity, I think, for us, to say, well, we think it’s a little more than a distraction. And, you know, we’d be happy to sort of take that off your hands and work on this together.

So, it was a very amicable split – we remain partners, we’re still partners today, where we work together on some customer accounts, the technologies work together, we can access data in Teradata, for example, from Presto. So, that partnership remains. But it was one that I think for them, they viewed us as sort of taking Presto off their hands because there were maybe close to a dozen companies within their customer base that were using Presto. So, we were able to deliver really first-class support to those customers, you know, not provide any interruption there, even as we left and formed this new business. So, they don’t own equity, it’s purely a partnership.

Identifying Opportunity

Mike: It’s just amazing like how you deal your business, is you got a huge company Facebook to help you grade and test this infrastructure. You got to do R&D in Teradata, and then you started the business with customers – it doesn’t get any better than that really.

Justin: Now, you’re absolutely right. And believe me, the good fortune is certainly not lost on me. You know, advice I give to entrepreneurs of any type, not just open-source entrepreneurs, is to just have your eyes open to opportunity. I think it passes us all by all the time, and very often we miss it. And I think seeing it, and then, you know, running and jumping on it, it certainly has been beneficial in my career. I’m even going back to my first company and spinning out technology from Yale, which you could argue was the great benefit of various government research grants, funding that research in the first place. So, keeping the eyes open and seeing an application for where it could become a business.

When To Raise Money

Mike: So, initially, you didn’t have to raise money because you had some customers that came that provided some runway, but you did raise a series A, and I guess, October 2018, so, pretty recently. So, what was in the decision process to say, “Okay, now capital is going to help us.”, like what were some of the benchmarks that you reached, that helped you say, “Now is the time we should do that.”?

Justin: So, that’s exactly right. We started without raising any capital. That allowed us to build a profitable cash-flow positive business over those first two years of operating, which I think, by the way, as an aside, gave us a lot of opportunity to be patient and sort of think through exactly what we wanted our go-to-market strategy to be, what kind of strategy we wanted to take around monetization.

And we didn’t have the pressure of investors necessarily breathing down our neck, which I think many, many entrepreneurs have in those early days. So, I think it was a great way to start a business, what forced us to change and actually consider taking capital was really a realization that the market opportunity was bigger than we felt like we could actually satisfy growing at purely an organic rate.

So, we took that series A really as a growth round, you know, even though it’s called the series A, I think it’s a little bit misleading, because it’s probably more like a series B for most companies in that. Not only was it a large amount of money 22 million in that first round, but it was really deployed towards expansion and rapidly growing the business. Less so about proving product/market fit, which is more typical in a series A.

As you said, we did a series B shortly thereafter, which was probably more like a series C, adding another 42 million. So, we’ve gone from raising nothing to now 64 million. And really I think that was all made possible by really building the fundamentals first. Making sure you have that product/market fit sorted out, and then, you know, applying fuel to the fire to expand.

Revenues Pre-Investment

Mike: What was the revenues when you raised the series A?

Justin: Yeah, well, if it was 12 months looking forward, I would say it was already looking north of $10M at that point. So, that allowed us to really take the funding and apply it to, again, expansion rather than kind of sorting out the basic product details.

Mike: And what year did you actually start the company?

Justin: 2017.

Mike: That’s pretty amazing – two years to go to $10M. It’s pretty stellar.

Justin: Thank you. I mean, again, I think a big advantage here was that, in some ways, this was like building the same company over again – I mean, there are a lot of differences between this and my first, but they’re also enough similarities, just in terms of the types of customers that we sell to, the types of use cases, the types of problems that they’re trying to solve. So, I think that historical knowledge was advantageous for us to just move a little bit faster this time around than we did that the first time.

Balancing R&D Investment

Mike: Okay, switching gears a little bit into more basic business stuff. You mentioned in one of your previous interviews that I listened to, that Starburst is basically pursuing an open-core strategy. So, performance, robustness, security patches that goes into open source, things like connectors, security, ease of use, I guess GUI deployment stuff, goes into the core. One of the questions that I’ve sort of wonder about is, how do you decide how to prioritize R&D in open source versus the enterprise features when you go the open-core route?

Justin: Yeah, I mean, I think that’s the key question. So, it makes sense why you’re asking it, and I think it has to be on the mind of every open-source entrepreneur. And it’s a delicate balance because, on the one hand, you want to make the open-source project as useful as possible to get widespread adoption. Because really that’s your lead generation vehicle – I think that’s the way to think about it.

A lot of people say open source is really just another form of a freemium business model. There’s a free component, and that just happens to be open source in an open-source model. And then, how do you kind of upsell to the Enterprise version. So, for us, I think the logic was, what are the reasons why people use Presto anyways in the first place.

And we think performance is a core element to that. So, we wanted to make sure that performance is always great, right out of the box, with the first experience of it, including the open-source version. So, that’s why a ton of work goes into open-source around performance enhancement, scalability enhancements, those kinds of things.

And then, we think about, well, what do people in enterprises, who are willing to pay for this stuff, what do they want. And that’s where it is, things like security features, which are just essential for any large, mature enterprise things, like role-based access control, data masking, if you’ve got social security numbers or credit card numbers, being able to mask digits appropriately, having audit logs for querying.

And then, because Presto access is all these different types of data sources, it also made logical sense that if you’re going to access a database like Oracle, or Teradata, or IBM, all of which are very expensive in their own right, well then, a customer, probably, is willing to pay for enhanced connectors to get faster throughput to those systems.

So, that was kind of the logic was trying to like think through what are the enterprise features that someone is willing to pay a premium for, versus what just produces an out-of-the-box great experience. Because I think so much about open source is really people doing their own self-evaluations of the technology. So, self POCs, if you will, so, you want to make sure that’s great, because you can’t control that. You may not even know who downloaded it in the first place. So, that’s where you really want to put I think a lot of energy into the open-source project. And then, it’s as more of those production features that are important to the larger enterprises, where those I think you can hold back.

Why Not 100% Open Source?

Mike: I interviewed Mike Olson from Cloudera, you might know him.

Justin: I do, oh, yeah.

Mike: He was one of my first guest, and he gave a very similar comment to what you were just saying. And he was quite emphatic about it. And yet, Cloudera recently switched to a 100% open-source strategy. And other open-source companies have also, for example, Chef, and of course some of the older, Linux distributions are, RedHat and SUSE are all open source.

And so, one of the things I’ve been wondering myself is, you can use the open-core strategy. It makes perfect sense I think to business people, but I also wonder, this license is paying for the right to use the software. Do you think that customers are actually paying for the right to use, or they’re paying for the engagement with your organization? And do you think, if you made it all open source, it would actually negatively affect your revenues, or customers would still want to engage with Starburst a company?


Justin: I think I can speak from experience here, because part of what’s interesting about our history is that we’ve kind of evolved through the various open-source business models in our brief history. So, when we first started the company, we didn’t have any proprietary IP, so we naturally just sold support contract. So, the early customers that we started with were just support contracts.

I think the challenge that we quickly identified is that support alone is not the most compelling value proposition. It is to some, I’m not saying it’s not, but it’s not a sufficiently compelling I think to win over a broad set of customers.

I think that’s where the open-core model, at least for us, really created an inflection in the business, where, you know, now we had a real tangible reason. And, by the way, for what it’s worth, I think we learn this actually from our own prospects, that those who are actually huge fans of Presto, who are huge fans of us even, who were champions of what we’re doing, but couldn’t quite get the purchase across the line in those early days and that first year of our operation, because they couldn’t justify or explain to their boss why one would have to pay for something that was free essentially. And that was the tricky conversation was like, “Well, you get this for free, why would you pay for it?” Like, “We don’t need support, you guys are smart, you can support this, right?” And those are the kinds of conversations that can take place. So, I think that’s where the open-core model is really helpful to the business.

Monetization Strategy

Mike: You’re selling a product that’s almost like a data access product, like I call the Presto Interface, and it connects two back-end databases. How do you price an interface, like what are the buckets – I don’t need to know the price but I’m just wondering like, how do you land and expand, and how do you set up the model, so that it’s easy enough for customers to understand, and you can charge enterprise software rates for it?

Justin: The way that we monetize this is based on CPU consumption. Technically, we actually anchor on Virtual CPU consumption because so many of our customers deploy in Cloud environments. So, that’s the underlying metric, and the reason that’s a good proxy for us is because basically Presto is a technology that scales out super effectively, and is leveraging compute-intensively to execute the query.

So, it’s basically, like, the more queries you have, the more data you’re accessing, the more complexity of the workload, and the more users who are hitting the system you talked about, the strong concurrency that Presto provides. Those are kind of the dimensions that drive CPU consumption up, and we just monetize with that. It’s a straightforward metric I think that customers easily understand, and seems to work for us.

Optionality

Mike: In one of your previous talks I listened to, you talked about optionality, and how you recommended basically that optionality essentially drives freedom – how does Presto help you get that optionality?

Justin: Presto creates optionality by virtue of being disconnected from storage, is essentially not having its own storage layer. I used the analogy in the beginning that we’re like a database without storage. The other way I put it for people who are familiar with data warehousing is, we provide data warehousing analytics without the data warehouse. That’s another way to think about it.

So, because of that, it basically allows you to think about Presto as an abstraction layer, above all the data sources that you already have. And you can kind of skip the complex and time-consuming task of having to move data around, create copies of data, ETL it, extract it, transform it, and load it into another system, instead you can just do that at query time, and access that data, and get your results.

So, that gives you a lot of flexibility, and I think one of the ways we’ve seen that play out is, we have a lot of customers that have a classic data warehouse, maybe it’s Teradata or Oracle. And then, they’ve got some kind of a data-lake strategy, and maybe that’s either Hadoop on-prem, or maybe it’s S3, or some Cloud-object storage.

And the first step might be to use Presto to just join tables between these two systems. You’ve got some kind of user behavior logs in your data lake, and you’ve got billing data in your classic data warehouse, and you want to be able to correlate the behavior with the billing, let’s say. That would be a very common use case for us. You can do that with a simple query and Presto.

Now, what that allows you to do then, as a second step, is, essentially, hide from your own end-users, be them internal analyst, data scientist, or even customers. Where the data actually lives, they don’t need to know that they need to go to the data warehouse to get the billing data, and they need to go to the data lake to get the user behavior – they’re just submitting a query, and they don’t know where the data lives anymore.

And by doing that, you’re able to actually decouple your end-user from where the data is stored and give the architects in the organization the ability to now decide, based on cost or performance, where that data should actually live. So, you don’t need to pay Oracle or Teradata tremendous amounts of money to store your data anymore. That is, of course, the most expensive storage you’re going to find.

You could instead choose object storage, like Ceph from RedHat, or there’s a company on the West Coast called MinIO, which creates S3-compatible object storage. And that’s very inexpensive, relatively speaking. And you can deploy all of your data, or start to migrate your data into this lower-cost storage, and still be able to access it, while your end-users are none the wiser to where the data lives – they’re just getting their results. So, I think that’s where you kind of get to create this optionality and be flexible about where you put your data over time.

Mike: In addition to the technical level, I always think about optionality as, does the open-source license itself also lead, or open-source infrastructure in general, also lead to more optionality and freedom?

Justin: For sure. I mean, I think the notion of not having vendor lock-in is really important to customers. Increasingly so, I think they’ve been burned over decades of very expensive technology that becomes legacy technology, and then, their stock and the pricing goes up. And they don’t feel like they have much ability to resolve that. And I think the open-source license in and of itself gives customers a lot of comfort, in knowing that, you know, a worst-case scenario, they can always roll this themselves, with the open source. But also, Presto is able to read open data formats, which is also great. Because I think data lock-in is probably the worst kind of vendor lock-in.

And in a traditional database system, once the data is loaded into the database, it’s kind of not easy to get access to or get the data out, without continuing to pay for that database system. But if you’re using open data formats, which we’d really pioneered during the Hadoop era, these are like ORC or Parquet, if you’re familiar with those file formats, you can store them anywhere and query them with a multitude of tools. You could use Spark to train machine-learning models, working off the same Parquet files that you’re querying via SQL for Presto. And I think that gives customers a lot of flexibility as well.

Open Source V. Commercial Market Size

Mike: I read a lot of articles about how enterprises are really moving towards open source, certainly when you look at the large consumer-facing services, like you mentioned, Netflix, Facebook, etc., they’re building a lot on open source. Then, you look at the size of the market, and you see that, actually, from a market percentage of open-source software is still only a tiny amount – is the move to open source really real, or is it more hype than reality?

Justin: When you say the market is small, do you mean measured in dollars, or what’s the metric there?

Mike: Dollar, yes.

Justin: Yep, makes sense. And that’s the key piece. I think it’s probably super widely used, but the percentage of open source that actually gets monetized is relatively small. And I think that’s what’s translating to the overall dollar amount, seeming small, relative, to the proprietary solution. I think if you measured in terms of impact to businesses and organizations, I think it’s actually probably the reverse actually, where you might have more open-source software having bigger impact than the proprietary.

But, of course, the challenge – and I suppose this is the purpose of your podcast – is figuring out how to monetize that effectively, so that you can build a successful business, while having that broad impact that open source provides. And I do think that, as vendors, we’ve gotten smarter over the years about how to do that.

I mean, the way I think about open-source business models over history is that it started with the sort of pure-play support model, just offering support, nothing proprietary. I think kind of Generation 2 was the open-core model that we’ve spent time talking about. You know, Cloudera popularized that, as did many other companies. And I think Generation 3, which is actually where we’re moving as well as a company, is cloud-hosted, SaaS offerings.

And, basically, being able to make part of the value proposition, the simplicity of the solution that you can deliver as a SaaS, and I think data bricks is a great example of that. So, I think that’s kind of the next frontier. And I think, as more and more open-source companies move in that direction, I think they’ll probably have better success in monetizing that background usage of the open-source. Because, there’s so much you can control now from a SaaS perspective to really enhance the experience, that is just easier for customers to use your SaaS solution, rather than having to maintain it themselves.

Starburst Cloud Strategy

Mike: I normally ask companies if they’re developing a SaaS offering. And I think that there are some companies where it’s been really successful like MongoDB, Eli Horowitz from MongoDB is emphatic that cloud is the best business model and everyone should be doing cloud. In doing the 50+ podcast, I found that the results have been mixed, where sometimes companies find that it’s a good way to reduce the try by fly time, where the cloud offering is a good introduction, but then the revenues are mostly derived from the enterprise, like self-hosted version.

And it takes a lot of effort to actually — it’s almost like a whole new product, like you’re building a software platform, a great software platform, and then, building the SaaS is almost like a totally new product in different business endeavor. What’s Presto done in this area? Are you working on it? And do you have any thoughts about how that experience is going, sort of making a cloud offering out of the software?

Justin: We definitely are working on it, and we have been actually for quite some time. And it is hard work. I think there’s no doubt about it, but I do think that some recent innovations around Kubernetes actually make this easier than it maybe was a few years ago. Because Kubernetes can kind of create a uniform, almost like operating system, if you will, that you can deploy your software within, and therefore, sort of create the software once, rather than having to have all these different kind of custom versions for different types of deployments.

I think that’s a game-changer. It’s certainly something we’re betting heavily on, as we approached that by trying to create the same experience, regardless of where customers deploy.

Single-Tenant V. Multi-Tenant SaaS

Mike: Most of the old cloud services were multi-tenant, but, are you thinking, like with Kubernetes, we could maybe build a single-tenant and deliver sort of like, “We’ll host it for you, you’ll host it.”, but it’s going to be sort of the same thing?

Justin: That’s exactly right, yeah. You know, I don’t want to give away too much of our strategy just yet because we haven’t released the cloud product yet. But I think those are really important concepts that you highlighted there, that we’re very interested in.

Building A Sales Team

Mike: So, something you must have done a really good job at is building the sales organization, because $10M in sales hasn’t happened by accident. And I think sometimes founders underestimate how difficult it is to build a sales and marketing organization – did you have any thoughts or advice you could share on, like how that went for you, like, how you pulled it off, like how do you do it?

Justin: Yeah. I think the first step I would say is trying to understand yourself as the entrepreneur – what the sales process looks like, like, what are customers buying, how do they understand the value proposition. And I’m a big believer in entrepreneurs selling the first few customers themselves. I think you learn so much, even from a product management perspective of what you need. You get to experience what your sales reps will experience when you start to scale up. So, I’m a huge advocate of that.

The second thing I would say is find a great sales leader. Because you know there are folks out there who have done this many times before, and know what it takes to sort of scale up a sales organization. And, certainly, that was impactful for us in finding our VP of sales, who’s done a great job of really scaling up that organization quickly.

Team

Mike: One question I had was, the pandemic has changed things were much more remote –  were you remote before the pandemic, and what’s your plan for growing the team in the next couple of years?

Justin: We were not entirely remote, but we did have some level of distributed nature to our team. Before the pandemic, we had major teams in Boston, the Bay Area, and then, actually Warsaw Poland as well, as an important development center for us. So, we kind of had to work across these three geographies, which are obviously spread out by 9 hours of time zones. And I think that gave us maybe a head start on the pandemic. But to be perfectly frank, I mean, I would much rather go back to actually having an office, and being able to interact on a one-on-one basis personally, with so many of these people.

Because I think what’s been weird for us is, we have scaled so quickly this year that I have not met probably half of our employees at this point, which is just a weird thing, to have grown the company so much. And the only interactions I’ve had have been over a Zoom call. So, that part I miss. I do think we’re all trying to make the best out of it, of course. And I think good best practices are sort of documenting everything, having frequent all-hands meetings, where you get everybody together, but there’s still no real substitute I think for one-on-one interaction.

Founder Advice

Mike: The last question, any advice for new entrepreneurs who are launching a business, and they want to use open-source software development as part of their business strategy?

Justin: My advice would be to think early about that key question that you asked earlier in the podcast about what your monetization strategy is going to be, and on along what metrics are you going to, or what criteria I should say, are you going to be separating the enterprise value proposition from what you give for free, and I think kind of have a strategy early on and stick to it. Because I think that will just make the decision-making process so much easier for you as you go along. You won’t have to debate each and every feature that you come up with – you’ll just sort of know because it will fall into a framework. That would be my piece of advice.

Close

Mike: Justin, thank you so much for sharing all this knowledge and experience with us.

Justin: Thank you, Mike. This was fun, and it was great meeting you.

Mike: Thanks to the Starburst team for reaching out and coordinating the podcast. Audio editing by Ines Cetenji, transcription and episode website by Marina Andjelkovic. Cool graphics by Kemal Bhattacharjee. Music from Broke For Free, Chris Zabriskie and Lee Rosevere.

Next time, we’re joined by Miguel Valdes Faura, CEO and Co-Founder of Bonitasoft, a global provider of BPM, low-code, and digital transformation solutions.

Until next time, stay safe, and thanks for listening.

Episode 53: Rajoshi Ghosh, Co-Founder of Hasura, Controlling Access to Data with GraphQL

Intro

Mike: Hello and welcome to Open Source Underdogs. I’m your host, Mike Schwartz, and this is episode 53, with Rajoshi Ghosh, co-founder of Hasura, a relatively young startup, using GraphQL to connect Enterprise data. I’m happy to report that Rajoshi is the first Indian national we’ve had as a guest on the podcast, a trend which I hope continues. Although she’s normally based in the Bay Area, Rajoshi was in Bangalore in late July when we recorded this.

Before we get started, I have a quick request – we all want to help open-source founders and startups. I make the podcast, but I need your help to get the word out, so tell your friends, post on LinkedIn, tweet out a link, post on Hacker News, or follow me and share one of my posts on LinkedIn, whatever you think makes sense, go for it.

As I mentioned, Hasura is a young startup, but given their success in momentum, I thought it’d be interesting to hear their stories sooner than normal. If you’re interested in GraphQL you might also want to listen to episode 41, with Geoff Schmidt, the founder and CEO of Apollo.

So, without further ado, here is Rajoshi Ghosh, co-founder of Hasura. Welcome to the podcast. Thank you for joining us today.

Rajoshi: Thank you so much for having me, Mike. I’m really happy to be here.

Origin

Mike: What’s the origin story of Hasura?

Rajoshi: At that time, Michael, we started working together really long time back, and I think at that point, we really wanted to work on something that would make application development easier, but we did not know what shape or form this would take,  and so, what we started doing was, we started building products for — started off with friends, and then, moved on to like local startups and then started working with one of the largest banks out there, help consulting with them.

We realized that if we were building enough products across different types of companies and different industries, then we would learn a lot about the different businesses, and also, it gives us an opportunity to try and build tooling that can work across companies of different sizes and different industries and verticals.

So,we got into this consulting business that we did, but the entire time we had a small team that was continuously building different products that could be used across different clients that we were working with. So, we did that for about three and a half years, and then, it came to a point, where we built a bunch of these tools, and you know, we were faced with the decision of signing like a multi-year contract for a consulting gig with a really large bank or actually going back to saying, “Okay, let’s take these products to market and build a business out of it.

So, we decided to start Hasura, wind down the consulting practice. So, that’s kind of how we set up the tools, that, like, parts of Hasura were built. So, what we did after that was, we spent a few months taking these different pieces that we built to market, trying to open-source a bunch of them, saw how folks were reacting, trying to understand the business implications of these products being used.

And that’s kind of how the Hasura GraphQL engine, which is our open-source product sort of came about. You know, we spoke to a bunch of people, realized that data access was a big problem that people seem to be struggling with across all kinds of companies, and again, different sizes of businesses. So, that was the piece that when we open-sourced and we wrote about it, and we put it out, and I think the first blog post that we had about our product resulted in our Fortune 500 health care company, reaching out to us and saying, “Hey, we really want this.” So, we knew we were onto something. So, it started out with this consulting practice, building pieces of this data access problem, from there, and then kind of polishing it up and launching it as the Hasura GraphqQL Engine in 2018.

How Is Hasura Different From Apollo?

Mike: A few episodes back, we had Geoff Schmidt, one of the founders of Apollo GraphQL, and although this is a business podcast, not a tech podcast, we have a lot of tech listeners out there. So, maybe you could just give a quick overview. I know that Apollo is part of the community, you’re part of the community, and the products are different, but maybe you could just give a quick overview of like how the products fit in the market?

Rajoshi: Absolutely. At Hasura, we kind of came at this problem, from the data access angle, we were trying to solve the data access problem, and back in our consulting days, we have actually built our own version of GraphQL called Urql, and we had that whole thing going. And every time we would talk to people about what we were building – and this was around the time GraphQL was getting popular, people would tell us, “Hey, this sounds an awful like GraphQL, why don’t you add support for GraphQL?”

So, that’s how we sort of braided into the GraphQL space, but we sort of came at it from the data access piece, so, what Hasura as a product does today is the service that you connect to your database and other data sources, and it kind of instantly gives you GraphQL APIs. So, it’s sort of short-circuits, the path, like you don’t really need to build a GraphQL server, Hasura kind of becomes that piece in the middle that connects to your database and other services, and gives you these APIs. And Hasura gives you a metadata engine, where you can specify the relationships between your different pieces of data – you can add authorization, logic, we have a very granular authorization system built in. And then, you can start accessing these APIs directly from your front-end clients.

That’s how we fit into the GraphQL ecosystem. And now, we have our – Hasura is available as a cloud product, and what you also have is, you have a lot of features that help you kind of run Hasura production. And there’s a little bit of overlap with some of the things that Apollo engine does, which is basically, like monitoring and analytics, and sort of add that API layer. So, these are the features that we have in common, but the problems that we’re solving are very different.

I think Apollo is coming at it from the side of being, like a GraphQL Gateway, where every different service speaks GraphQL, and they’re kind of the GraphQL Gateway. And they are building tooling at that GraphQL Gateway sort of layer, where, we are sort of more on the infrastructure layer, where we are solving the data access problem. And we give you GraphQL APIs.

Lessons Learned

Mike: If you could go back to that day when you said, “Okay, we don’t want to take this contract, we want to move forward with a software company.” That must have been a little while back, but if you could go back to that day, would you do anything differently in terms of how you executed after that?

Rajoshi: That’s a very interesting question. I would say not. Because what happened, like, the steps that sort of followed from there, we took the product, we had built some great text, so, we raised some seed money based on some of the tech built, we took that to market.

And once we put out the GraphQL engine on like, we did a show and launch like a Hacker News launch. And that was a pretty good launch that a lot of people found out about the product, and usually what happens is with Hacker News launches, they are very transient. Somebody finds out about it on one day, sometimes it goes great, but sometimes, there are new products being launched that every single day.

But I think what helped us sort of stick around after that initial launch was the fact that when people started trying it out and looking at our documentation, there were two things that I think really helped us over there. One was that either documentation was very complete. This was also because this was a problem that we’ve been at for a while.

And the second thing was that getting started experience was magical, like it was 30 seconds to your first GraphQL API. You would connect it to an existing database, existing Postgres database. And you would instantly get APIs. So, that sort of helped us get the word around, got people excited. And they spoke about it to each other, and that started off our sort of developer adoption journey.

So, we were still tagged Alpha back then, and we already saw all kinds of companies starting to use Hasura, and putting it in a very critical part of their stack. So, what happened is, we hadn’t actually started building a commercial product just then, we just put this out and we were still trying it out. But because of the kinds of companies who’ve started using us, they started calling us inside, saying, “Hey, you know what, we’re using this — if this goes down like who are we going to talk to, like, can we sign a contract with you. And then, he started getting these calls from companies, and that also helped us sort of like inform our kind of roadmap of how we were going to build into our Enterprise product. And then, we launched that earlier this year.

I think the journey has been one of learning, and on all sides of things, like growing an open-source community, growing the usage of an open-source software, and then building a commercial product around it – that’s been a really good journey. And I think the fact that people really, like, the commercial versions of the product as well is something that comes from having been through the journey with our users, listening to our customers and working alongside them over the last two years.

Monetization Strategy

Mike: So, that pivot that you’re describing is really difficult to make from open-source project to commercial product, and you’re probably still making that pivot as we talk, but can you talk about what are your thoughts about the strategy for whether – I heard you mention that you launched a cloud service – that’s certainly a fantastic business model. There’s also a lot of innovation around open core, making certain parts of your product, commercial vs. open source. So, how have you figured out how to monetize some of the open source to fund the company?

Rajoshi: I think the way we’ve been thinking about what comes apart of sort of our commercial offerings is, things that companies using GraphQL engine in production will start needing, you know, when they are in production. Things like monitoring and analytics, stuff like query capture, so that you’re able to create allow lists when you’re in production, prevent breaking changes with regression testing, great limiting of your queries – these are kinds of features that people need when they’re in production. So, these are the kinds of things that we put in our commercial versions.

And the core GraphQL engine, which sort of gets you building and then, you need to self-manage, and you need to build all of these toolings yourself, but the call that sort of gives you the APIs and helps you connect to data systems – that’s in the open-source part. Because that’s part of your critical infrastructure, and you know, being an open-source product, if you’re in the infrastructure I think is almost given these days.

Cloud Positioning

Mike: What’s the positioning of the cloud product? I understand you just launched that, but what is your vision for? Is that going to be a major part of the revenue streams, or is it just from so people can get started and kick the tires quickly – where do you think that fits?

Rajoshi: It’s very new. We just actually announced a general availability, we launched it about 4 weeks ago. So, it’s very, very new, but we do foresee it being a critical part of our like revenue stream going forward. So, what we did is, we actually re-engineered a sort of open-source engine for it to be like a true cloud SaaS product. Both of the things you mentioned are important in the sense that getting started with Hasura on cloud is something that we absolutely care about, that being the best experience for you to get started on Hasura, so that’s extremely critical to us that anybody who wants to try Hasura, the experience of getting started on cloud should be magical.

So, that’s very important, but it’s also something that we’re building for, you know, companies running Hasura at significant amounts of traffic and scale introduction. We have interesting sort of things that we’ve built into the cloud, and one of those is sort of like dynamic data caching. And that’s something that we’ve — I know that the podcast is going to be out about three weeks after we speak, but actually in just about an hour, my co-founder’s going to be speaking about server-side caching and dynamic data caching as part of the GraphQL summit, where he’s going to talk about how we’ve built it, and what is our sort of vision of the cloud, which is something like CDN for data. So, that’s kind of where we see it going, where you build, you connect your data sources.

Data is being fragmented, and data is everywhere – it’s in your databases, it’s a multiple data sources, and you have this managed infrastructure piece in the middle that just has to connect to all of these data sources, magically get this API. And it’s fully managed, it scales, it’s super fast. And so, yeah, that’s kind of the way we look at the cloud product.

Value Prop

Mike: You mentioned that Hasura is almost like a data connection layer. One of the main value propositions must be getting access to your data, but what are some of the other reasons that driving Enterprise customers in particular.

Rajoshi: I think for Enterprises specifically, since that was your question, I think one of the things that we’re seeing and that our Enterprise customers are seeing is that time to value and time to market. So, as people like building with Hasura, and we recently had our user conference, where, Philips healthcare, one of the Solutions architect there, who’s been a Solutions architect for 26 years, spoke about how something that they were building with Hasura would have typically taken them two to four years, but build and ship this product in under a year.

So, companies and Enterprises are saving like quarters and like years of work by using Hasura, because Hasura is just – you get these APIs with access control out of the box. This could be anywhere from like 40 to 90% of the backend logic that you need to write. So, that’s a huge benefit. And that’s kind of what is also helping Hasura spread by word of mouth within the Enterprise. Once one team starts using it, other teams sort of see the pace at which people are building, and that’s helping the word spread within Enterprise for us.

So, that’s one. The second – there’s two other things that, again, we’ve heard our users talk about. One is having better domain understanding. There is this layer that connects to all of your different data sources. You sort of have a better understanding of your domains. And that helps architects and that helps team lead sort of build faster, because as things are very fragmented, Hasura kind of brings that unified view of your different access control rules across different data sources. That also adds to the speed aspect that I spoke about, but that’s also in itself with huge benefit that enterprises are seeing today with Hasura.

And the third one is enhanced security, and again, each of these points of sort of building on the previous thing that I spoke about, which is, we have the Hasura console, which is this UI, where you can see all of these different access control rules. And so, you’re able to see very granular access control rules are set up for, again, all of the kinds of data access that you need to do. So, having that visibility in one UI makes it very easy for again Enterprises to handle the security aspect of data access. These are things that we’ve heard time and again from our Enterprise users as benefits that they see building with Hasura.

And on top of this is the entire GraphQL piece, which is all of the benefits of GraphQL that is making people move towards GraphqQL, the amazing developer ecosystem around the tooling, the developer experience for front-end developers to get started and build products fast. So, the front-end experience with GraphQL along with the themes experience with Hasura to handle all of the different data sources in the access control kind of makes that package really valuable for our users, especially in Enterprise.

Community

Mike: You mentioned the user conference, and I’m wondering what is the current community like for Hasura, and how do you see developing the community, and giving the community enough value going forward?

Rajoshi: We have a really, really engaged community around Hasura, and it’s something that we’re all very, very excited about. And it really makes us very happy, and we deeply care about the community around Hasura. So, more than half of our engineering team is working on our open-source product. There’s continuous development, and we’re listening to our users in the community very closely and sort of acting on things that they are talking about. So, there’s that aspect to it.

And there’s also the aspect of like really helping the learning process. So, we have a very extensive set of tutorials on GraphQL on Hasura, on authorization that we’ve built on hasura.io/learn, which basically the GraphQL tutorials over there are like vendor agnostic tutorials, which are just about getting started with Hasura, whatever sort of stack your come from, especially for front-end developer. So, I think we have almost more than 10 tutorials for different stacks for you to get started with GraphQL.

And overall, the site has I think almost like 15 to 17 tutorials on like full stack, front-end, back-end authorization data modeling. So, these are things that we put out continuously for the open-source community. We have a very vibrant discord community, and we have community champions, who are folks, who are helping out each other and helping out other users who are coming into the Hasura, new folks who are coming into the Hasura community, so that’s where the community hangs out.

And yeah, I think bringing all of these aspects together at the user conference was truly amazing for us two years into launching Hasura that we put out this user conference, it had about 33 talks of which three were from Hasura folks, and the other 30 were from the community, just talking about different ways, in which they are using Hasura different pieces of tooling that they’ve built. So, it was really, really good to hear and good to see the community coming together, giving back, and by talking about how they’ve learned and build things with Hasura.

Community Code Contribution?

Mike: Does the community actually commit any code?

Rajoshi: We do have community contribution that’s happening on console code based, on documentation, on sort of lots of tooling, but yes that is community contribution going into the code records.

Pricing

Mike: Pricing is one of the hardest exercises, not only for open-source startups, but I think for every company. What are some of the gates that you’re thinking about for pricing, and how do you get, for example, intrinsic value based pricing for the customer?

Rajoshi: Yeah, this is something that we’re thinking deeply about and also evolving. We are very, very early in the stage, in this journey. I’m sure, down the line, that we add a lot more color that I can add to this conversation to this topic, but right now, we’re thinking about it as basically pricing on the cloud product, consumption-based pricing, which is basically on data pass-through.

We have a starting tier with certain amount of data pass-through, and then, we’re basically charging on data pass-through. And we have a few more things on, the number of collaborators and the limits we apply on some of the features that you get. But the primary way that we’re thinking about pricing is on the data pass-through.

So, that’s currently how we price on the cloud product, and for Enterprises, which either on the cloud or on, a self-hosted model currently, its feature bundles and pricing per project, which is unlimited usage but pricing for project – that’s how we roll pricing on the Enterprise, but on Cloud, it’s with these usage limits. And that scales as your usage of the product scales, and each of these is for personal project.

Serving SMB?

Mike: So, a lot of software startups, some in your area, are making most of their money in the Enterprise space. I bet you think that you’ll find a way to also offer products and services to smaller organizations.

Rajoshi: I think. I mean, today our users do span the spectrum from the hobby developers to folks in the enterprise, we definitely – our Cloud product is meant to be something that caters to smaller products that are just kind of getting started in introduction. And there’s always open source that you can sort of sell, post and run across any kind of hosting service that is – yes, but the cloud is something that we have envisioned to be anyone running GraphQL introduction should be able to start a pricing would make sense for them economically. And that’s sort of how we’re thinking about it. And like I said, it’s very early days for us. And so, we’re going to sort of observe and see how it scales for us over the next few months and keep tweaking this.

Team

Mike: Right now, you’re sitting in Bangalore, one of the urban hubs of technology, what are your thoughts about growing the team, and how you’ll have to adjust the plan for the pandemic?

Rajoshi: We started, becoming a distributed company early in 2019, I think 2019 was when we brought our first remote colleague on board. And since then, we’ve been hiring across the globe remotely.So, that was very helpful to US during Covid, like all of our communication and all of our working in a distributed manner across different time zones. So, that really helped us when we all went with Covid-19.

So, in terms of growing the team, I think we will continue to hire across the globe in different cities and different countries –  that’s how we’re thinking of growing the team. We do have a base in Bangalore, and we have a base in San Francisco, so, we will look at hiring across these two cities. But we, also, currently, we have people in, I think, over 20 cities outside of these two, the side of Bangalore and San Francisco, maybe even more – I haven’t actually done a proper count, but we have everybody from, like LA to Melbourne, and like everything in middle.

So, we can’t actually do an all-hand’s call, where we have everybody in the same call, because we have like the West Coast, we have Europe, we have India, southeast Asia, and Australia. So, we kind of do this call in the morning, you know, morning time SS. And then, we record that, and we do one in the evening, like late evening, which works for like Australia, Asia and Europe. And this kind of play the recording, and then do another second half, and then, record that, and play that in the next thing. So, we figured this out, and it’s working pretty well.

But we’re already across time zones, where we can’t fit everybody into one call that is not a crazy hour. So, I expect us to kind of keep trucking along that way. And it’s fun! I mean, it’s great to have colleagues from like all over the globe, and we try to bring everybody together twice a year. That’s surprisingly enough. We actually had one of those this year, which sounds magical and unbelievable almost, that we actually had a team off site in 2020. But we did that just before Covid struck, and now, we’re all waiting for that to happen again.

Advice For Open Source Software Startups

Mike: It’s really hard to start any kind of business, but open-sourcing your software adds a little extra challenge I think. Do you have any advice for founders on how to find the right balance to make open source an advantage in their business model?

Rajoshi: Yeah. I think open source is a very important question to ask, if you are sort of just starting off and the decision is between, like, should I open source or not. I think why is open source important, it’s that specific kind of business is for important question to ask. I mean, there are every kind of products that are open-source and closed-source alternatives.

In the infrastructure space, open source has pretty much become table stakes for people, for how software is being adopted, but I think thinking through the business model from the beginning, and not making that an afterthought is going to be very important. That would be my only piece of advice to sort of think about it from day one, at least as much as you possibly can.

Because there are two ways – either you start a business intentionally, saying this is going to be an open-source business. And then, I’m going to start clearing on commercial features. Or you build something open source as a side project, and that kind of takes off, and then, you try to figure out, “Oh, wow, everyone’s using this – how can I make a business out of it?” I guess if that’s the way you’re going about it, then, you will have to figure it out as it happens. But if you’re intentionally doing it, I think thinking through, really thinking through how will you start monetizing, right from day one, is going to be very important. Because, often times, if the differentiation factor between what is open source and what you plan to make a part of the commercial feature, if it’s not very well-thought out, then, that can lead to all kinds of problems, both from the community, as well as just generally as to become a viable business.

Did Hasura Plan The Business Model Early On?

Mike: Did you follow your own advice there?

Rajoshi: Yes, we did, we did. I think we did. Partially we did, definitely, we know that we didn’t want to make our commercial offering. Their support base model wasn’t what we were going for – that’s not the kind of open source company we were building out to be. And we also did not want to have our Cloud version to be just like a hosted offering. Because the problem, the way we see it, if it’s a hosted offering of your open-source software, then, everyone’s bound to compare it to here. But I can host it on so-and-so provider for like this much cheaper.

We did not want to go down that path, we wanted to really offer teachers, which were part of our commercial offering that would really, again, make sense for the stage of the company you were. And, it would economically and ergonomically make sense.

So, it was always about that – what are the things that you will need once you’re in production, you know, you birth the product, you trust the product, and now, you want to go ahead in production. And what are the things you don’t want to worry about when you are in production. And that’s kind of what we look. The jury is still out – I mean, well, we’re going to see how this works out, but so far, the signs are good. I think people are really liking our commercial features and the product, but it’s early days – we will see how things evolve.

Role Models For Rajoshi?

Mike: You’re the first Indian female founder we’ve had on the podcast, and we hope you won’t be the last. I’d like to end with this different question than I normally ask. Who are some of the leaders and role models that influence your decision to co-found Hasura?

Rajoshi: Wow…that influence my decision to co-found Hasura? That is a very difficult question to answer because I used to be in genomics and research – I’m a bioinformatics person by sort of education, in the first few years of my career. And if somebody had asked me then, “Are you going to be the co-founder?” Like, whatever, start a company – I think it would have not crossed my mind. I was deep in the academic world, and it was so far away from anything that I thought about that, I don’t think I would have had an answer.

When I started working at this Incubator is when I saw how startups work. You know, I found about startups, this incubator that I work. I used tohave a lot of folks who worked at successful companies, who would come and speak to the students, though I was a mentor there, I was also a student, because I was teaching them programming and learning about all of these different amazing business things from folks that had successful startups. And that was the first time that thought crossed my mind.

I think my journey – once I did that, that was an 11-month thing, where I thought – I think for me after that, it just seemed like the next step that I have today. And that’s kind of how I got into it. It wasn’t again like an extremely like, “Okay. I am going to start a company.” sort of thing, it’s sort of just like my life experience has led me to this. So, I guess I don’t know how I can sort of talk about role models and who kind of influenced my decision – I think that experience that I had teaching at this Incubator – which is actually based in West Africa in Ghana, and it’s done by a Silicon Valley company called Meltwater. It’s an amazing program, and they bring students or fresh graduates from university, who want to start companies, and train them. And just being part of that ecosystem, I think that was my inspiration, that entire experience was my inspiration to sort of stop something and not get bogged down by, you know, it’s just going to be really impossible to do.

Closing

Mike: Oh, congratulations. I think you’re going to be the role model for the next generation of entrepreneurs going forward. So, best of luck with Hasura and everything else you do. And thank you so much for being on the podcast.

Rajoshi: Thank you so much, Mike. Thank you so much for having me.

Mike: Thanks to the Hasura team for help coordinating the podcast. Audio editing by Ines Cetenji, transcription and episode website by Marina Andjelkovic, cool graphics from Kemal Bhattacharjee. Music from Broke for Free, Chris Zabriskie and Lee Rosevere.

Next time, we have Justin Borgman, CEO of Starburst. If you don’t know Starburst, I highly recommend listening because it’s an amazing story of a perfectly executed startup – Justin was great.

Until next time, stay safe, and thanks for listening.



Episode 51: Cloud Native Agility, Reliability and Stability with Weaveworks CTO Cornelia Davis

Interview with Cornelia Davis, CTO of Weaveworks, a leader in the cloud native infrastructure open source software ecosystem.

Episode 50: DataStax NoSQL solutions built on Apache Cassandra with Kathryn Erickson, Open Source and Ecosystem Strategy

Intro


Mike Schwartz: Hello and welcome to Open Source Underdogs. I’m your host, Mike Schwartz, and this is episode 50 with Kathryn Erickson who helps lead open-source strategy at DataStax. Founded in 2010 and currently employing about 500 people, DataStax was one of the first and most successful companies in the Apache Cassandra big data Ecosystem.


Kathryn has an engineering background. You can listen to some of her great deep dives into the tech on the DataStax website. In her role on the strategy team, she’s helping to lead the company into its next phase of growth and community engagement. I hope you’ll enjoy this episode. And if you do, don’t forget to share a link on social media. You can find all the episodes on opensourceunderdogs.com, or you can retweet our announcement by following us on Twitter. Our handle is @fosspodcast. So, without further ado, let’s carry on with the interview.

DataStax Origin

Mike Schwartz: Kathryn, thank you for joining us today.

Kathryn Erickson: Sure, of course, thank you.

Mike Schwartz: Most of our listeners probably know about Apache Cassandra, one of the most popular databases for big data, but how did DataStax evolved in relation to the Cassandra project.

Kathryn Erickson: DataStax was founded by Jonathan Ellis and Matt Pfeil, both employees of Rackspace. Jonathan, being contributor to Apache Cassandra and Project Share as well, was considering leaving Rackspace, and Matt Pfeil went to talk to him and say, “Hey, there’s some really cool stuff going on here, you should really consider staying.” And by the end of the conversation, they were founding a company together.

And so DataStax was founded to support Apache Cassandra. Over time, we began adding Enterprise features and selling an Enterprise distribution of the database with these features added, and then, of course, more recently, the cloud platform as a service offering as well.

Evolution Of Support Offering

Mike Schwartz: Actually, I didn’t realize that you started out providing support. Because when I first ran into DataStax, I guess I had just known it as a distribution of Cassandra. And now, I see that you’re also providing support for the open-source distribution. Can you talk a little bit about how that’s evolved over time? Has it always been there or has there been a focus on for or against doing that?

Kathryn Erickson: It hasn’t always been there. When DataStax was founded 10 years ago, there wasn’t really a playbook for how to build and run a successful open-source company.
We were founded around the premise of providing support and consulting for Apache Cassandra. Over time, we did, all for the Enterprise Edition, but what you see with most Enterprises is that they have a mix of the Enterprise version and open source. For some customers, that’s dependent on the criticality of the data, and for other customers, it’s dependent on the features or the distribution, being the as-a-service offering or self-installed on-prem.

And so, what we saw in the last year was that there were some obvious things that we weren’t doing, and our customers needed support and consulting around open-source Cassandra. We are beginning to open-source a lot more of the features that would build Cassandra abundance, and so, it made sense to bring those offerings back.

Astra – DataStax Cloud Offering

Mike Schwartz: Okay, and you mentioned that DataStax launched a new hosted service called Astra. Do you see that product as a driver for revenue, or is it just an easier path for customers to test drive the product?

Kathryn Erickson: I think that will evolve over time. I think at launch, it is the easiest way to learn Apache Cassandra. And I think as we launched the hybrid option, I believe that’s later this year, that would become a more significant line of revenue.

Pricing

Mike Schwartz: Most of the revenue today I guess is from the license Enterprise product, so focusing on that, a lot of open-source businesses are moving towards consumption-based pricing. And I’m wondering, what kind of metrics do you use to determine what is consumption?

Kathryn Erickson: You know, a cloud-based offering consumption is based on capacity. And with our licensed product and with Luna, the open-source support offering, our focus this year has been around simplification of the pricing model. And we revisit that each year.

With the Enterprise product, we previously charged for the Enterprise license, and then, an optional additional fee for advanced workloads, like Spark analytics and graph. That’s confusing for the customer, they just want a simple pricing mechanism. So, we collapse that pricing. And then, of course, for larger deals ,we would have ELAs, or special terms to accommodate those customers.


Mike Schwartz: That consumption is based on, like, per CPU, per server, or how do you actually figure out what is the size?

Kathryn Erickson: It’s true capacity-based, the size of the data set being stored. And as we move to Astra hybrid, which will be that offering on-prem, I think we’ll consider that pricing option there as well.

Market Segmentation

Mike Schwartz: Data persistence is like the most horizontal market on the planet. Every company basically needs to store data. When you can sell to everyone, it’s sort of a blessing and a curse. Do you segment the market at all vertically or by use case, or do you just not segment the market?


Kathryn Erickson: It’s hard to segment when you’re serving a pretty broad market. What we try to do is have as easy of an on-ramp for the different verticals as possible. We see data models look similar between IoT use cases, inventory and messaging data models would be similar.
So, we don’t segment the market for go-to-market strategies, but we try to find places of repeatable consulting efforts to speed up the successes for those customers.

Partnerships

Mike Schwartz: When you took on the role of director of strategic Pprtnerships, you probably did a survey of the range of partnerships that exist. Can you talk about like what is the partner landscape look like at DataStax?

Kathryn Erickson: I ran our technology partner program, and there’s two other sides of that, SI partners and the cloud partners. On the technology side, you want to make it easy as possible for customers to consume your product.

So, in a technology partner program, you want to understand the user journey to get to your product, and make sure that those adjacent technologies have the simplest most repeatable easy to build, easy to test integrations as possible over time. If you want to think about specific companies and integrations, every database needs an ODBC and JDBC connector. And customers want those for BI, for reporting, for simple ways to move data in and out of the system, but in the last few years, most customers also want to see Kafka connectors and more high-speed ingest Pub/Sub integrations.  So, we want to accommodate those as well.

Mike Schwartz: Coming on the System Integrator side, you know, at Gluu, we found that those have been essential for us, to be able to focus on innovating the product versus getting involved in specific projects. But there’s such a broad range when you’re serving a global market of the System Integrators. Do you consider them channel partners or integration partners?


Kathryn Erickson: We usually consider them strategic partners when we take those types of partnerships on. And the goal is usually to help us penetrate markets that we don’t currently have field team in, or packaged, or cookie-cutter solutions. If you look at some of the stuff that we’ve done with VMware and with partnerships at Dell, we want to assert that the product stack works as recommended for customers that are used to seeing these reference architectures from these larger integrators and technology companies.

Most Important Partnerships For Driving Revenues

Mike Schwartz:  Which partnerships, do you think are the most important for actually driving growth?

Kathryn Erickson:  Deloitte’s been in a role to our federal business, they know that space better than any startup could hope. VMware for helping to modernize Enterprise platforms. Enterprises that are looking at Cassandra and looking at DataStax are usually going through some type of digital transformation. And the product that they already have in place is VMware. So, everything that we could do to make that migration to know SQL smooth was helpful to those customers. VMware has been a pretty big partner in my journey.

Open Source Strategy

Mike Schwartz: Some of the companies we’ve interviewed are moving to a 100% open-source strategy, specifically Chef and Cloudera. In the past, the value property DataStax, it had improved distribution of Cassandra.But do you see DataStax maybe moving more in the direction of open-sourcing its platforms and some of that technology it’s developed?

Kathryn Erickson: We are open-sourcing a lot more. We try to stick to simple rules for open sourcing, simple rule is, it’s a Harvard Business review article, simple rules for a complex world.
And so, simple rules for open source, if it increases adoption Cassandra, it should be open-sourced. And if it’s Enterprise feature that’s more specific to Enterprise customers, like security features or advanced replication options, then that would be kept proprietary.

And then, where should something be open-sourced? Well, if it makes a change to the core of Cassandra, of course it should go to the Apache project. And if it increases abundance, but it’s not impactful to the core of the project, then it still should be open-sourced, but maybe able to exist in a DataStax repo or different foundation.

Does Open Source Help?

Mike Schwartz: Do you think the wider open-source community A Cassandra helps DataStax too?

Kathryn Erickson: Of course, open source is all about positive sum games. I think it was Thomas Jefferson that said, “If use my light to light your torch, then we both have light.” And that’s how open-source works. The more communities and more companies that you can move from being other to being self, the larger the positive sum game that you’re playing. So, it’s open source, and open-source abundance is absolutely essential to the success of any open-source company.

Thoughts About Open Source Foundations?



Mike Schwartz: Any thoughts about Cassandra being hosted at the Apache Foundation versus perhaps Linux Foundation or the CMSF?

Kathryn Erickson:  I don’t have any opinions on the other foundations, but I think that Apache Cassandra will always be at home with the ASF. They have their simple rules for what it means to protect the open-source nature of a project, and they don’t waiver. And for a vendor backing an open-source project, that can be like a Northern Light, you can lose your way, and you can always look back up and reorient towards the community.

But you know, there’s nice things when you see CNCF, you know, the marketing wing, and the power of the CloudNative messaging that’s there. But there’s no reason that projects can’t have pieces that exist in different foundations either.

We see ourselves and others that build communities operators or management APIs or drivers is an example, they should live in a project, but management tooling that exists that the maintainers of the project wouldn’t want entry. So, something like that maybe should live in a CNCF type of foundation that’s focused on CloudNative. But no Apache Cassandra will remain Apache, and that’s a tome.

Industry Changes In The Last 10 Years

Mike Schwartz: So, DataStax is one of more mature, well-established companies in the open-source ecosystem today. What are some of the challenges you think that you are looking at now that were different than when you got started?

Kathryn Erickson: When I started a DataStax, it didn’t always feel like we had a lot of competition. And I think as other good distributed databases emerged, we adjusted to having competition. I think the obvious answer that most people would expect is pressure from the public Cloud vendors. But if you stay oriented on the positive sum nature of open source, then that becomes easy to embrace as well.

So, there’s changes in understanding the virtuous cycles of open-source, understanding how to build software as-a-service more quickly as Kubernetes has matured that’s become a lot easier. So, I think the ecosystem around us has matured a lot, the playbooks around how to build a company around open source have matured. And there are more senior projects that kind of exist in our ecosystem that we can work with and learn from as well.

Is Open Source Table Stakes For Databases?

Mike Schwartz: You know, most of the databases that have been released in the last, let’s say five to eight years or so, have been open source. Is being open source basically like table stakes now? So, is it a non-differentiator in the database market?

Kathryn Erickson: I think that if you’re moving from a proprietary relational system, and moving towards NoSQL, then you’re obviously moving into an open-source world. And if you can choose something that has a security life, security blanket that you know will outlive any vendor behind it, then you should consider those options first.

I think that it would be hard to start proprietary databases without the support of the community and of these foundations. I think Snowflake has done an exceptional job and is kind of the exception to the open-source game. But, you know, they were disruptive in a much different way. NoSQL in general is an open-source family.

Data Platform Trends

Mike Schwartz: Just a general database question about the database market. So, we’ve interviewed a probably more database companies on this podcast than any other type of company, but have you ever seen a real shift in the way that customers think about databases.

In the old days, I think you just used to get one database and hope it did everything, but have you seen a sort of on the technology side a shift in the way that companies are thinking about data and databases now, with more SaaS hosted offerings and more database offerings, like in general.

Kathryn Erickson: Yes. I think I think this is definitely the age of data platforms. With Cassandra, we see customers considering NoSQL when they’re using the relational system. And it can’t support the throughput that they need anymore, or they need to replicate more geographies, or exist in a multi-cloud or hybrid environment.

And so, that’s when you consider Cassandra. If you look at when you might consider Mongo, you want to get quick start with a developer friendly environment that’s great for mobile. What you start to see is that there’s a certain fit for purpose that the different NoSQL databases have. We’ve started to see an emergence of multi-model systems that move forward. And consolidating those capabilities, we have that with our Enterprise products and their integrations for graph analytics and search, we want to help customers build high-growth applications, high-speed transactional applications are the sweet spot of any Cassandra deployment.

Advice For Startup

Mike Schwartz: This is a question, a sort of a generic question for entrepreneurs who want to launch a business around an open-source product. I’m wondering if you have any advice, for let’s say, startups? And it could be general and it could be about partnerships.

Kathryn Erickson: You don’t have to invent a path to success, you can listen to the A16 podcast, you can look at other companies that are out there. You can go through so many success stories on podcasts like this, you can listen to Cockroach, and there are Open Source Underdogs podcast talk about how they’re thinking about licensing other companies. You know, having similar conversations, really understand what has made other companies successful, and don’t try to invent that yourself.

How To Improve Tech Diversity?


Mike Schwartz: Last question. As you’ve might noticed, there aren’t enough women in the tech business, including there haven’t been enough women on my podcast, so thank you for joining. What can we do to reverse that trend?

Kathryn Erickson: I think there’s a lot that we can do. as You are on the side of making mistakes, just try things, and if it’s not the right thing or if it doesn’t work, try something else. We’re going to do a program at DataStax, you know, Jumpstart, if you’re a woman or a person of color, and you want to learn Cassandra, and you don’t know where to start, just hit the button, sign up. Somebody from the team will meet with you for 30 minutes and help you get started. That might work, that might fall flat, but we’re going to just start trying stuff. And I think everyone should just start trying the ideas that they have, and we should all tell each other what’s working.

How’D You Get Started?

Mike Schwartz: How did you get started in the tech industry?

Kathryn Erickson: Well, my dad taught Computer Science, Community College, and I was going to be a DNA researcher. And I just wasn’t very good at it, and I thought, “You know what dad’s over Computer Science, we’ve been playing with computers all of our lives.” That sounds more like playing then working, it’s been that way ever since. It feels more like playing than working every day,

Mike Schwartz: That’s great. Thank you so much for joining us today, Kathryn, and sharing your insights. And best of luck at DataStax.

Kathryn Erickson: Sure. Thank you.

Closing

Mike Schwartz: Thanks to the DataStax PR team for helping us to schedule some time with Kathryn.

Editing by Ines Cetenji. Transcription by Marina Andjelkovic. Cool graphics by Kamal Bhattacharjee. Music from Broke For Free, Chris Zabriskie and Lee Rosevere.

Next episode we’re excited to have Cornelia Davis, author of Cloud Native Patterns, a Manning book that needs to be on every software architect’s bookshelf. She’s also the CTO of Weaveworks. She was fantastic, so don’t miss it. Until next time, thanks for listening, and stay safe.

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.