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

Startups always bring refreshing perspectives and brand-new ideas to any space, and the platform engineering industry is no different. In this episode, Cory O'Daniel sits down with Colton Dempsey of Next47 to discuss the important role of startup ventures in the progress of platform engineering. He explains the five categories of startups, why many of them are building more diverse feature sets, and the most effective monetization approaches for open-source projects. Colton also delves into the rise of cloud-native technologies and Kubernetes, detailing how they influenced his investment strategies.

‍

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

With me is Colton Dempsey, a Partner at Next47. Colton, thanks for being on the show.

Thank you so much for having me. I’m excited to be here.

Career Background

I would love to learn a bit about your background in venture capital, particularly in the DevOps and platform engineering space. I enjoyed the posts you wrote on DevOps Rebrand or a Meaningful Step Forward. As a platform engineer, that's something that I have feared and hoped was not the case for most of my career, but I would love to know about your journey.

I joined Next47 in 2018, and we're a B2B-focused venture capital firm. We invest in tools used by engineers and DevOps professionals, data teams, sales teams, marketing teams, and roles across the enterprise. I have a particular love for the infrastructure side of things. That's where I spend the majority of my time. I came across platform engineering more so from my interactions with startups in the space. 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 I wrote that blog post to that was the initial question, “Is this a rebrand?” That's what a lot of people were calling it. I came out thinking this is platform engineering is a valuable pattern and approach. It's been great diving into the space.

Role Of Startup

We met at Reinvent and when we were there it was funny the number of DevOps and platform engineers that I met that were very much concerned about as well like it being at the rebrand. I think that most of the industry understands that the work and mission are important, but we've been through this rebrand before. A lot of ops people felt like they got rebranded from ops to DevOps engineers and then it happened again with SRE. A lot of people are afraid of this happening again. How do you think that startups in this space can help make sure that this isn't just a rebrand and push this mission forward?

Some of the concerns are around the title. I'm not sure that platform engineering has to be a title. There are 22,000 now Platform engineers. I wrote a blog post about it. It’s growing at a decent clip, but still fairly small, but I don't think teams necessarily need to call themselves something different. I view platform engineering as an approach that helps both developers and DevOps teams or platform engineers operate more efficiently. I don't think there's anything wrong with building products that help with that. I'm not too concerned about it, but about the rebrand piece, I think this will be valuable long term, but it's still very early and startups are figuring out what provides the most value and how to sell this appropriately because it can definitely be tricky when you're selling to two different parties within an enterprise.

‍

Platform engineering is an approach that helps both developers and platform engineers operate more efficiently.

‍

I'm familiar with that one. It's interesting because when you look at some of the most successful companies in the world, they're doing this. I feel like when you look at FANG, it has platform engineers like Google. The clouds in and of themselves have done a lot of platform engineering so that they could extend the services to us as developers. You see that this is something that big companies have to do.

I feel like there are a lot of large organizations out there that you may see as antiquated, the grocery chains, some of the older brick and mortar now eCommerce sites, and the things that we use every day as people, not just software engineers that they can have some of the most amount of struggle of trying to get this talent. I do hope that 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 in engineering and DevOps sectors, what is the most exciting about those sectors in those companies that keeps you interested?

Within infrastructure, it's an incredibly complex rich ecosystem of startups that's perpetually evolving. The interdependency on other tech, especially pronounced in this space and the waves of adoption that we see whether it's moving to the cloud or adopting Kubernetes, new things like serverless create lots of new opportunities every day for new startups to emerge and claim a competitive advantage versus the incumbents who weren't born in the cloud or designed for Kubernetes. It's the ever-changing nature of the space that gets me most excited.

Portfolio

Are you comfortable sharing a couple of the companies in your portfolio that you're most excited about that are in this space?

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. It's still early days of the category and I think there's some convergence that will happen. I’m excited to see how that develops. We have companies in our portfolio like Logz.io that work with the ELK stack related to observability and monitoring. It can be a piece of platform engineering. Some of the challenges of building these platforms are how broad they should be and what they should encompass. Right now observability operates a bit in its own lane. It's a pretty well-defined category, but in the long-term, I think that it is already being encompassed in some platform engineering tools. We are still actively looking for interesting companies in platform engineering.

