Software Company HashiCorp Is Weighing a Potential Sale
bloomberg.com
bloomberg.com
The reason selling devtools is hard is there's generally no established budget to sell into. I already have budget for various things - a vendor comes to me and tries to sell their product/tool/saas I'm looking what I can move around to afford it. If yours does a better job of something I'm already paying for, then it's the easiest sell of them all. Eg why most companies have moved off of Pagerduty.
If the tool is small enough $/user I can probably afford it without too much trouble or approval - budgets have some padding and there's always some wiggle room, something to deprecate etc.
Unfortunately, Hashicorp like some other devtools companies was too proud and only wanted to sell Terraform to large Enterprise ($100k/yr). I'd have been happy to give them $/dev/mth but that was never an option. GitLab is similar. Their pricing is either free or insane with little middle ground. I pleaded with a sales rep - I'm happy to stay on the free features but give you some money for "support" but they wouldn't take my money. Utter madness of a business model to turn down money.
To justify Terraform Enterprise ($100k/yr) I would need to get new budget. This could take a year. I need to get internal buy-in which takes time but there's no way to show the business the productivity gains until I'm using it. Catch 22.
What Hashicorp should have done is a near free version. Get people comfortable with running Terraform on the cloud and out of awful CI pipelines, then upsell features as their customers naturally grow (concurrency/security/training etc).
Having had paid customers would have given Hashicorp a mechanism to be able to listen to and get feedback on how their tools were actually being used and the pain points businesses had.
Thankfully we now have OpenTofu and the likes of Spacelift et al.
What a missed opportunity.
It makes sense to turn down money if the administrative overhead of taking it will cost more. If I have to spend a couple of months negotiating a license/service agreement with your legal department and then chase your AP people for a couple months more to get my invoice paid, the the couple of $K you are willing to pay are not really worth it. And unfortunately that how things really work.
Yes, definitely. The cost to build out and maintain any middle ground solution must be unprofitable for the majority of business models.
Ultimately this creates opportunities for down-market service providers. Mid-large companies outsource support to contractors who will provide support for terraform in addition to 20 other things.
It is a process efficiency tool (a great one) but is ultimately a luxury. All companies already have some sort of process in place even if it's terrible. But as companies don't have an existing incident vendor they're already spending on, they're also having to educate customers about the business value of the product category at the same time.
However, if you tell me I can replace Pagerduty (which I'm already looking to replace as why am I paying $252/user/year for a PAGER APP!) for an incident tool + pager (even at a higher total) that's a much easier sell. The business value is in the incident response not the tool that sends me a push notification.
I suspect they'll have a lot of success with this.
There's truth to this: as with all new product categories, there's some education that needs to go along with the sale, and budget that needs to be found, that doesn't currently exist. On the whole, we haven't found this to be a large challenge so far. Most people look at our product, see a very fair exchange of value, and are happy to pay.
However, that isn't why we built On-call. We built it - along with many other reasons - because it's part of the trifecta that we think you need to do incident response well:
1. A way to alert people that something is wrong 2. A way for them to respond, resolve and learn from the incident 3. A way for them to communicate to their customers about it
We have built all of these respectively in On-call, Response and Status Pages. Consolidating all of these into one cohesive product makes obvious sense, to us at least. We'll see what the market says!
Just letting you know that many orgs use SSO that aren't at enterprise scale, the platforms are pretty affordable to obtain (depending on choice). Such a relatively simple to implement and valuable feature commanding the highest price tag and a bevy of features you really don't need acts as a gatekeeper for many of us.
Could you elaborate on what you're trying to do with SSO? To clarify, you can SSO via Slack on any of our pricing plans (which in turn often SSO's with other providers). Essentially, whatever you SSO with on Slack, will work with incident.io.
If you'd like to use SAML, you can do that too, on our Pro plan and above. The only thing offered exclusively behind our Enterprise plan is SCIM.
https://help.incident.io/en/articles/6991102-sign-in-with-sa...
> Organisation's on our enterprise plan can enable SSO using SAML to manage access to the incident.io dashboard via an Identity Provider (IdP) like Okta.
What are the positives or negatives you see when dealing with vendors (i.e. what makes you lean towards or against dealing with a vendor)? I'm trying to figure out how I can make the process as easy as possible for exactly people in your position.
1. If SSO and other basic modern security features are locked into "Enterprise" pricing tiers then the service is at the bottom of the list (see: https://sso.tax). I'd love to say instant disqualification but too many SaaS companies have it in their head that only wealthy enterprises use SSO, despite SSO platforms being widely available and some quite cheap to acquire and start using.
2. If I need to request a quote to start any kind of service to see what the product is about then I'm not likely to pursue it. Don't make me jump through hoops when I'm just trying to see if a product can fit my needs.
3. If license terms are too complex or easy to violate that's a hard pass. Infrastructure monitoring tools are a great example. The licensing is often per "device" or per monitored metric, and some vendors are very loose with their definition of "device". (Don't use LogicMonitor with k8s unless you like throwing money in the garbage can). Hard lessons learned.
4. If the only details I can find regarding how you secure your product are claims of SOC2 and ISO27001 certification then that's a very likely pass. Those controls are great to have, necessary even, but anyone who has had to work to meet those compliance objectives knows that they're much more about organization controls than they are product security. Give me an idea about how you protect data and whatnot on a security page somewhere, not an attestation that dev and prod are separate and you have logs.
On the side of the positives, outside of not hitting the negative marks, I value ease to work with, responsive and competent support, strong pre and post-sales solutions architecture and support/training (if the product is complex enough to warrant that), and supports SSO. I bring up SSO again because it's a hard requirement for SaaS purchases everywhere I go -- no SSO, no go. Social login is not a substitute and is highly undesired.
Hope this helps.
For SSO, does SAML support clear your bar?
What is mean is that by the time NewTool that fills a gap doing X really well catches up with the YZ that older tools have long experience handling, EvenNewerTool handles E better than NewTool does.
I don't have any knowledge of the specifics here, but at first guess I doubt something security-focused would be an exception to that rule.
They just used to be free and open source.
In this particular case, devops or iac or gitops was huge driver for hashicorp. It was synonymous But as market turned as cloud providers mature it is falling out of trend.
Charging per resource? Paying per json file? Per secret or managed instance?
That's silly.
Terraform Cloud could be $25 per user per month while remaining profitable but that's just a guess.
https://github.com/opentofu#why-opentofu (Terraform)
https://github.com/openbao/openbao#readme (Vault)
and I know of several attempts at Vagrant <https://github.com/hashicorp/vagrant/forks> but I don't believe one of them has caught traction yet
There are also some who have talked about an "open Nomad" but since I don't play in that space I can't speak to it
Devtools are about developer efficiency etc.
And the "all you can eat" toolbox license is just a staggeringly good deal, IMHO, which also comes with a "you can keep your license forever, just no updates" which is way different from setting subscription-based licensing money on fire when your license expires. Whoever came up with that should be applauded because it really drives down my "what about" anxiety of paying subscription money for IDEs
That's the main difference, as they had lower margins compared to Hashicorp which traditionally had most of their enfineeeing in the US.
Hashicorp has started pivoting hiring to Bulgaria, Poland, and India now for that reason.