The Role Of Startups In Moving Platform Engineering Forward With Colton Dempsey Of Next 47

Intro: 00:05

You're listening to the Platform Engineering Podcast. Your expert guide to the fascinating world of platform engineering. Each episode brings you in depth interviews with industry experts and professionals who break down the intricacies of platform architecture, cloud operations, and DevOps practices.

From tool reviews, to valuable lessons from real-world projects, to insights about the best approaches and strategies, you can count on this show to provide you with expert knowledge that will truly elevate your own journey in the world of platform engineering.

Cory: 00:45

Hey everyone, thanks for tuning in to this episode of the Platform Engineering Podcast. I'm Cory O'Daniel. With me is Colton Dempsey, a partner at Next47.

Colton, thanks for being on the show today.

Colton: 00:56

Thanks so much for having me, Corey. Excited to be here.

Cory: 00:58

Yeah, I would love to learn a bit about your background in venture capital and particularly in the DevOps and platform engineering space. I really enjoyed the posts you wrote on, is DevOps a rebrand or meaningful step forward? Is platform engineering a rebrand of DevOps or a meaningful step forward?

That's something that I have feared and hoped was not the case for most of my career, but would love to hear about your journey.

Colton: 01:23

Yeah, absolutely. And so I joined Next47 in 2018, and we're a B2B focused venture capital firm. So we invest in tools used by engineers and DevOps, professionals, data teams, sales teams, marketing teams, so roles just across the enterprise.

And I just have a particular love for the infrastructure side of things. So that's where I spend a majority of my time. And I came across platform engineering more, more so from my interactions with startups in the space.

So I think I came across the startups, probably before I heard about the term platform engineering. But as I did start to hear about it, I could see how some of these pieces fit together. And so I wrote that blog post to really, that was the initial question, is this a rebrand?

That's what a lot of people were calling it. But I come out thinking this is platform engineering is a valuable pattern and approach. So it's been great diving into the space.

Cory: 02:31

Yeah, we actually met at re:Invent. And when we were there, it was funny, the number of DevOps and platform engineers that I met, they were very much concerned about this as well, like just being at the rebrand. I think that most of the industry understands that like the work's important, like the mission's important.

But we've kind of been through this rebrand before, like a lot of people felt like they got rebranded from DevOps engineers, and it happened again with SRE. And I think a lot of people are afraid of afraid of this happening again. You know, like, how do you think that that startups in this space can help can help make sure that this isn't just a rebrand and actually push this mission forward?

Colton 3:15

Sure. Yeah, I think some of the concern is around title. And I'm not sure that, like, platform engineering has to be a title.

I think there are 20,000, actually 22,000. Now platform engineers, I wrote the blog post about six months ago. So growing at a decent clip, but you know, still fairly small.

But I don't think teams necessarily need to call themselves something different. You know, I view platform engineering as as an approach that helps both developers and DevOps teams or platform engineers, both operate more efficiently. So I don't think there's anything wrong in in, in, you know, building products to that actually help with that.

And so I'm not too concerned about it. But about like the rebrand piece, I think this will be valuable long term, but it's still very early and startups are really figuring out what provides the most value and, and how to sell this appropriately, because it can definitely be tricky when you're selling to two different parties within within an enterprise.

Cory: 04:24

Yeah, I'm familiar with that one. And it's interesting, because like, when you look at some of the most successful companies in the world, like they're doing this, right? Like, and I feel like when you look at FANG, like FANG has platform engineers, Google, right?

I mean, the clouds themselves have done a lot of platform engineering so that they could extend the services to us as as developers. So it's like, you see that this is something that big companies have to do. And I feel like there's a lot of really large organizations out there that may, you know, you may see them as antiquated, right?

Grocery chains, some of the older brick and mortar now e commerce sites, and banks, right? Like the things that we use every day as people, not just software engineers, that they, they need this, and they can actually have some of the most amount of struggle of trying to get this talent, right. And so I really do hope that it is a it is a mission that people continue to push and that we're successful in moving there.

The companies that you're investing in, in the platform and engineering and DevOps sectors, like what, what is the most exciting about those sectors in those companies that keeps you interested?

Colton: 05:37

Hmm, yeah. Within, within infrastructure, it's incredibly complex, rich, rich ecosystem of startups. That's, that's perpetually evolving, I think, more so, you know, the interdependency on other tech is, you know, especially pronounced in this space.

And the the waves of adoption that we see, whether it's, you know, moving to the cloud or adopting Kubernetes, you know, new things like serverless, create new lots of new opportunities every day for new startups to emerge and claim a competitive advantage of versus the the incumbents who, you know, weren't born in the cloud or, or designed for for Kubernetes. So I think it's just the ever changing nature of the space that gets me most excited.

Within platform engineering, we haven't made an investment yet. It's not to say that we won't, we definitely are looking to do that. But yeah, it's still early days of the category.

And I think there's some convergence that will happen. So excited to see how that develops. You know, we have companies in our portfolio, like logs, IO that work with the ELK stack, you know, related to observability and monitoring.

So I think that that is a can be a piece of platform engineering. And that's some of the challenge of building these platforms is how broad should they be? And, and, and what should they encompass?

And I think right now observability kind of operates a bit in its own lane. It's like a pretty well defined category. But, but long term, I think that that will absolutely be is already being encompassed in some platform engineering tools.

So, so still, still actively looking for, for interesting companies in platform engineering.