Qualities Of A Promising Startup

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

To find them, there are lots of ways. A lot of them will be open-source startups. You can find them at events like KubeCon. The CNCF has a book I'm reading called Platform Engineering On Kubernetes. They are operating in those open source communities and other DevOps meetups, great way to find platform engineering startups. At a high level, I think it's the startups that in platform engineering, they can strike a good balance between value for developers and DevOps. I think platform engineering aims 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. You have to make it comfortable for them for developers to take on that additional responsibility.

‍

The startups in platform engineering must strike a good balance between value for developers and for DevOps.

‍

It seems like there needs to be an exchange where developers are maybe taking on more infrastructure and DevOps people or platform engineering teams are learning more codes. There's a bit of a trade there going on. That balance is important and it's hard to give specific attributes that we look for because I think there are many exceptions. There's always an exception in the startup world, but at a high level, I think we're looking for great teams, building a product that is either a huge leap above the performance of the incumbents in a defensible way.

That way you're tackling an existing bucket of spend, 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 fundamentally disruptive and even not be as defensible as that previous example I mentioned. The idea is you'll get such a headstart that you'll be leading that way.

Open Source Project Value

You mentioned the open source component, that's what I'm curious about especially from the VC point of view, with all the shake in the market over the past years, does a good successful open source project still have the same value as an investor when you're looking at an organization or has that receded a bit?

If you look across the platform engineering space, probably half or more of the startups at least like in the landscape I made have an open source approach. It’s important and great, but it's not absolutely necessary. I think it provides a great pipeline for startups and great distribution, but you can also find projects or companies that have so much adoption and still are struggling to monetize. When looking at open source, there are plenty of benefits but you need to make sure that you are being intentional about what you're putting in the open source and what you're keeping proprietary.

Some founders that come from the open source world struggle with that a bit, but it's like you are a commercial entity ultimately people won't fault you for it if you make it as fair as possible. There's a balance to strike between putting out an open-source project that provides enough value that people get excited about it and not so much that there's no ability to monetize. Having those pay walling strategies is important.

I feel like especially with like the budget cycles you get on operations and DevOps teams, I feel like for in large organizations I've worked in like hopefully you get a quarterly one, don't get stuck in the annual budget you have to deal with but that open source is the way for you to sneak something in under the radar where you don't have a budget for it yet and try it out and prove the value to the business. I've always seen that as an important component of getting good dev tooling or operations tooling like into a business that's something I've been thinking about with how much more pressure there is for startups to get bigger revenues before they get to series A.

You have to be pretty intentional about it and there's no rush necessarily to be open source from the start. You could be source available or can take time to figure out, “What components of my product are helpful to be open sourced?” Maybe it's more of a format that you've developed or some type of syntax that people can build things and then it's helpful to have that community. Other times, maybe you want the open source primarily to get some distribution but definitely like to help enterprises be more comfortable being able to read the source code. There's a variety of different approaches you can take.

Startup Categories

What startup categories do you think to embody that platform engineering mindset with the evolution of DevOps and platform engineering where do you see these opportunities for innovation investment over the next couple of years?

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 is there, but Spotify has their backstage product which is a project that is known pretty well. It serves as either a list of services and who's responsible or can serve as 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 think there are categories like environments that are helping developers spin up more isolated ephemeral environments rather than having a shared resource that can cause conflicts in the testing process. There are categories like platform orchestration. I see a variety of approaches there, but generally trying to help provide abstractions for developers to work with things like Kubernetes or or work with cloud infrastructure more easily either by defining how their application should work upfront, having some of that configuration upfront and passing it over to the platform team or then there are tools like Massdriver in this category that are more visual and it's not like a YAML format but it's like a real product you can interact with.

Infrastructure code fits in this category pretty well. There are hosting tools, if you think about companies like Vercel that are essentially enabling smaller teams or developers to provide their code. Vercel handles the rest with things like hosting. There are tools like that that tend to focus more maybe on the SMB side. Incident management is an emerging category, although I think it's been around forever. I see more and more workflow tools getting built up. Those were the five categories that I initially identified, but there were lots of debates that we had about other spaces like build tools, should that be included or CICD tools?

