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.
IBM is backing OpenTofu and OpenBao AFAIK. They're supposedly one of the main reasons for the licensing change. Cisco was looking to buy HC years ago, I would bet they're still interested (wonder if it will be for less money...)
IBM is a good guess but it would probably be more accurate at this stage to point at anyone that missed the cloud wars and are claiming to be a “multi-cloud manager.”
Definitely IBM, maybe Nutanix, possibly Broadcom. Hell, maybe even Cisco.
As the tech lead of the OpenTofu project, I can tell you that I'm positively surprised by how quick the uptake has been so far since the stable release! We're also seeing a ton of external contributors jumping in, which has been heartwarming!
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 :)
Just started a new tiny greenfield infra project for a friend but was too cowardly to use OpenTF after I tried it and found that I needed Hashicorp providers etc, couldn’t be bothered to dig in and untangle. Gotta say, didn’t find opentf docs useful at all. But hoping things go well and one day I’ll be able to just fire things up and it’ll be frictionless.
Sorry to hear that, could you expand on the paint points? Esp. on the friction points, where it was different than just using `tofu` instead of `terraform` in your commands.
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).
Mainly because I installed it and ran it on a sample base infra - vpc and subnets - and I noted that it was still picking up Hashicorp providers, fine, but doesn’t this mean I have to run through a large codebase and start switching every provider out? Essentially I wasn’t sure what to do next. Should I stick with my standard terraform setup or figure out shifting to OpenTF and risk getting hit with something not available? Wasn’t something I could figure out in advance, if that makes sense? So was safest to stick with TF.
You should just keep using hashicorp providers - there's no changes to your codebase required, generally, as long as you don't specify provider sources in long form (as in, you should specify the source as `hashicorp/aws`, not as `registry.terraform.io/hashicorp/aws`). All providers should be available in our registry, and if you're missing any, just submit it[0]. Though as I said, all should be available.
There's also the migration guide you could take a look at[1].
Happy to answer technical questions about OpenBao as people have, though some might be best directed at the Technical Steering Committee, which I do not represent. :-)
Thank you for the RFE! Looking at the X-Forwarded-For handling might be good, I wasn't able to add tests for that easily, though maybe the existing test could be used as a template if you get time. I think we depend on nginx or Caddy elsewhere, but the pkiext tests might also serve as a good reference. :-)
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).
Well with these changes before the first version I would not consider openbao a fork of vault. More like a different product.
Yeah some of these proposed changes are nice. But they shouldn’t be done in the first release if you wanted to take over vault customers.
I will probably never migrate to openbao.
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.
I think there's many counter examples to this: Jenkins & Hudson, Illumos & Solaris, LibreSSL & OpenSSL & BoringSSL, LibreOffice & OpenOffice, Spongy Castle & Bouncy Castle, and Webkit & KHTML to name a few.
A fork need not necessarily be 1:1, bug for bug, compatible.
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.
We had some discussions about this before removing all storage plugins except Raft, In-Memory and File storage as cipherboy pointed out in the sibling comment. If you're currently not using Raft, this should not stop you from adopting OpenBao if you first migrate to the Raft storage backend. Hashicorp has a tutorial on this which you can follow:
Amazing - we actually had a secrets PoC for our org paused recently, and Vault is one of the options. But honestly this looks like it could solve a few things in our team right now.
Checkout Akeyless as a better alternative to vault. All of the enterprise features of vault, for less than half the cost and delivered as a SaaS service. So no deployment, no maintenance, and no scaling required.
Out of curiosity, and afaik HashiCorp is not one, how do sales of US-style benefit corporations [0] go?
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?
> HashiCorp's financials don't look terrible, so I'm assuming this sale is more about individual holders cashing out?
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.
> a shift in their user base towards open source forks
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?
Revenue is up because a lot of their contracts will be over a 3-5 year term and they'll recognize the revenue each year of the contract.
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.
What is your definition of viable? I know large F500 orgs using OpenTofu. A lot of orgs that offer services to other orgs within an umbrella org or within a holding company noped out of terraform due to the licensing change.
OpenTofu does seem to have reached a stable, usable release. I meant to ask whether any of the other forks are viable. OpenBao, e.g., doesn't seem there yet.
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)
They're making progress. Their last quarter shows them decreasing their loss in net income and at the same time increasing their revenue.
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.
Makes sense, since with another product company you could collapse the sales orgs and drastically decrease the marketing+sales costs without impacting revenue.
Is there more context than the single tweet? Twitter doesn't display threads to non-users anymore and Nitter is dead, so I can't see if the follow up mentioned ever happened.
I think so too, I think of Cloudflare as an infrastructure kind of company which is why they came to mind. It would be a buyout to keep the industry from seeing crucial tooling go down in flames when the wrong company acquires them. Microsoft might be a solid one, though no telling if this is even on their radar.
Actually given how Java has evolved since Java 7, MaximeVM evolution into GraalVM, J/Rockit integration into OpenJDK, versus the mess on Android side, I am glad Google didn't move a finger to acquire Sun after torpedoed it.
Is there a good open source secret management abstraction that works for both containers and serverless? I’d love to use one library to connect to AWS SM and Vault and whatever we replace Vault with.
I always thought Hashi's technologies would lose their lustres soon. My previous company used to use Terraform and Nomad. They are like Graphite 10 years ago: darling of the open source community, good for small companies, but eventually becoming a productivity nightmare. There are just so many bizarre decisions and the accidental complexity of Hashi's family bucket is just through the roof. The one that I hate most is its embedding of Jinja template to inject system configurations. I mean why in the world would someone separate the service configuration from a service itself and force engineers to take care of service configurations in a separate places while learning so many irrelevant details: Terraform, Jinja, string escaping, embedded language, integration with the deployment environment, and the official docs do not help that much. They seem contain everything, but it's just so hard to connect the dots.
Hashicorp gave away basically everything valuable they had, and charges extortionate prices for the few features they've paywalled. Only way they're going to survive is by becoming a feature of some bigger cloud offering.
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.
The high price of Hashicorp doomed them in the end. I don’t know what their financials looked like internally but the quotes we got from sales reps got them laughed out of the room.
I had the same experience some years ago. When we told them they were out of their minds and they wouldn't budge on price, the sales rep came back after a few months pleading to get us back to the table because we would have been a gigantic sale and a foothold into the other orgs of the large company I worked for at the time. We told them we already had a different solution in flight because of their original failure to negotiate.
Thirded. Some of their products looked useful so we talked to a sales person, and it was exorbitant. Not "oof, that's a little more than I'd budgeted for", but "LOL does that include equity?" The upside is that it pushed us to check out the alternatives.
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 worked in the HashiCorp sales org for a couple of years -- Vault's weird identity-based pricing model was by far the biggest issue with getting prospects to buy Enterprise. It's great if you're a large multinational with highly-consolidated infrastructure and application identity, but if you're operating on a smaller scale than that or are not highly-centralized it's totally infeasible. The sales segment that focused on the smallest deals was rarely able to sell Vault Enterprise at all -- both because the pricing was so high and because the pricing model itself didn't scale in a way prospects felt they could understand and budget predictably for as they grew. We heard "we love the features, but there's no way we can afford that price" all the time. Various people beat the drum on this internally for literally years right from the initial switch to the current pricing model, but other than minor "client counting" tweaks, nothing ever changed.
I see they have a SaaS product called Vault Secrets now and I bet that's exactly why that product exists.
Okay but how much does that really say? All HN/startup advice says that when you sell to enterprises you have to charge enterprise prices. Meanwhile techies are notoriously for preferring to spend a month's worth of salary building an FTP server to replace Dropbox with.
Hashicorp's prices are not what i'd consider to be 'enterprise prices'. When we looked at buying "enterprise vault" a few years ago it was six figures a year for a relatively small install. It was basically "we don't want your business" pricing.
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.
> All HN/startup advice says that when you sell to enterprises you have to charge enterprise prices.
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.
I remember seeing quotes for Hashicorp Vault Enterprise, the price for Vault dwarfed the entire cloud bill of the company. And yet the cloud bill (through the marketplace) included other third-parties that were being paid an "enterprise price".
I can tell you that I worked at a large company that was moving pieces like identity and secrets management to SaaS or open source solutions years after rolling their own and failing to keep up. I'm well versed in built vs buy vs opensource.
For the record, Hashicorp vault was 10x the cost of our fully managed Identity system for a million+ unique logins a month.
Was there still people buying Vault at that price? From my perspective it looks like Hashicorp has been overplaying its hand there, but maybe it worked somehow!?
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.
For Terraform there should be none, since you have drop-in alternatives for both the base product and the commercial platform (disclosure: I’m involved in OpenTofu and Spacelift, respectively).
Other tooling may be more problematic. Vault has an open source fork in the works but nowhere near production readiness AFAIK.
He moved to being an IC a few years ago, so Mitchell's departure might've been in progress for a while. And he seems to be having fun writing a terminal emulator in zig.
As soon as it's formally announced, It moves to the price they agreed to sell for, and then you can either sell them on the open market for that price, or hold them and convert them to shares of the company acquiring. There may be a tax benefit to you doing one or the other, so I'd consult a tax advisor.
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. :)
Here is a free tip to fix terraform business model (no MBA required):
- Terraform is one of the most valuable tools for IaC - it's all free and it shouldn't - it is not a consumer product, it is not running ads and 99% of the users are business users with money.
- Keep Terraform SDK free and open source, close source plugins, charge per resource.
- Invest much more into Core and plugins.
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.
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.