Cory: 07:39

And how do you how do you like identify a promising startup in the platform engineering or the DevOps space? What qualities are you looking for?

Colton: 07:48

Yeah. I think well, to find them, there's lots of ways, you know, a lot of them will be open source startups. So if you go to, you can find them at events like KubeCon.

There, you know, a book I'm reading right now called Platform Engineering on, on Kubernetes. So, you know, I think platform engineering is aiming to have developers take on a little bit more of the infrastructure work that DevOps traditionally has done a bit more manually, this time in a more productized approach. But you have to make it, you know, comfortable for them, for developers to take on that additional responsibility.

And so it kind of seems like there needs to be an exchange where, where developers are maybe taking on more infrastructure and DevOps, you know, people are platform engineering teams are learning more codes. So kind of convert, there's a bit of a trade there going on. So that that balance is really important.

And it's hard to give, like, specific attributes we look for, because I think there's so many exceptions, there's always an exception in the startup world. But at a high level, I think we're looking for, you know, great teams, building a product that is either a huge leap above the performance of the incumbents and like in a defensible way. That way, you're tackling an existing bucket of spend, and a clearly defined budget.

Or companies that have a totally unique vision of the world, maybe a more contrarian vision of the world, that is just, you know, fundamentally disruptive, and may even not be as defensible as that previous example I mentioned. But the idea is you'll get such a head start, that you'll be leading in that, leading that way.

Cory: 09:45

Yeah, you mentioned the open source component. That's what I'm really curious about, you know, especially from the VC point of view, with all the kind of shake up in the market over the past, you know, year, year and a half, does a good, successful open source project, like still have the same value as an investor, like when you're looking at an organization, or is that, has it receded a bit?

Colton: 10:09

I think there, I think open source, if you look across the platform engineering space, probably half or more of the startups, you know, at least like in the landscape I made, have an open source approach. So I think it's definitely important and great, but it's not absolutely necessary. I think it provides a great pipeline for startups, you know, great distribution.

But you can also find projects or companies that have, you know, so much adoption and still are struggling to monetize. So when looking at open source, there are plenty of benefits, but really need to make sure that you are being intentional about what you're putting in the open source and what you're keeping proprietary. And, you know, I think some founders that come from the open source world, you know, struggle with that a bit, but it's like you are a commercial entity.

So ultimately, you know, people won't fault you for it if you make it fair as possible. So I think there's a balance to strike of putting out an open source project that provides enough value that people get really excited about it. And but, you know, not so much that there's no ability to monetize.

So having those, you know, paywalling strategies are important.

Cory: 11:35

Yeah, I feel like there's so many, especially with like the budget cycles you get on operations and DevOps teams, I feel like in large organizations I've worked in, like, hopefully get a quarterly one, don't get stuck with the annual budget you have to deal with. But like that open source is really the way for you to sneak something in under the radar, right, where you don't have a budget for it yet, and try it out and kind of prove the value to the business. And so I've always seen that as a really important component of, you know, getting really good dev tooling or operations tooling, like into a business.

And so that's just something I've been thinking about with, with, you know, how much more pressure there is for startups to, you know, get bigger revenues before they get to Series A.

Colton: 12:18

Right. Yeah, absolutely. You have to be pretty intentional about it.

And, you know, there's no rush necessarily to be open source from the start. You could be source available, or, you know, you can take time to figure out what components of my product, you know, are helpful to be open source. Maybe it's not, maybe it's more of a format that you've developed, or, you know, something, some type of syntax that people can build things, and then so it's helpful to have that community.

Other times, you know, maybe you want the open source, primarily for, you know, to put, you know, get some distribution, but definitely like to help enterprises be more comfortable being able to read the source code. So, yeah, there's a variety of different approaches you can take.

Cory: 13:07

Awesome. And what categories, what startup categories do you think really embody that platform engineering mindset with the evolution of DevOps and platform engineering? Like, where do you see these opportunities for innovation investment over the next couple of years?

Colton: 13:21

Yeah, so I think, well, the there are a few categories that are top of mind for me in platform engineering. One of them being internal developer portals, IDPs, or internal developer platforms. I'm not totally sure exactly the difference there.

But, you know, Spotify has their backstage product, which is a project which is known pretty well and serve kind of as either a list of services and who's responsible, or can serve as a, you know, the jumping off point and the UI of the platform for people to spin up new resources and projects in a well defined way. I also think, you know, there's there's categories like environments that are helping, you know, helping developers spin up more isolated, ephemeral environments, rather than having a shared resource that can cause conflicts in the testing process. There's categories like platform orchestration that are, you know, I see a variety of approaches there, but generally trying to help provide abstractions for developers to work with things like Kubernetes or work in the with cloud infrastructure more easily, either by defining how their application should work, like having some of that configuration upfront, and passing it over to the platform team, or then there are tools that, you know, I kind of view as a mass driver in this category that are that are more visual, and actually, you know, it's not just like a YAML format, but it's actually like a real product you can interact with. Infrastructure as code, I think, fits in this category pretty well.

And, you know, there are hosting tools. If you think about companies like Vercel that are essentially enabling smaller teams or developers to provide their code, and, you know, Vercel really handles the rest with things like hosting. So there are tools like that that tend to focus more maybe on the SMB side.