For build tools, we have seen more companies have developers owning that in part already. Maybe not embodying as much of taking something that traditionally was DevOps and making it a developer responsibility, 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. I'd be curious about your opinion. What belongs in the platform? Do build tools belong in a platform? Does observability belong in the internal developer platform?

That's an interesting question because I think that you can put a lot of stuff in a platform and our product is obviously in the space and I've used a fair number of our competitor's products and I'm friends with a lot of these people. Our products are very different. The reality is organizations are very different. Nobody's product in this space is going to be able to sell to everybody. It's funny, even within an organization, our teams are very different. We run Massdriver, we're on Massdriver, but we also use Vercel. It is the only thing that we use outside of Mass Driver. It's because it is fantastic for our front-end team. One of the things that's a little worrisome is I see some companies talking about like, “You need the IDP. 80% to 90% of your team should be using it.”

That's not a real expectation. We can't expect the AI and ML teams to use the same platform that our backend teams using in the same platform that our front-end team using. As far as the tooling and functionality that will be in these platforms is going to depend on the team that's using it, I think that we're going to see that teams are going to start to coalesce around specific platforms based on their function. What's interesting though as far as the bigger players in the space is who can expand here. 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 Dev X now everybody's trying to get a piece of this pie that we're baking in this platform engineering market.

I'm curious about what behemoths in the space are going to start to do some of the work and some of the functionality you're seeing a lot of the startups implementing. That'll be pretty interesting there. As a startup, it's a little scary to think of maybe a HashiCorp moving into the platform engineering space. I don't think that there is a tool that every single person at every single organization is going to want to use. When we start to see some of these bigger IAC environments, you know deployment management and incident management start to have some of this functionality, it's going to validate the space.

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

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.

DevOps Teams

I've been an operations and DevOps engineer for many 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 many years. We have a hard job and we're always outnumbered. There are 3, 4, or 5 ops people and 200 engineers. It's hard to get a good DevOps culture when you're constantly struggling for budget and you're not seen as a direct value that adds to the product that a lot of organizations.

Have you noticed that being on DevOps teams? How does your budget compare to the budget of the engineering team?

It's funny how it works. It depends on if there are good cost controls in the org. Especially early on, all of the cloud costs end up rolling up to the DevOps team. It looks like a big budget, but the reality is you're running your developer's infrastructure. As you get more mature it's boring to talk about but having good cost controls and attribution of cost for your resources gets people an idea of who's spending the most like, “I can see that there's $100,000 spent a month for the backend team and there's maybe $500,000 a month of storage and processing and ETL for the data team.” 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 research to see the DevOps team has a very small budget.

We have a handful of engineers compared to what is on the product team. That's customer-facing. That makes sense. I think that you're outnumbered staff-wise and on the budget time and time again. That's something that is going to be hard for a lot of DevOps teams so they want to move to platform engineering. The people who aren't having it shoved down their throats have to somehow show value, whether that's through another buzzword, the thinnest viable product or you know, MVP or through doing good DevOps culture in your org. We have to show value so the business sees that value add 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. We're far from the product. We're far from product management. I haven't seen a lot of teams lean into doing that DevOps work, like seeing what their engineering customers need and surveying people.

Figuring out how you can be a force multiplier for your engineering team versus doing dev. I don't think that they necessarily are doing that on purpose and a lot of them are dealing with dev. You get brought in as the first ops person 3 or 4 years into a project and like day one you've got a lot of work to do before you can start even adding that value. The budgets I feel like tend to be a lot less when you're not counting the entire cloud into it. I think some people are still struggling with 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 a year for this, $100,000 a year for this one.

Their budget is getting spread out to all these tools that solve a single problem. Now they're looking for, “Who can solve three of my problems so I can consolidate some of my budget on one vendor and get some of that money back so I can hire another teammate.” That's why you're starting to see a lot of these bigger organizations start to have these diverse feature sets. Somebody like Logz can start to do tracing as well. It's like, “I'll use them for my logs and tracing instead of buying a LightStep or running a hotel or you here myself.”

