HashiCorp Exploring Potential Sale
reuters.com
reuters.com
Based upon some research into numbers...
They'll absorb the talent. Expand IBMs offering of Vault-ish product while basically reselling Vault as a line item addition to their existing line items.
Less pain for IBM from license drama and the selling of open source Vault with an IBM tweak to a MUCH larger user base with zero sales expense.
IBM gets all Vault talent Hashi gets massive market without sales
Hashi is $800MM revenue because of 80% sales and marketing.
Definitely IBM, maybe Nutanix, possibly Broadcom. Hell, maybe even Cisco.
Could have Cisco as well! They are a lot more engaged in transforming themselves and doing a lot of M&A
I hoped that I could move from vault to openbao , but it looks like that is not the case.
I can understand the removal of secrets engines and stuff but the storage plugins should’ve been kept at least for the first few releases and than dropped a few of them while giving people a way to migrate them to supported options.
I have a few improvements I'd have liked to have see upstream, but couldn't land due to the vast storage plugin base. You're left writing to the lowest common denominator of 20 storage engines which isn't maintainable when HashiCorp only supports Raft and Consul.
Take paginated lists which I've proposed as a PR. If your backend engine of choice doesn't support efficient pagination aligning with the designated semantics, you're stuck implementing it from scratch. Now do that with transactional storage, which is another upstream requested feature... And so forth.
Additionally, the current contributor base is too small to support much more. Personally, I'd like to see Postgres as the only external storage engine. But I don't presently feel we have enough maintainers to justify multiple storage engines. Raft is easiest to support as it is what upstream is actively developing. It also eases migration for upstream-aligned users.
My 2c. But happy to take suggestions and contributions!
Edit to add: ideally I'd have liked to add an external storage plugin interface, but this would be a bit of a perf hit over native support and wouldn't be a stable target (as I'd like to see some of these things land).
Especially if raft is the only storage option.
And don’t get me wrong you can do that stuff. You do the work, so you guys can do whatever you like.
A fork need not necessarily be 1:1, bug for bug, compatible.
We discussed this here: https://github.com/orgs/openbao/discussions/55 and here: https://github.com/orgs/openbao/discussions/64 -- you're welcome to give feedback there and contribute to the success of the project. :-)
But as noted here: https://developer.hashicorp.com/vault/docs/configuration/sto... -- upstream only supports the Raft backend. The other backends may have issues and don't see many commits as upstream has not delegated maintenance to external community members. Frequently, commentators (both employees and community members) suggest moving away from custom storage backends to Raft.
A storage migration only impacts one small category of users -- the operator -- but remains transparent to the consumers of secrets (whether humans or applications). This only occurs once. Yes, it requires planning. Yes, it is a lot of work to execute successfully. But it is also an approach upstream uses e.g., in FIPS 140-2 migrations: https://developer.hashicorp.com/vault/docs/enterprise/fips/f... -- as we get time, we'd like to make this type of cross-instance migration more automated if we can.
But our goal is to remain API compatible, so the vast majority of use cases require no changes to operate with the forked code. And we wish to remain as drop-in compatible with consumers using Raft as we can. So yes, I think OpenBao can still be called a fork of Vault. And IMO, even a 1:1 bug compatible fork is still a separate product, and that isn't necessarily a bad thing. :-)
OpenTofu has much the same approach, where they don't guarantee a 1:1 drop-in, bug-for-bug fork of upstream, but instead gives themselves some room to make changes for the best of their community: https://opentofu.org/docs/language/v1-compatibility-promises...
I think that every project needs to find their own balance, and this is what the OpenBao community has chosen. :-)
My 2c, views my own. But feel free to contact me via email if you have additional technical concerns to discuss.
https://developer.hashicorp.com/vault/tutorials/raft/raft-mi...
I've personally used the Raft storage backend in production for some years and can assure you it is rock solid.
I also invite anybody using OpenTofu (or considering it) to join our Slack[0], it's quite active there. It's also a great place to influence the shape of new OpenTofu features.
Now 1.7 is coming out soon as well, and this week we have OpenTofu Day at KubeCon happening :)
To answer some of your points:
There's no point in forking the providers, as they're still open-source, you're just fetching them from our registry - registry.opentofu.org.
Core docs are generally the same as Terraform docs, but we're still missing the registry UI to explore provider docs (and are currently working on a design for that).
There's also the migration guide you could take a look at[1].
[0]: https://github.com/opentofu/registry/issues/new?assignees=&l...
Was there any pain in preserving existing state files and large amounts of existing infrastructure (and terraform repos) when migrating to OpenTofu?
It seems like irrevocable benefits enumerated in corporate bylaws + predecided public-friendly liquidation procedure (i.e. source code / copyright / trademark release) would help fight profit maximization at the expense of product quality.
HashiCorp's financials don't look terrible, so I'm assuming this sale is more about individual holders cashing out?
IMO they're a dying company. Selling is a smart move to push their existing customers a cross sale product to close the loss gap. They'll drop 15 to 30% of their staff.
They're not that far from profitability when you realize their staffing cost is high vs the yielding return per employee.
They don't look terrible now. But otherwise their recent license change and loss of technical founder have caused a bit of a shift in their user base towards open source forks. Which over time might substantially devalue their growth perspective. Any new projects would default to open source tools and not their proprietary thing.
This is also what I see when consulting on Elasticsearch and Opensearch projects. Almost all my recent clients start out with Opensearch these days because it is the open source choice and they are (mostly) in AWS just a few short years after they announced their license change. I'm pretty sure that's going to happen with things like Terraform and Opentofu as well. Anyone considering making similar moves, there's a growing amount of cases where this ends with a fork.
So, yes, this is why they are selling now. Before it turns into a fire sale. To a buyer it might be attractive to milk existing accounts for a while. A smart buyer might even reverse the license change in order to get some prospect of growth and re-absorb the community. But barring that, it's going to be the usual deal of either companies like Oracle or some hedge fund squeezing this thing dry until there's nothing left.
I wonder how we can verify this. If I look at HashiCorp's quarterly results,[1] revenue is up, and they're adding customers, but net dollar retention rate is trending down.
OpenTofu has 3k followers to HashiCorp's 6.9k on Github. The opentofu/opentofu repo has 18.8k stars to 40.9k for hashicorp/terraform. Sentiment on a recent r/TerraForm thread seems decidedly mixed.[2]
Are any of the (edit: other) forks of HashiCorp's viable yet?
[1] https://ir.hashicorp.com/financial-information/quarterly-res...
[2] https://old.reddit.com/r/Terraform/comments/19egjs3/thoughts...
It'll take 3 to 5 years for the pain to be felt and another 3 to 5 years from that point to collapse because most companies will just pay the renewal to buy time to let the rest of the space mature.
Source/bias: I see this happening all the time in the space. I gave a talk about why Terraform is dead and long live Pulumi.
Uh, what?
2023 revenue was 475.89M, gross margin was certainly good with 381.47M gross profit, but then you look at 678.76M of SG&A and then operational losses are (274.3M). Everything else is horrible: -62% operating margin, -22% return on equity, -23% return on total capital, -21% return on invested capital.
And now due to bungling their license change, there are completely open source forks of their two biggest products. Given their pretty flat revenue since the license change they haven't even been able to successfully use the license change to do a short-term squeeze out of their existing customers. They had been growing 72% revenue year over year for the prior 4 years, but they're now only up 16% over the past 4 quarters.
This is currently a value destroying business. If you take the products and the R&D team and throw away the administrative and selling costs and plug it into some much bigger corporations administrative+selling THEN it might look better (but it is more likely to wind up like F-secure ssh vs. openssh and any purchaser is going to grossly overpay -- probably it'll be the best outcome for the shareholders though)
Oracle would make it suck more.
Microsoft, Amazon, or Google would make it less portable and do they buy infrastructure projects like this?
Would Cisco maybe consider this infrastructure in all their customers stacks?
Or Facebook could buy as a vanity project to just get mindspace with developers?
My guess is on Microsoft. It fits within the GitHub MO.
With Azure they have alternatives for stuff that Hashicorp offers and what for them in Terrafor considering that ARM and Bicep exists?
A strategy that has worked well for them.
I could see Microsoft keeping things open too. So far they have done OK with GitHub and NPM.
65 points by MajimasEyepatch 1 day ago | 49 comments
We've been leaning into Terraform-based Crossplane providers recently and the out of the box experience is so much better than using terraform cloud once you get crossplane set up, I can't imagine ever going back to vanilla terraform pipelines, and certainly not paying for terraform cloud.
So, they cost about 1 developer?
I mean, yes, it is a bit expensive. On the other hand, it also shows that it is nearly impossible to have an opensource product and be profitable at the same time, especially with dev/infra tooling like this.
> So, they cost about 1 developer?
Where lol. You live in a bubble.
Not in the US, for that matter.
1M is seven figures.
Counting is hard.
HN/founder culture is a bubble though.
And the original statement was Joel's and said you have to either charge something that the lowest level manager can approve on their own OR enterprise pricing. Basically you can charge $30 or $3000 but not $300.
For the record, Hashicorp vault was 10x the cost of our fully managed Identity system for a million+ unique logins a month.
AWS Secrets Manager isn't as nice as Vault in a lot of ways, but at a starting price of $0.40/mo for 1 secret + as many clients as you'd want vs $1250/mo for a standard vault + 1 client, it's fine.
I see they have a SaaS product called Vault Secrets now and I bet that's exactly why that product exists.
I've got a github actions pipeline that stands up a kind cluster, installs cluster-api on it, uses cluster-api to stand up the control plane cluster and then copies over the cluster-api config to it along with argocd, and after that it's self-managing. We did have to do a little bit of terraform to get iam roles set up, but that's it.
Everything after that is pure argo cd, cluster-api and crossplane.
I work at something that's basically a startup incubator and we can stand up and manage the infrastructure for an entire enterprise, on either aws or azure (including stuff like SSO artifact storage and CICD pipelines), from a central control plane with just a few lines of yaml, and they can be deploying code within 30 minutes. And it's continuously reconciled, so there's no drift, and if we push out an update to something, it rolls out to everything within minutes.
planetscale - https://news.ycombinator.com/item?id=39618815
It would be better for it to be Oracle, so that the rest of the people using their system would have the impetus to move to the open source project.
Hashiternative stack:
- vault -> openbao (fork)
- terraform -> opentofu (fork)
- consul -> ?
- nomad -> slurm + something that runs/orchestrates windows jobs?
- hcl -> dhall + nix?
What is particularly worrisome when you need something lightweight and to support non containerized services...
More discussion https://news.ycombinator.com/item?id=39721381
Other tooling may be more problematic. Vault has an open source fork in the works but nowhere near production readiness AFAIK.
Personally, I lost a shitload of money on HashiCorp. I've "emotionally bought" 2 stocks in my life and Hashi is one of them. I like Mitchell and Armon very much, they're actually seriously great humans, both of them, but that's an awful reason to buy a stock. If I can break even and they sell for the IPO price I'll be very pleased, but that seems impossible heh. :)
all forks are doomed with the same destiny, business model is not sustainable with negative margin - as long as you have such a generous free tier and storage can run on S3 the price you can ask for a managed version is incredibly low.
You welcome :)