And, you know, incident management, I think, as well is, you know, emerging kind of, emerging category, although I think it's been around forever, but the workflow, like more, I see more and more workflow tools getting built up. So those were like the five categories that I initially identified, but there were lots of debates that we had about other spaces, like build tools, like should that be included, or CICD tools. For build tools, we had seen those more, like more companies have developers really owning that in part already.

So maybe not embodying as much of like taking something that traditionally was DevOps and making it a developer responsibility. And then the CICD tools, not sure exactly if developers are still getting super involved in that yet, but you definitely see some interesting companies coming out with higher-level abstractions that can help there. But I'd be curious, your opinion, like what belongs in a platform?

Do build tools belong in a platform? Does observability belong in internal developer platform?

Cory: 16:42

Yeah, I mean, I think that's an interesting question, because I think that you can put a lot of stuff in a platform. And, you know, our product is obviously in the space, and I've used a fair number of our competitors' products. I'm friends with a lot of those people.

And it's like our products are very different, right? And the reality is, it's like organizations are very different. Like nobody's product in the space is going to be able to sell to everybody.

But it's funny, like even within an organization, like our teams are very different, right? You mentioned Vercel earlier, right? We use Vercel.

We have a team, like we run MassDriver on MassDriver, but we also use Vercel. Vercel is the only thing that we use outside of MassDriver because it is fantastic for our front-end team, right? And I think that one of the things that's a little, I guess, worrisome is I see some companies talking about like, oh, you need an IDP, like 80 to 90% of your team should be using it.

And it's like, that's not a real expectation. Like we can't expect the AI and ML teams to use the same platform that our back-end team is using and the same platform that our front-end team is using. So I think that, you know, as far as like the tooling and functionality that will be in these platforms is really going to depend on the team that's using it.

And I think that we're going to see that, you know, teams are going to start to coalesce around like specific platforms based on their function. I think what's really interesting, though, as far as like the bigger players in the space is who can expand here. And I think that you're seeing a lot of organizations that were a DevOps tool starting to use platform language.

Everybody's talking about self-service and DevEx now. Everybody's trying to get a piece of this, you know, pie that we're baking kind of in this platform engineering market. I'm really curious what kind of behemoths in the space are going to start to do some of the work and some of the functionality that you're seeing a lot of the startups implementing.

So I think that would be pretty interesting there. And I think that's, you know, as a startup, I think it's a little scary to think of maybe a hashy port moving into the platform engineering space. But again, like I don't think that there's a tool that every single person at every single organization is going to want to use.

I think that when we start to see some of these bigger, you know, I see environments, you know, deployment management, incident management start to have some of this functionality. I think it's going to really validate the space. I think this is something that, like, again, we see FANG doing it.

And people that have, like, suffered and been in this space or worked in this space, like, understand the value of it. And I think it's going to be really interesting to see some of these bigger companies start to use this terminology, our language, and start to implement some of these features, because that's just going to make the pie much bigger for everybody else in the space.

Colton: 19:34

Certainly. I feel bad for all the people who are upset by the platform engineering branding, because they'll probably be hearing a lot more of it over the next few years.

Cory: 19:42

I've been an operations and DevOps engineer for going on 20 years now. And then I was in data centers before that.

I feel like there's a lot of tooling that's been jammed down our throats for 20 years. And it's like, we have a hard job and we're always outnumbered, right? It's like, oh, there's three, four, five ops people and 200 engineers.

It's like, it's really hard to get a good DevOps culture when you're constantly struggling for budget and, like, you're not seen as a direct value add to the product of a lot of organizations.

Colton: 20:20

I have a question on that. Have you noticed that being on DevOps teams, how does your budget compare to the budget of the engineering team?

Cory: 20:29

Well, yeah, it's really funny how it works. It depends on if there's good, like, cost controls in the org, right? So, like, a lot of orgs, I think, especially early on, all of the cloud costs just end up rolling up to the DevOps team, right?

So, it looks like a big budget, but the reality is you're running your developers' infrastructure. I think as you get more mature, it's boring to talk about, but, like, having good cost controls and attribution of costs, like, for your resources really gets people an idea of, like, who's spending the most. Like, oh, I can see that there's, you know, $100,000 to spend a month for the backend team and there's maybe $500,000 a month of storage and processing and ETL for the data team.

So, I think that once you get to that state where you have good cost controls and you can see where people's costs are in the cloud, that's where you start to see the DevOps team has a very small budget, right? It's like we have, you know, a handful of engineers compared to what is on the product team. Again, that's customer-facing.

That makes sense. But I think that you're outnumbered staff-wise and outnumbered on the budget, like, time and time again. And I think that's something that I think is going to be hard for a lot of DevOps teams that want to move to platform engineering, people that aren't having it shoved down their throat is they have to somehow show value, whether that's through, you know, another buzzword, the thinnest viable product, or, you know, MVP, or through just doing really good DevOps culture in your org.

Like, we got to show value so the business sees that value that we're giving so that we can start to open up that budget. I don't think we do a good job of that, right? We're so far from the product.

We're so far from product management. I haven't seen a lot of teams, like, lean into, like, really doing that DevOps work, like, seeing what their engineering customers need, surveying people, right? Like, figuring out, like, how you can actually be a force multiplier for your engineering team versus, like, just doing that.

And I don't think that they necessarily are doing that on purpose. I think a lot of them are just dealing with that, right? Like, you get brought in as the first ops person, like, three or four years into a project, and, like, day one, you've got a lot of work to do before you can start even, you know, adding that value.