Over the past few years a lot of interest in consolidation and cost optimization. We see a lot of tools emerge in that space it's interesting that you mentioned that the DevOps budget may seem large, but when you get down to it and attribute everything, it's not as large as you may think. 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 monetize with governance features. It's very difficult to get developers super excited about adding a lot more governance features to some products that they already like. You're pitching two different value props and how do you combine and how do you pitch both velocities to developers and control to DevOps teams? I know that it's not the only thing DevOps teams are concerned with, but that is a typical tried and true method of selling that type of ROI.

‍

DevOps budgets may seem large, but when you get down to it and attribute everything, it may not be as large as you may think.

‍

It's funny when you look at a common ratio that we threw out there. Depending on what blog posts you read, but you'll see people say 1 to 10 is good like DevOps or operations to engineers. You'll see some people say 1 to 7. You see a lot of times companies realistically have 1 to 20. That is right there when you look at people's power. You can see that there are 7 times the budget for engineers, or 10 or 20 times the budget just for people, let alone their tooling. A lot of times we struggle for that budget.

We have to be sensible about like how we're spending it. If I buy two different tools for two very specific use cases, that might be the salary of a person that could bring in and that might be able to run Jager we don't have to go buy a tool in the space and they can also help with some other stuff. One of the things that's key to being a great DevOps engineer is being frugal. That sucks as a vendor in this space. You don't have a big budget. You have to figure out how to get the most bang for your buck out of the tools and people that you're hiring.

That's why things like land and expand strategy can be important for platform engineering tools to get that initial foothold and prove value over time.

Rise Of Kubernetes

How has the rise of cloud-native technologies and Kubernetes influenced your investment strategy? There's a lot of tooling in the space now. How is that changing how you think about investments?

Kubernetes has surpassed many people's expectations for its staying power. It's been about decades now. I think it's becoming more and more viable to build a company that is based on Kubernetes and highly focused on it or even being a pure-play Kubernetes company. If I look into the past, there have been companies like Rancher that have been successful in abstracting on top of Kubernetes. There are been companies like Red Hat that were around well before Kubernetes, but picked up the mantle and helped bring that project to life. There haven't been so many pure-play Kubernetes companies that have super successful exits yet. In fact, it's been maybe more of the ancillary services around Kubernetes that may have had some of the initial success of things like securing Kubernetes rather than the actual dev tools on top of Kubernetes.

There's more and more opportunity for startups to purely focus on Kubernetes, but I think it's still risky to have that be your only strategy in the long term. If you want to serve enterprises, they're not just going to be necessarily running on Kubernetes. It's important to be able to help people who work on AWS natively and use VMs or whatever. I still like to see companies that have a bit more flexibility to go beyond Kubernetes, but it will be around for a very long time. VMs are still around. Mainframes are still around. Over time, we'll start to see more pure-play Kubernetes companies.

There was a great Twitter thread where people were discussing that Kubernetes, for the most part, doesn't have a competitor. I'm sure people listening are familiar with it. People are mad like, “Wait a second,” but it was DC/OS or Mesosphere. There are a lot of these orchestration tools. There was Docker Swarm, but Kubernetes won. When we look, there's not anything that's like competing with it. You can say like, “Maybe there's a HashiCorp nomad.” I think that has a very different use case for people in the VM and containerization world, but Kubernetes won this orchestration war. I like watching this Twitter thing where people were like, “We need competition.”

I have this feeling that we don't. There have been so many of our jobs as DevOps engineers where like we're reinventing the wheel. There's some stuff that we do that's very custom to our orgs, definitely some bespoke things but a lot of what we do is a commodity. Seeing a lot of this work commoditized into the single API that makes our knowledge portable gives us the ability to have more secure systems. I can take my knowledge to another company or another cloud and have an 80% understanding when I get there. That is a power that's frequently overlooked with Kubernetes. That’s the best feature of it.

There's so much stuff that it does. That ability to say that we all understand how this works, whether it's OnPrem or in the cloud, is something that I don't feel like a lot of technologies give you for the people who are still shaking fists out there. I don't know if we have competitor deposits. There are certain points where it's like we need a good standardization and start seeing tools coming into the space is great. You're going to have to do that security stuff no matter what, whether it's serverless or whether it's VMs I feel like being able to have like a set of security tools that starts to tie into something that we all are starting to use, I feel like it is a great place for us to be and agree. We still have mainframes and VMs out there and they're going to be there for a long time, especially in some industries.

