HashiCorp Terraform and Community Contributions | Hacker News Reader

HashiCorp Terraform and Community Contributions

hashicorp.com

83 pointsairhangerf1541 comments

From this blog post: "The Terraform product organization has grown in kind, and is now composed of more than 100 people and a dozen teams, ..."

From their job hiring page:

88 open engineering positions, (https://www.hashicorp.com/jobs/engineering)

That's a significant deficit compared to their current org size.

It's only dwarfed by their open sales positions:

102 (https://www.hashicorp.com/jobs/sales, good sales people are hard to come by!)

But yeah, they're swamped, you don't want your few resources to get overwhelmed and burned out before fixing your staffing issues. It's understandable.

They have quite a few interesting products; so good to see things are going well for them.

Terraform is probably one of their more well known ones. But I also use packer occasionally and have used vagrant before docker became a thing. I was looking into Nomad a few weeks ago because I'm kind of dreading the maze of complexity and misdirection that is Kubernetes and it's documentation. Absolutely nothing seems simple with that. Nomad's pitch seems to be being vastly less of a beast to deal with. I'm in need of something like that that can handle our quite modest and reasonable requirements without side-lining me for the next 2-3 months. Hashicorp excels in simplifying the complex and convoluted mess that other/bigger companies come up with.

Their stance with open pull requests is a bit puzzling though. I guess they are a victim of their own success in terms of the number of PRs. But it maybe also indicates that they are struggling with being an OSS company. Working with the community instead of acting as a gateway for it is key. I'm guessing they have a lack of outside contributors that could help reviewing PRs. Having and curating such outside contributors would also be a great way to fill those 88 open engineering positions. Recruiting from your own OSS community is an important perk of being an OSS company.

Not all of those open positions are for Terraform, which alone has "more than 100 people".

You're right, I stand corrected!

Was there really confusion? I thought it was pretty clear they were just saying "we're overwhelmed right now, please hold on while we catch up".

But I guess people be people.

I think they needed to be more explicit for their commercial customers. Our c-suite is gonna prefer a blog post to a git diff!

There actually was a blog post!

Here's the commit that has the information: https://github.com/hashicorp/terraform/commit/6562466c32a875...

And if you follow the link in the comment there, that brings you to the blog post from about a week ago: https://www.hashicorp.com/blog/terraform-community-contribut...

Regardless, not having the manpower or not prioritizing community contributions is an interesting situation that hasn't been seen much in the past before. I wonder why it is that they can't find the necessary manpower not to have this problem. Is it a matter of priorities? Or of the job market? Or employee related expenses?

Maintaining open source is highly taxing, because you're likely doing that alongside your regular work, which is a really piss-poor corporate strategy but common nonetheless.

Unfortunately, the days of mostly rational Github users are over.

The last year or two I've noticed a pretty sharp uptick of demanding, unreasonable people berating you for taking too much time or otherwise being rude or offensive if they don't get their way.

This is probably a contributing factor.

I thought it was pretty clear too

Is it the end of the world if your PR is not accepted immediately? If you fix is really important, you are not waiting for your PR to get accepted and make it into a release before running it in production.

Maybe there is a startup idea here, in making it easier to manage and patch third party dependencies, like how of the big tech companies do?

CTA: send me a message if you like build systems and packages managers and Git and want to manage a billion forks. Worst case scenario we start a support group.

> Maybe there is a startup idea here, in making it easier to manage and patch third party dependencies, like how of the big tech companies do?

It's most often not as simple as "patch third party dependencies". The Linux kernel is quite infamous for having so many refactorings and reworkings that you can count the amount of proprietary drivers for current (!) kernel versions on one hand. IIRC, the only one viable at the moment is NVIDIA's weird shim, with the longest other holdout Paragon NTFS having gone for open-sourcing a couple weeks ago.

Everyone else (cough Android or general embedded PSPs/BSPs) is stuck with fossilized kernel versions. Take apart any cheap router firmware and you'll likely see a 2.6.x kernel and even older u-boot versions since no one wants to do the work necessary to port over all the custom cruft to a modern version, and no one wants to commit stuff upstream as the Linux kernel maintainers won't even think about accepting the shoddy quality that is common in the embedded space, not to mention people being afraid of violating NDAs.

> the only one viable at the moment is NVIDIA's weird shim

Yeah they recently gave up on supporting older hardware on new kernels, now one of my machines is stuck on Linux 5.4 LTS.

(Nouveau can't do Audio over HDMI on that hardware.)

In a way, it is - I take on an operational overhead of rebuilding an upstream tool, periodically merging my changes with master and rebuilding, etc.

This isn't something I budgeted time for, or something I even roadmapped for, which means the build process is going to be a 30-minute kludge and will likely incur greater-than-normal ongoing overhead.

I use Nix for that all of the time.

My workflow is usually like this: * upstream has a bug. * find and fix the bug, send a PR. * update the Nix code to build with either the PR branch as the source, or the PR diff as a patch.

What's missing is a good tool to scan for new releases and remove the override. Other than that it works really well.

It's much nicer to run a terraform provider from a branch than having to publish a temporary fork to registry.terraform.io

I spent my last week wasting hours on end how i could ship a fork of the aws provider to support some resources that upstream refuses to add (ec2 classic link). Wasted hours on end convincing terraform not to redownload or to not have hash collisions with their built in way to do this so i indeed ended up using nix to patch and ship the terraform provider in the end! Very nice experience.

My edits are purely additive so I have it as a patch file that I simply apply to the nix package definition. So far it has applied cleanly on many different terraform versions I use in the wild.

There was a show-stopping bug in the AWS provider that I was watching for about 13 months before a community patch got merged. Over 200 watchers and +1’s galore. We had to spin up separate tooling and write glue scripts to cover the gap. We didn’t really consider forking the AWS provider, but that may have big a quick fix in exchange for ongoing maintenance merges and confusion.

Slightly OT, but I'm rooting for Hashicorp to succeed in the commercial market. They created some of the foundational infrastructure tools that I use quite often as a developer (vault, consul, terraform, vagrant etc.). I hope that if I do need to switch to another tool for the purposes that hashitools currently serve, then they provide some phenomenal new features.

Previously discussed 7 days ago https://news.ycombinator.com/item?id=28425849

This link provides the context for the blog. Or, maybe better put, the blog is essentially a response to that discussion.

100+ employees for 1200 customers. So every customer needs to pay at least 0.1 developers on average to break even. Doesn't look sustainable. So we should expect to see more changes of terms over time. Like we have seen it from others with free offers, e.g. Qt in the past, Redis or gitlab somewhat more recently. Not saying that those have become bad, just no longer as free (either speech or beer) as they once started.

Isn't Hashicorp all B2B? So like, one of those 1200 customers could be a single government customer paying crazy amounts? I don't think this is a good metric just like "lines of code" isn't a good metric.

> 100+ employees for 1200 customers

That's only one of their products - many of the others don't have an enterprise version at all ( e.g. Packer, Vagrant, Waypoint, Boundary), so that skews your math a lot. But not every product needs to be profitable in itself, there can be loss leaders, reputation builders, integrations. IMHO the main money making products are probably Vault and in some point in the future Boundary when it grows enough (the alternatives in the space cost an arm and a leg, and are terrible in comparison).

It's been a few years since I looked into the enterprise HashiCorp offerings, but I remember there was an X seat minimum (where X was 10 I think). Larger customers will obviously have many more than 10 seat license/support agreements. The pricing was definitely "enterprise".

>100+ employees for 1200 customers. So every customer needs to pay at least 0.1 developers on average to break even. Doesn't look sustainable.

wasn't Discord computer-stuff related team even smaller?

They are cheap too! Like crazy cheap.. I expect a price increase sooner or later..

I must admit I have never looked at their pricing. We are a small company of geeks, we don't buy support.

I'm not sure what OP is referring too, because their prices for the supported services previously started in the mid six figure range for them to not ghost you.

We had a tech + commercial meeting with them like two months ago, so they could provide us pricing for a managed Vault (Hashicorp Cloud Vault), and we're still waiting for their offer.

Meanwhile, we got tired and we've deployed our own OSS Vault ¯\_(ツ)_/¯

I've used and enjoyed Vault in the past, but these days just reach for AWS / GCP secret managers.

When would you use Vault over those offerings?

I wasn't involved in the decision and can't recall everything, but I remember a couple things:

- We have A LOT of environments, so GCP Secrets pricing climbed really quickly.

- Interest in dynamic secrets

Maybe OP was being ironic?

Irony is not helpful when talking to someone who does not know the facts.

The main thing you buy are enterprise level features, not support. E.g. for Terraform that'd be Sentinel(Policy as Code), collaboration, auditing, etc. related features. Vault'd be multi-cluster active-active HA, integrations with HSMs, etc.

Though i guess someone might want to buy support only, the value proposition is limited.

> Vault'd be multi-cluster active-active HA

is there such a thing? actually there is only the replication feature the last time I looked, which effectively can be built by using s3/gcloud storage and vault without too much trouble.

That seems... Not too bad?

You can add Elasticsearch to that list too.

There was a discussion [1] on /r/DevOps about this recently and some interesting things came up. It's interesting to me that for a company who loudly proclaims 1200+ enterprise companies which I assume are paying customers, they can't allocate resources to solve this issue.

[1] https://www.reddit.com/r/devops/comments/pigzak/terraform_is...

> Although we have many teams, some short-term staffing changes impacted our ability to review changes to Terraform Core in a timely manner.

Anyone have insight into those short term staffing changes?

According to LinkedIn Insights they have ~500 engineers with a median tenure of 1.5 years, and posted 3,800 engineering jobs in Q2.

I'm a job seeker and (without knowing how LinkedIn does the counting) I think that 3800 might be a useless number.

There are lots of companies that have ~10 open positions and repost those once or twice a week without change.

Boom, now your 10 open positions are multiplied by 25. (12 weeks to a quarter * twice a week)

I hope someday someone will just build HashiNode which is a cloud infrastructure that only uses tools from HashiCorp.

Reply on news.ycombinator.com