So the budgets, I feel like, tend to be a lot less when you're not counting the entire cloud into it. And I think something people are still struggling with, there was a recent Gartner report on how a lot of these DevOps teams are trying to now figure out how to consolidate tooling, because now they've got 27 different tools, they're paying 50,000, you know, a year for this one, 100,000 a year for this one. So it's, like, their budget is getting, you know, spread out to all these tools that solve a single problem.

So now they're looking for, okay, who can solve three of my problems so I can consolidate some of my budget on one vendor, right? And get some of that money back so I can hire another teammate, right? And I think that's why you're starting to see a lot of these bigger organizations start to have these diverse feature sets.

It's like, if they can, you know, if somebody like Logs can start to do tracing as well, it's like, “Okay, well, maybe I'll use them for my logs and tracing instead of buying, you know, a LightStep or Running Hotel or Yager myself.”

Colton: 23:33

Yeah, I think it's certainly been, over the past two years, a lot of interest in consolidation and cost optimization. So definitely seeing a lot of tools emerge in that space. And yeah, I think it's interesting that you mentioned that the DevOps budget, you know, may seem large, but when you really get down to it and attribute everything, it's not as large as you may think.

And I still think this is probably the right approach, but a lot of platform engineering tools will try to market to maybe developers with their open source and then sell to the DevOps team and actually monetize with governance features. But it's very difficult to get, you know, developers super excited about, like, you know, adding a lot more governance features to some product that they already like. And so you're kind of pitching two different value props.

And how do you kind of combine that? How do you pitch both velocity to developers and, you know, control to DevOps teams? And I know that's not the only thing DevOps teams are concerned with, but, you know, that is like a typical tried and true method of selling that type of ROI.

Cory: 24:57

Yeah. And it's funny, like, when you just look at, like, you know, common, like, ratio that we threw out there, like, I think, you know, depending on what blog post you read, you'll see people say, like, one to ten is good, like, DevOps or operations to engineers. And you'll see some people say, like, one to seven.

You see a lot of times, like, companies realistically have, like, one to twenty, right? But, like, that right there, when you just look at, like, people power, like, you can see that there is seven times the budget for engineers, right? Or ten or twenty times the budget just for people, like, let alone their tooling.

So, I think that, you know, a lot of times we struggle for that budget, and we have to be, like, sensible about, like, how we're spending it, right? If I buy, you know, two different tools for two very specific use cases, that might be the salary of a person I could bring in and might be able to run, you know, Jaeger so we don't have to go buy a tool in the space. And they can also help with some other stuff.

It's, I think it's, I think, you know, one of the things that's really key to being a great DevOps engineer is being frugal, right? And that sucks as a vendor in the space, right? But, like, you don't have a big budget.

You got to figure out, like, how to get the most bang for your buck out of the tools and people that you're hiring.

Colton: 26:11

Yeah. I think that's why things like a land and expand strategy can be really important for platform engineering tools, to get that initial foothold and prove value over time.

Cory: 26:22

Has the rise of cloud-native technologies and Kubernetes influenced your investment strategy? Like, there's a lot of tooling in the space now.

Like, how is that changing how you think about investments?

Colton: 26:38

Well, yeah, I think Kubernetes has surpassed many people's expectations for, you know, it's staying power. It's been about a decade now. So I think it's becoming more and more viable to build a company that is really based on Kubernetes and highly focused on it, or even being a pure play, you know, Kubernetes company.

If I look into the past at companies like, there have been companies like Rancher that have been successful in kind of abstracting on top of Kubernetes. There's been companies like Red Hat that were around well before Kubernetes, but, you know, definitely picked up the mantle and helped, you know, bring that project to life. But there haven't been so many pure play Kubernetes companies, you know, have a super successful exit yet.

I think, in fact, it's been maybe more of the ancillary services around Kubernetes that maybe have had some of the initial success of things like, you know, securing Kubernetes rather than like the actual dev tools on top of Kubernetes. So I think there's more and more opportunity for startups to purely focus on Kubernetes, but I think it's still kind of risky to have that be your only strategy in the long term. You know, if you want to serve enterprise, they're not just going to be necessarily running on Kubernetes.

It's important to be able to help people who just work on AWS natively and, you know, use VMs or whatever. So I still like to see companies that have a bit more flexibility to go beyond just Kubernetes. But certainly, I think, you know, it will be around for a very long time.

You know, VMs are still around. Mainframes are still around. So, yeah, I think over time, more and more, we'll start to see more pure play Kubernetes companies.

Cory: 28:51

Yeah. Well, speaking of things that are new to doing the space, like startups that are in this space, the DevOps and platform engineering space, like what are some of the challenges that they're, like, what are some of the common challenges that they're going to be facing, especially like this new era of where it's hard to get venture capital and how can they overcome some of these challenges?

Colton: 29:13

Yeah. I mean, just like we were talking about, it is a tricky space in terms of the go to market with selling to DevOps and engineers in a two handed sales process. So I think it's important to be as crisp as you can and intentional upfront about how you set up your business model and align that really well with your product.

If you're selling to enterprises, they've made huge investments in their software development life cycle and may be reticent to pull out, you know, rip out everything. So a rip and replace strategy for enterprise, if you're an early stage startup, is a very tall order. And I think it's important if you're selling to enterprise to make a modular platform so you can, like, at least give them the option to insert you in one particular part of their tool chain and then expand over time.