It's exciting to me to start to see this taking off and more organizations leaning into it and all the major cloud providers now having a Kubernetes offering. I hate using the word game changer, but I feel like it's so much easier to learn stuff. I can start Kubernetes. Let's say I'm a fresh college grad. I can install it on my machine and get an idea of how to run it. You can't do that with the cloud. You can go use a free tier of AWS to start learning its API, but then as soon as you go over that free tier, that's not very welcoming to you as a fresh college grad where you can get a pretty good understanding of how Kubernetes works in a truly free environment. We haven't had that for the entire history of the cloud, a great way to learn about it locally. I'm pretty excited about the stuff in this space.

I think there's still a lot more meat on the bone for Kubernetes and startups to tackle. I think there's plenty more abstraction to be built on top, although a small part of me as a venture investor would be curious to see what the next Kubernetes is and invest in companies capitalizing on that. I don't necessarily want to see that quite yet. There's plenty more to do in the Kubernetes space.

Startup Challenges

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

As 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. It's important to be as crisp as you can and intentional upfront about how you set up your business model and align that well with your product. If you're selling to enterprises, they've made huge investments in their software development lifecycle and may be reticent to pull out and rip out everything. A rip-and-replace strategy for the enterprise, if you're an early-stage startup, is a very tall order. It's important if you're selling to an enterprise to make a modular platform you can at least give them the option to insert you in one particular part of their toolchain and then expand over time. Enterprises also at the same time require a lot of depth of product.

You need to give them the option to have that full end-to-end automation. 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 SMV, you might want to have a clearer simple pricing model. Their budget upfront is very transparent for them to see because they have super-strapped budgets. That will help a bit with the adoption. If I think about the product for platform engineering, it's not enough to provide configuration management for companies for your customers. If you provide some type of opinionating on top of the infrastructure, it's not going to be a huge leap up in productivity probably for developers. You're 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 slightly simpler.

What unlocks value is if you can get developers to build their own domain knowledge into the platform. That's one of the things I think is great about Massdriver is you provide the ability to be opinionated, the DevOps team or platform team can set developers to input very specific, only the variables that they need to know about and like help them with the configuration. They can use these building blocks to build abstractions that are closer to the business logic that they need. That I think is what will hook developers and make this more of a productivity play than a governance play.

When you think about the work that you do in the cloud, we've always had this with ops and dev and then what became DevOps. There are these two teams that have to work together to get this stuff up and out. It is funny when you look at thinking about codifying business needs into the platform. When you look at almost any service in the cloud, there's a set of configurations there that are very much for the developer that developer cares about then there's a set of configurations that are very much what the operator cares about, looking at like running a database like, “I want it to be highly available multi-zone.” I don't think the developer cares much as they're not getting woken up at 2:00 AM. What they care about is the version of Postgres or MySQL.

I feel like the unfortunate thing with how we experience the cloud and you have tools for developers, if you give them Terraform or OpenTofu, you hand it to them, they have to learn all these attributes and all these configurations. There's so much for them to think about. In reality, they care about very few of the attributes of any given service of the cloud. They want to think the work and they want it to be the version that they need for their application to work. At the same time, ops is like, “I want it to be secure, compliant and cost-efficient,” but we have this one tool for both of us to try to agree on I feel like that's very hard when you're handing developers that all tools like Terraform and OpenTofu help directly.

There's so much of it 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 the cloud. They only have 40 hours in their week. They might want to learn it but it's like, “Learn it in your free time. Get your work done. Get to your free time.” You shouldn't be spending ten hours of your week trying to understand my side of the world's language to do your job. That's been my philosophy.

I've heard some objections from DevOps professionals that say, “I don't need these platform engineering tools. We have infrastructure code that spins up infrastructure,” and they can use these and take an almost scripting approach to this. That works to an extent, but when you are hiring a lot of people, it's more onboarding time. If they don't know Terraform, it can be more brittle. 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.

Monetization Approaches

