>>> That's why I think that any open source project that gets too popular will have to have a cloud vendor strategy,
This.
In fact sadly one of the marks of a successful OSS project is ability to pay yourself, and even perhaps commercial success. In Linus' day it was enough to have a whip round online to buy a faster Pentium machine, but these days it's a foundation and cloud offering.
I was at a conference last year and talked to someone who said that the investors he knew were shying away from investing in open source software companies because anything that was successful would just be copied and operationalized by AWS/GCP/Azure.
I hope that isn't the case, but we'll see. Maybe the answer is niche operations that are too small or domain specific to be noticed by the big folks.
There are lots of niche operations, but they tend to build their domain-specific work on top of these cloud providers.
AWS's fork of Elasticsearch (ES) is a good example of the operationalization you talk about. If I was building a niche eDiscovery solution for the compliance market on top of ES I'm likely to want to offer that on AWS or another cloud provider at some point. If they offer their managed version of it, then I don't have to support it.
You can make obvious arguments like special extensions, or all compliance customers don't use the public cloud, but ultimately many users are going in that direction. Any type of general-purpose tool like ES is ripe for the picking by any cloud provider when it gets popular.
The only options I see are licensing it in a way that's prohibitive for adoption by cloud providers, or engaging them early to become their subcontracted maintainer for the product on their cloud so that you remain in the value chain.
Ultimately, it's not the type of business that should be taking VC money because the upside is, so limited when you have the typical successful outcome. The only way to get to an outcome that VCs might like is to use the income stream, or talent acquisition, from the open source product to pivot into something that isn't as limited. Doing that is really hard.
I'm pretty sure there's room for smaller verticals these days. It's been demonstrated many times that if you have the best front-end to the problem space, and you add some services on top, everything under it can be totally commodified but you'll still get customers.
From there the strategy would depend on whether you want to stay small or not: To get bigger, you'd start going deeper into the open stack to scale things up and provide a wider array of services. If you stay small, your organization will necessarily be more focused on interfaces and compatibility while maintaining that top-end UX. In both instances there are plays for open source, but with different characters; the big company will tend to code-dump an enterprise toolchain, the small one will primarily be a contributor to a foundation project or open some of their internal interfaces.
> It's been demonstrated many times that if you have the best front-end to the problem space, and you add some services on top, everything under it can be totally commodified but you'll still get customers.
This.
In fact sadly one of the marks of a successful OSS project is ability to pay yourself, and even perhaps commercial success. In Linus' day it was enough to have a whip round online to buy a faster Pentium machine, but these days it's a foundation and cloud offering.