But you still want to have a pretty... Enterprises also, at the same time, require a lot of depth of product. So you need to give them that option to have that full end to end automation as well.

That's easier said than done. But I think in general, the land and expand strategy is the best approach to take for enterprise. If you're selling to SMB, you know, you might want to have, you know, a clearer, simple pricing model.

Their budget upfront, that's, you know, very transparent for them to see because they have super strapped budgets. And so, like, that will help a bit with the adoption. And I think if I think about, like, the product for platform engineering, and I think it's not enough to just provide, you know, configuration management for companies, for your customers.

You know, if you provide, you know, some type of opinionation on top of infrastructure, you know, it's not going to be a huge leap up in productivity, probably for developers. You're kind of making it a little bit easier for them to do the developers, making it easier for the developers to do the job that DevOps was doing, you know, slightly simpler. But I think what really unlocks value is if you can get developers to build their own domain knowledge into the platform.

And, you know, that's one of the things I think is great about MassDriver is how you guys have, you know, you provide the ability to be opinionated. The DevOps team or platform team can, you know, set, have the developers input very specific, like, only the variables that they need to know about and, like, help them with the configuration. But they also can build, you know, use these building blocks to build abstractions that, you know, are closer to the business logic that they need.

And that, I think, is what really actually will hook developers and make this more of a productivity play than just a governance play.

Cory: 32:30

Yeah, it's interesting, like, when, you know, when you think about, like, the work that you do in the cloud, right, we've always had this with ops and dev and then what became DevOps, like, there's these two teams that have to work together to get this stuff up and out, right? And it's really funny when you look at, like, thinking about, like, codifying, you know, business needs into the platform. It's, like, when you look at almost any service in the cloud, there's a set of configurations there that are very much for the developer, the developer cares about.

And then there's a set of configurations that are very much what the operator cares about, right? Like, looking at, like, running a database, like, oh, like, I want it to be highly available, like, multi-zonal, like, I don't think the developer cares so much as they're not getting woken up at 2 a.m. Like, what they care about is, like, the version of Postgres or MySQL, right? And I feel like the unfortunate thing with, like, how we experience the cloud when you give tools to developers, they're, like, if you just give them Terraform or OpenTofu, like, hand it to them, they have to kind of learn all these, all these attributes, like, all this configuration, right?

There's so much for them to think about, and in reality, it's, like, they care about very few of the attributes of any given service in the cloud, they just want the thing to work, and they want it to be the version that they need for their application to work, right? And at the same time, Ops is, like, I want it to be secure, compliant, and cost-efficient. But, like, we have, you know, this one tool for both of us to kind of, you know, try to agree on.

I feel like that's very, very hard when you're just kind of handing developers the raw tools, like, Terraform, OpenTofu, Helm directly. Like, there's so much you need to hide from them, because nothing you need to hide, I think, if they want to learn it, that's great. We need more people to understand cloud, but, like, they only have 40 hours in their week.

Like, we can't, like, it's, like, they might want to learn it, but it's, like, okay, well, learn it on your free time, like, get your work done, and, like, get to your free time, right? Like, you shouldn't be spending 10 hours of your week trying to understand, like, my side of the world's language to do your job. That's just kind of been my philosophy.

Colton: 34:34

Yeah, I've definitely heard some objections from, you know, DevOps professionals that say, I don't need these platform engineering tools. We have infrastructure as code that spins up infrastructure, and they can just, you know, use these, like, basically take an almost scripting approach to this. And I think that works to an extent, but when you are hiring a lot of people, it's just it's more onboarding time, if they don't know Terraform, you know, it can be more brittle.

So, I think that, you know, that can work as a temporary solution, but there are more efficient ways to do it with some of the tools we're seeing in platform engineering.

Cory: 35:16

Yeah, yeah. So, you mentioned, you know, pricing a minute ago, and I would love to dig into that a bit more. You know, when we went through Y Combinator, one of the first things they told us is your pricing.

Like, not to us directly, to everybody, it was like, your pricing's wrong, and that's fine. Like, your pricing's going to change, like, eight times, and I feel like I've gone through so much, like, pricing trauma to get to where we are today, but, like, it is very common, and if you're a startup today, your pricing's wrong, it's going to change. If you haven't been told that, it's definitely wrong, but what are some of the monetization approaches you've seen be successful in the DevOps and the platform engineering space?

Colton: 35:55

Yeah, I don't think there's one size fits all, but, and I think there's plenty of room for experimentation on pricing, especially in the early stages of a startup. When you're just getting started, you don't even necessarily have pricing on your webpage, you know, you have development partners, and you're negotiating with them, and giving them a nice price to start, and start working up from there, seeing what you can get. And, but I think it's important to think about all the tools that you have at hand, so you can price simply based on seats, but that may not always correlate to the, you know, the value that you're getting, that the customer is getting.