You mentioned pricing. I would love to dig into that a bit more. When we went through Y Combinator, one of the first things they told not to us directly, but to everybody, it was, “Your pricing is wrong and that's fine. Your pricing is going to change eight times.” I feel like I've gone through much like pricing trauma to get to where we are, but it is very common and if you're a startup today, your pricing's wrong. It's going to change if you've ever been told that it's wrong. What are some of the monetization approaches you've seen be successful in the DevOps and the platform engineering space?

I don't think there's one size fits all. I think there's plenty of room for experimentation on pricing, especially in the early stages of a startup. When you're getting started, you don't even necessarily have pricing on your webpage. 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. It's important to think about all the tools that you have at hand. You can price simply based on seats, but may not always correlate to the value that the customer is getting or say you want. Pricing by seats may also limit the spread of your tool within an enterprise. To counter that, you can sometimes have some upfront fee for using the platform and make the Percy pricing a smaller incremental charge on top.

If your customer's usage varies a lot and that usage is directly tied to your own costs as a startup, then a consumption-based business model is probably better. You could do that on compute or on events. There are lots of different ways you can do that. There are tools out there that'll also help you with consumption billing. because there's a lot of custom logic that you have to build into that. It depends on whether you are an open-source project or not. When you have an open source strategy, you have to decide what you put into the product upfront. There's less room for experimentation there. When I think about, an example, it could be Cypress.io. They have an open-source project where you want to parallelize your tests.

That is seen by developers as far as the open-source product works end-to-end. If you want that added speed, that can be an upsell, but it's not just speed. You can sell a lot of upsell. You see basic things like enterprise support and there are various levels of support you can get way you can send them to your community Slack channel or you can have a dedicated Slack channel where you talk with them or you can have a dedicated customer success rep who will hop on the phone anytime they want. People will put SSO as a super common upsell. I think you have to be careful with that one. Some people don't appreciate putting SSO as an upsell. What do you think about this?

Cypress has done a very thoughtful job of when they convert people to paying. This drives me nuts as an operations engineer. I feel like a lot of things people charge you for. I feel like they're sticking it to you. SSO included. Good security shouldn't be something you have to pay for. 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. When we're making security and we're making tools for operations bulk, that shouldn't be an option. It should come with it. We had this very early on. We didn't want to charge per sea. because I've seen teams hit a seat max and like, “We'll share passwords.”

It's like, “That undermines security.” There are a lot of interesting things that people will reach for because they're like, “It's a measure of how much somebody's using my product.” At the same time, I think as vendors, we have to think about our values, morals, and what we stand for. Does that pricing plan align with it? I've seen people that say they're going to make you more agile and DevOps.

They charge you based on deployments, “You incentivized me to not make as many pull requests.” You're going to impact my culture with this. Pricing is hard. We still haven't gotten there. I'm sure we'll change it eight more times on our path to series A, but I think that a lot of times people reach for that. In SSO, you have to come to enterprise and it's like, “Security is becoming much more important early on.” That shouldn't be the thing that differentiates your enterprise product. You should have some value in it, not baseline security.

Features would be the number one most appreciated, upsell from developers and DevOps teams like security governance may be the next piece. The final pieces that are probably least appreciated are those arbitrary limits that aren't necessarily tied to costs for the vendor. SSO is one example, although it falls in security, but it's you've built it, why don't you let everyone use it? It's great. For people to have security. You don't want your customers getting breached anyways. There are other arbitrary, sometimes tools will limit, like making it impossible for the product to be persistent over a long period of time. The URLs will change or something like that. Those are strategies too, but they tend to be a little less appreciated by customers, but you do see that as well.

Investing In Big Companies

I have a question I'd love to ask you and it's an interesting one for me to ask, being that I'm involved in this one, but speaking of pricing and open source, going to be thinking about HashiCorp's recent change to the license of all their flagship SSO tools. People aren't familiar, they changed to the Boost license, which is the source available. It has limitations on who can use it if they're direct competitors with HashiCorp. Has this impacted VC's views on OSS investments at all? If so, how?

It's happened in the past. It's happening now and it will happen again. It's not pretty. From the HashiCorp perspective, you would expect there to be backlash, but, I think they also learned the importance of communicating this clearly. It's a challenge for them to do 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 they probably don't have an incentive to directly identify all of their competitors. They had a nice call in and asked us for an approach, which is difficult to see how people will do that. It is risky to depend on open-source software from a commercial vendor if you are operating in their orbit and could potentially be competitive.

‍

Itis risky to depend on open-source software from a commercial vendor if you are operating in their orbit or could potentially be competitive.

‍

It shows that HashiCorp is nervous about some of these startups operating in its space. If I look at past examples like MongoDB changed their open source license back in 2018. I think that was more about cloud providers, but this is a case where it's more focused potentially on the startups. That's one interesting difference, but there's a risk to startups operating on those open-source tools and it's going to be a painful process if you have to make a license change. Sometimes it's maybe the best economic decision for the business, but I like to give them the benefit of the doubt that they didn't foresee this until later. It would've been better if they could have been more intentional upfront and not had to make the license change, but sometimes that happens.

It's funny from a business standpoint, that’s the right business decision to make. At the end of the day, we're here to drive shareholder value. We're going through some stuff that we're about to be open-sourcing now and not that we're considering boost, but we're trying to figure out what licensing is. The lawyers obviously have opinions, but I think that we're pretty dedicated to open source. Our entire team built our careers on it. We want to make sure that we're picking licensing that makes developers comfortable. It's funny, for the longest time I felt like developers didn't care so much. They just grab something and throw it in there and and use it.

If you're at a bigger company, you're like, “No, I'm not here. I know at bigger companies.” If you're at Lockheed, you marry much and should care about the licensing. In startups, people aren't paying attention to it, but people are very familiar with the differences between MIT, GPL, and Apache. It's interesting to see developers starting to be concerned with the license they have because they've run into this with Elasticsearch, Mongo, Red Hat, and now HashiCorp. I'm curious if it's going to change the way we do open source. I think that some of these tools you get to a point where they become important to the ecosystem, and not just the ecosystem that is in a smaller orbit, but the grander ecosystem.

The HashiCorp changes. In fact, the CNCF changed out a bunch of tooling because of the change. I'm almost curious if we'll start to see more projects like leaning towards foundations earlier and if there's the right time to put something into one of these foundations like Lennox Foundation to make sure that it stays vendor-independent and make sure that it becomes something that the community owns versus an organization. It's a very interesting time and that was sad for me to see. It makes sense why they did. I'm curious what some of these open source projects are going to be doing moving forward if they're going to be following suit for some of the ones that are getting more powerful and more adopted.

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

I have. We were obviously on their radar, but I think that they made a business decision, but I still think that this is a business decision very financial decision. At the heart of HashiCorp, it's still run by good people. They probably did this and they know that “People will go and they will stop doing it, move, shift or pivot.” I can't imagine that they would throw stones at startups. I go after people. I would be very surprised if that happened. If they were maybe going after AWS like resource manager or something like that, I could see that being viable, but I don't think they're going to necessarily after some of the smaller weeks.

Maybe they have that in their pocket. IPO is what it is. I couldn't imagine that they would. Let's hope. We were of OpenTofu along with some other great companies like SpaceLift and Harness or one of those companies that defined this space. Corp built the tools, but Grunt work did a lot of the work to get the community here. It's going great. We had the first GA release. It’s stable. It's got feature compatibility. We've had a lot of legal hurdles thrown in the way. Who can't use the Terraform registry?

They changed the licensing on that as well. We had to go build a registry and we open-sourced it. It's fantastic. It's out there. It's a serverless registry. We run it internally. We had to build our registry. A lot of people 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 script for a policy of not accessing any of their source code. In the meantime, we’ve gotten to the Linux Foundation. We've got our application done for the CNCF. We had to build this registry. We've maintained feature compatibility and we've added features that aren't in Terraform, like Terraform State Encryption. It's something that people have been waiting for years, basic encryption around our state files, which are the old secrets and information that shouldn't necessarily be easily accessible.