Sometimes, say, or say you want, you know, pricing by seats may also limit the spread of your tool within an enterprise, so, you know, to counter that, you can sometimes have, like, a platform fee, like some upfront fee for using the platform, and make the per-seat pricing a smaller, you know, incremental charge on top. If you have, if your customer's usage varies a lot, and that, you know, and that usage is directly tied to your own costs as a startup, then a consumption-based business model is probably better, and it, you know, you could do that on, like, compute, you can do that on events, there are, like, lots of different ways you can do that, and there are tools out there that will also help you with, like, consumption billing, because there's a lot of custom logic that you have to build in into that. It's also, I guess, depends on whether you are an open-source project or not, and so, when you have an open-source strategy, it also is, again, you have to really decide what you put in to the product up front, so there's less room, probably, there's less room for experimentation there, but when I think about, you know, maybe an example could be Cypress.io, like, they have an open-source project where you can run tests, but if you want to parallelize your tests, you pay, and I think that that's, like, a fair, I think that is seen by developers as fair. The open-source product, like, works end-to-end, and, but if you really want that added speed, you know, if you want, like, that can be an upsell, but, you know, it's not just speed, you can sell, a lot of upsell, you know, will be, you see basic things, like enterprise support, and there's various levels of support you can get all the way, you can, you know, send them to your community Slack channel, or you can have a dedicated Slack channel where you talk with them, or you can actually have a dedicated customer success rep who will hop on the phone anytime they want, you know, people will put SSO, SSO is a super common upsell, but I think you have to be careful with that one. Some people really don't appreciate putting SSO as, like, as an upsell, they think, you know, you should have, so what do you think about this, Cory?

Cory: 39:05

Yeah, so, actually, I think Cypress actually has done a very thoughtful job of when they, when they convert people to paying. This drives me nuts as, like, an operations engineer, I feel like a lot of, a lot of things people will charge you for, it's, like, I feel like they're really, kind of, sticking it to you, SSO included, right, it's, like, good security shouldn't be something you have to pay for, right, like, I mean, and you could say, maybe, if you're selling, like, a Calendly, or something like that, sure, if you want SSO to Calendly, you have to pay for it, but, like, when we're making security, and we're making tools for operations bulk, like, that, that shouldn't be an option, like, it should just, kind of, come with it, right, and, you know, we had, we had this very early on, like, we didn't, we didn't want to charge per seat, because I've seen teams hit a seat max, and, like, okay, we'll just share passwords, and it's, like, well, like, that undermines security, right, so I think there's a lot of interesting things that, like, people will reach for, because they're, like, oh, it's a measure of, like, how, how much somebody's using my product, but I think, at the same time, I think, as vendors, we have to think about, like, what are our values, and, like, and morals, and, like, what we stand for, and, like, does that pricing plan align with it, right, so I've seen people that say, like, they're going to make you more agile, and they're going to make you more DevOps, right, and then they charge you based on deployments, and it's, like, well, you just incentivized me to not make as many pull requests, right, so, like, like, like, you're going to impact my culture with this, right, so pricing is so hard, like, and we definitely still haven't gotten it right, I'm sure we'll change it eight more times on our path to Series A, but, you know, I think that a lot of times, like, people just, kind of, reach for that, just, yeah, you want SSO, you have to come to enterprise, and it's, like, you know, security is becoming much more important early on, like, we shouldn't, that shouldn't be the thing that differentiates your enterprise product, but you should have some, you should have some value in it, not, not baseline security.

Colton: 41:04

Yeah, I think features would be the number one, you know, most, you know, appreciated, I guess, maybe in a way to say it, upsell from, from developers and DevOps teams, like security, governance, maybe being the next piece, and, like, the final piece that are probably least appreciated are, like, those arbitrary limits that, like, aren't necessarily tied to costs for the vendor, and, you know, SSO maybe is, is one example, although it falls in security, but it's, like, you've built it, why don't you just let everyone use it, it's great, right, for people to have security, and you want your, you don't want your customers getting breached anyways, but, you know, there are other arbitrary, sometimes tools will limit, like, make it impossible for the product to be, like, persistent over a long period of time, like, the URLs will change or something like that, and, you know, those are strategies too, but, like, they tend to be a little less appreciated by, by the customers, but you definitely do see that as well.

Cory: 42:04

Yeah, so I have a question I'd love to ask you, and it's, it's interesting, one for me to ask, being that I'm involved in this one, but, you know, just speaking of pricing and open source, got me thinking about Apache Corp's recent change to the license of, you know, all their flagship OSS tools, so if people aren't familiar, they changed to the Boostle license, which is source available, it has limitations on who can use it, if they're direct competitors with Apache Corp.

Has this impacted VC's views on OSS investments at all, and if so, how?

Colton: 42:43

I think it's happened in the past, it's, you know, it's happening, it's happening now, and it will happen again, and it's not, it's not pretty, you know, I think from the Apache Corp perspective, you would expect there to be backlash, but I think they also learned, you know, the importance of communicating this really clearly. I think it's a challenge for them to do so, you know, in their subsequent blog posts that they came out with more clarifications, maybe some of that should have been put up front, but at the same time, I understand it's hard for them to, like, they probably don't have an incentive to directly identify all of their their competitors, so they had the nice call-in-and-ask-us approach, which is, you know, yeah, difficult to see how people will actually, if people will actually do that. I think it's risky to, it just shows that it is risky to depend on open-source software from a commercial vendor if you are operating, like, you know, in their orbit, and could potentially be competitive. You know, I think it shows that Apache Corp is nervous about some of these startups operating in its space, and if I look at, like, a past example, like MongoDB changed their open-source license back in 2018, and I think that was more about cloud providers, you know, but this is a case where it's, I think it's more focused potentially on the startups.

So, you know, that's one interesting difference, but, you know, so there's, yeah, there's definitely risk, there's risk to startups operating on those open-source tools, and, you know, it's going to be a painful process if you have to make a license change. Sometimes it's, you know, maybe the best economic decision for the business, but, you know, I'd like to give them the benefit of the doubt that they just didn't foresee this until later, but it would have been better if they could have been more intentional up front and just, you know, not had to make the license change, but, you know, sometimes that happens.