I think that we've had amazing progress, and what's exciting is that the state of OSS report showed that there is already 8% of people surveyed have adopted OpenTofu internally. Terraform is sitting around 22%. OpenTofu has reached almost four Pulumis. You're seeing big companies adopting this. GitLab recently announced that they're going to be replacing all their Terraform templates with Open Tofu. I think that people are concerned with the license change, even if they're not directly impacted by it. It's exciting. It is bittersweet for me, honestly, like as a company that we were necessarily impacted by the change because we compete with a different product of HashiCorp. It was a cutout for us.

I wanted to be a part of this because I felt like it was a little bit of turning back on the people who built up this community, but at the same time, I don't want to see a fractured community. Now we're entering an interesting space. We are committed to keeping feature compatibility with Terraform, but we're also building our own features. if you use OpenTofu, that's great, but backward compatible now. If you start using OpenTofu and you're encrypting your state, 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, it's disappointing to me as somebody who's concerned about security and operations.

It sucks to think these two groups of people are going to be, I hate the term Cold War because, on our side, there's not any animosity. It's a group of competitors that all get along very well. We have two groups of people trying to implement this same standard, if you will, of like how this thing works I'm sure that now that we've implemented state encryption, you'll probably see it happen in Terraform finally. This seems to me like a monumental waste of effort. It's one thing for two open-source projects in the same space that have very different use cases. Pulumi, Terraform, and Winglang, let's have all three of those. They're three very different ideas that are exciting.

Two groups of people that are literally doing the same thing is a bummer to me. I don't know how it can go. I would love to still see some way to bring the community back together. That's my personal take. I hope that it gets there. I would welcome HasiCorp with open arms. I'm not sure necessarily if everybody in the open source space would or how that would look, but that's what I hope happens. I hope that we all see this as ridiculous. There's a big pie to bake here. The funny thing is I feel like we're all fighting over paintings. It seems like a crazy thing to say given HashiCorp's market cap. If you look at the state of CD report 2023, only 27% of companies are doing infrastructure as code.

The winner is still Ansible. There are a lot of people left to sell to. I don't know why we need to fight over the people that we have. There's a huge market out there. I feel like there could have been a better way to look at how to do this and how to move forward with it. We are where we are, and that sucks and I hope that converges at some point in time. We've made great progress in the meantime. We've got a great adoption. We've got a day at KubeCon, and Open TofuDay. It's all very exciting, but it's a little bittersweet at the same time.

Painful situation, but it is remarkable how the community and people like you have come together to lead the charge on this. Kudos for that.

It was funny, we were at Reinvent and Spacelift was five booths down from us. I was wearing a Massdriver shirt and one of their employees was wearing a Spacelift shirt and we were talking. Somebody comes by and looks at us like a random person. They're like, “Aren't you guys competitors?” We're like, “Yes, but we were friends too. There's nothing wrong with that.” It's good to discuss ideas and we're doing things very differently. We have very different target audiences we're trying to sell to.

When the Aliens come, humanity unites

Notable Tool

Everybody can be as welcoming and forgiving as the IAC community. I appreciate having you on the show. I do want to ask two last questions, both very short. What's a tool or service that you've seen recently that you're excited about?

I saw a very cool demo for a database company called TigerBeetle, and it's for financial accounting. If you think about banks and payment companies that have to handle double ledger accounting, there's a problem with issues with consistency, and potential like durability. What can happen if you have a failure mode and you update one account but not the other? Banks build a lot of custom logic into their databases to have this accounting logic. The thought with TigerBeetle is to have these abstractions natively in the database and, on top of that, be 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.

Closing Words

I have heard of Zig. I have not used it. I've seen a terminal application that was written in it. I have heard it a couple of times. Last question. Where can people find you online?

You can find me on Twitter, @ColtonDempsey. I would encourage founders to reach out. We invest primarily at the series A stage and later in B2B Tech companies. We have some services that we provide to our portfolio to put that out there. We help a lot with go-to-market. We have a ten-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 is Zig, we helped them land one of their largest customers and have booked millions of dollars for them and numerous other companies. I would encourage you to get in touch.

Thank you so much for coming on the show. I hope to have you back sometime soon.

Thanks.

‍

Important Links

• Next47
• Logz.io
• Platform Engineering On Kubernetes
• Cypress.io
• @ColtonDempsey - Twitter