Cory: 44:51

Yeah, and it's, like, it's funny from, like, a business standpoint, like, it makes sense, like, I mean, it's, that's the right business decision to make, right? Like, you, I mean, at the end of the day, we're here to, you know, drive the shareholder value, right? Like, but it's funny, it's like, you know, we're going through some stuff that we're about to be open-sourcing now, and, like, we're considering, I mean, not that we're considering Gruso, but it's, like, we're trying to figure out, like, what licensing is, right?

Like, the lawyers obviously have opinions, but, you know, I think that we're pretty dedicated to open source, like, you know, our entire team's built our careers on it, right? And we want to make sure that we're picking licensing that's, makes developers comfortable, and it's funny, for, like, the longest time, you know, I felt like developers didn't care so much, they just grabbed something and throw it in there and use it. If you're a bigger company, you're, like, no, I'm not here, yeah, I know, I know, if you're a bigger company, if you're lucky, you very much care about the licensing, but, like, you know, startups, like, people aren't paying attention to it, like, people know now, like, people are very familiar with, like, the differences between MIT and DPL and Apache, so it's interesting to see, like, developers starting to be concerned with the license they have because they've, you know, run into this with, you know, Elasticsearch and Mongo and Red Hat and now HashiCorp, and I'm really curious if it's going to change, like, the way we do open source, right, like, I think that some of these tools, you get to a point where it becomes so important to the ecosystem, right, like, and not just, like, the ecosystem in, like, their small orbit, but, like, the grander ecosystem, right, like, the HashiCorp changes impacted the CNCF, like, they changed out a bunch of tooling because of the change, right, and so I'm almost curious if we'll start to see more projects, like, leaning towards foundations earlier and if there's, like, a right time to put something into one of these foundations, like Linux Foundation, to make sure that, like, it stays vendor independent and make sure that it really becomes something that the community owns versus an organization, but it is, I think it's a very interesting time and that was, you know, it was sad for me to see.

It makes sense onto why they did it, but I'm really curious what some of these open source projects are going to be doing moving forward, if they're going to be kind of following suit for some of the ones that are getting more powerful and more adopted.

Colton: 47:19

Yeah, I'm curious to see how they actually go about enforcing this. I'm not sure if I've heard any rumors of them actually starting to go after startups yet or sue anyone, but, so I think we still need to wait and see how this plays out for them, but I don't know, have you heard anything on your end of people actually getting chased after or, and I'd also be curious, yeah, just the latest on OpenTofu?

Cory: 47:49

Yeah, I'd say, you know, I haven't and, you know, I mean, we're obviously on their radar. But I think that, you know, they made a business decision, but I still think that, I think this is a, this is right, this is a business decision, very financial decision, but I think at the heart of HashiCorp, like it's still run by good people, right? And I think that, I think they probably did this and they know that, oh, people will go and they will, you know, stop doing it, right, or move or shift or pivot, right?

I can't imagine that they would throw stones at startups, like, and actually go after people. I mean, I would be very surprised if that happened. Now, if they were maybe going after AWS, like resource manager or something like that, right, like I could see that being viable, but I don't think they're going to, you know, so I'm after, after some of the small words now, maybe they have that in their pocket for, you know, when they, IPO, right, maybe that's what it is, but I don't think that, I couldn't imagine that they would.

Colton: 48:49

Let's hope.

Cory: 48:50

We were a part of OpenTofu along with some other really great companies like Spacelift, MZero, Harness, Bruntwork, you know, one of those companies that like, I think really defined this space, right, like HashiCorp built the tools, but Bruntwork did a lot of the work to get the community here. So OpenTofu has been great. We had the first GA release a few weeks back, so it's up, it's stable, it's got feature compatibility.

We've had a lot of, you know, like kind of legal hurdles thrown in the way. So, you know, OpenTofu can't use the Terraform registry, so they changed the licensing on that as well. So we had to go build a registry and we open sourced it.

It's fantastic. So it's out there. It's a serverless registry.

You can run it internally if you want. So we had to build our own registry. So a lot of people kind of see our progress as a bit slow, but we've maintained feature compatibility with Terraform and we're doing that through reverse engineering.

We've got a strict policy of not accessing any of their source code. And in the meantime, it's like we've gotten to the Linux foundation. We've got our application done for the CNCF.

We had to build this registry to maintain feature compatibility. And we've added features that aren't in Terraform, like Terraform state encryption, right? It's something that people have been waiting for for years.

Just basic encryption around our state files, which are the old secrets and information that shouldn't necessarily be easily accessible. So I think that we've had amazing progress and it was really exciting recently. I can share this in the show notes as well.

The state of OSS report shows that there is already like 8% of people surveyed have adopted OpenTofu internally. I think Terraform is sitting around like 22%. So OpenTofu has reached almost where Pulumi is.

So I mean, you're seeing, you know, kind of big companies adopting this. GitLab recently announced that they're going to be replacing all their Terraform templates with OpenTofu. So I think that people are concerned with the license change, even if they're not directly impacted by it.

So I think it's exciting. It's bittersweet for me, honestly. I love open source.

I don't think that we were necessarily, as a company, that we were necessarily impacted by the change because we compete with a different product that actually feels a cut out for us. So I wanted to be a part of this because I was just like, I felt like there's a little bit of turning backs on people that built up this community. But at the same time, it's like, I don't want to see a fractured community, right?

And so now we're kind of entering an interesting space. It's like we're committed to keeping feature compatibility with Terraform, but we're also building our own features, right? So if you use OpenTofu, that's great, but we're not backwards compatible now, right?

If you start using OpenTofu and you're in your state and then, let's say, your organization requires you to go back to Terraform for some reason, you have to now take away that layer of security, which I think is disappointing to me as somebody who's concerned about security and operations. And so it just sucks to think these two groups of people are going to be kind of having, I don't want to say, I hate the term like cold war, because I don't think there's, on our side, there's really not any animosity. I mean, it's a group of competitors that all get along very well, funny enough.

But like, we're going to have two groups of people kind of trying to implement this same standard, if you will, of like how this thing works. And I'm sure that now that we've implemented state encryption, you'll probably see it happen in Terraform finally, right? And so it just seems to me like a monumental waste of effort, right?

Like it's one thing for two open source projects in the same space that have very different use cases, right? Pulumi and Terraform and Wingling. Yeah, let's have all three of those.

Like they're three very different ideas. That's exciting, but like two groups of people that are literally just doing the same thing is kind of a bummer to me. So I don't know how it can go.

I would love to still see like some way to bring the community back together. That's my personal take. And I hope that it gets there.

And I would welcome actually corporate open arms. I'm not sure necessarily if everybody in the open source food space would or how that would look. But I mean, that's kind of what I hope happens.

I hope that we kind of all see this as ridiculous. There's a big pie to bake here. I mean, the funny thing is, is like, I feel like we're all kind of fighting over pain.

It seems like a crazy thing to say given HashiCorp's market cap. But like, if you look at the state of CD report last year, only 27% of companies are doing infrastructure as code. And the winner is still Ansible, right?

So it's just like, there's a lot of people left to sell to. I don't know why we need to like fight over the people that we have today. It's like there's a huge market out there.

And so I feel like, you know, there could have been a better way to look at how to do this and how to move forward with it. And I think that we are where we are. And that sucks.

And I hope that it reconverges at some point in time. But we've got great progress in the meantime. And we got a great adoption.

We've got a day at KubeCon next week. So there's an open tofu day. So it's all very exciting.

But yeah, it's a little bittersweet at the same time.

Colton: 54:14

Yeah. Painful situation. But it is remarkable how the community people like you have come together to lead the charge on this.

So kudos for that.

Cory: 54:25

Yeah, yeah, it was funny. We're at Re:Invent and SpaceLift was like five booths down from us. And I was wearing a MassDriver shirt.

And one of the employees was wearing a SpaceLift shirt. And we're talking and just kind of, you know, kind of bullshit. And somebody comes by and like, looks at us just like a random person.

They're like, aren't you guys competitors? And we're like, yeah, yeah, we're friends too. Like, there's nothing wrong with that.

Like, I mean, I think it's good to discuss ideas. And we're doing things very differently, very different target audiences we're trying to sell to.

Colton: 54:54

So but in the alien atom, humanity unites.

Cory: 54:57

So yeah, everybody can just be as welcoming and forgiving as the IAC community. Oh, geez. Awesome.

Well, I really appreciate having you on the show today. We want to ask two last questions. Just both very short.

What's what's a tool or service that you've seen recently that you're excited about?

Colton: 55:17

Recently, I saw a demo for a very cool demo for a database company called Tiger Beetle. And it's for financial accounting. So if you think about banks and payments companies that have to handle double ledger accounting, they're like kind of to like, you know, there's a problem with the issues with consistency, right?

And potential like durability, what can happen if you have a failure mode, and you updated one account, but not the other, right? So banks build a lot of custom logic into their databases to like account, you know, to actually have this accounting logic. But the thought with Tiger Beetle is to have that these abstractions natively in the database.

And, you know, on top of that, be highly, highly performant. It's written in some programming language called Zig that I've started to hear a lot about. I don't know too much about it.

I don't know if you've come across it, but seems a little bit hyped up and interesting.

Cory: 56:19

Yeah, that is cool. I have heard of Zig. I think I have not used it.

I think I've seen a terminal application that was written in it recently. But I definitely heard it a couple of times. That's very cool.

Awesome. Last question, where can people find you online?

Colton: 56:36

You can find me on Twitter, Colton Dempsey. And yeah, I encourage founders to reach out. We invest primarily at series A stage and later in B2B tech companies.

And we also have some services that we provide to our portfolio. Just put that out there. We help a lot with go-to-market.

We have a 10-person in-house go-to-market team that generates qualified leads for our portfolio companies. We've closed over 300 deals on behalf of our portfolio and have millions of dollars of bookings for individual companies. One example, Sysdig, we helped them land one of their largest customers and have booked millions of dollars for and numerous other companies.

So yeah, I would encourage you to get in touch.

Cory: 57:30

Awesome. Well, thanks so much for coming on the show and hope to be back sometime soon.

Colton: 57:35

Yeah, talk again soon. Thanks, Cory.

Outro: 57:42

Thank you for listening to this episode of the Platform Engineering Podcast. Have a topic you would love to learn more about? Let us know at cory.massdriver.cloud. That's C-O-R-Y at M-A-S-S-D-R-I-V-E-R dot cloud. Catch you on the next one.