These things happen, props to Hashicorp for communicating about it.
It would be easy to say that this is a failure of open-source in some way, but to do so would be unfair to the huge amount of work that companies put into tools like this, and the stewardship that they offer, both of which take a lot of time and money. If periods of low activity while teams change are the cost the community needs to pay for that, I think that's very fair.
I had a conversation with my coworkers when I worked there about being upfront with folks that we wouldn't review or accept their PR and stop leaving people hanging (this was on the TFE provider). I'm glad this was added.
I stand by my statement then and now: there is nothing worse than contributing to something open source and then have your PR completely ignored.
"It would be easy to say that this is a failure of open-source in some way"
I have seen far more commercial, closed source products go through similar staffing crunches. The difference is that the problems are hidden away behind misdirecting sales teams and so on.
I can't tell you how many times I've reached out to someone on the inside of a company to get a straight answer as to whether a product is being properly staffed and supported. Or, conversely, how many times I myself have had to decide to orphan some commercial, customer facing work to meet a goal with a higher priority.
In my experience, useful open source products are less likely to suffer from inadequate staffing than closed.
I think it's the likely reality of far more projects than just terraform, and I don't fault the project completely for reaching this state - attrition is a brutal thing.
It's distressing personally though, that it's an issue unknown to me before I read this post, and affects a product I use and champion.
I commented, committed, worked with contributors and Hashicorp employees early on in Terraform. It was so refreshing to see a project that did what I wanted, but better than the tooling I'd already written -- and that it was so actively working with the community.
Phinze was a large part of feeling like my contributions were welcomed, even just as a community member. A few months back I encountered something of Paul's, noticed his GitHub work had tapered off and found the blog posts entitled "diagnosis" and "treatment" on his blog.
I know nothing more about current events pertaining to Hashicorp or Terraform, but seeing some negativity here coupled with the experience of encountering that sad news led me to comment.
That team has made world class tooling, with the community. The people I know who work there are some of the sharpest and kindest people I've ever met. I'm willing to give them the benefit of the doubt and I hope you yourself will as well before presuming anything that leads to more negativity.
It's obviously not ideal, but perhaps there are legitimate reasons and at least they were transparent.
Props to them for being honest, but it's still not a good look for Hashicorp. Their stewardship of Terraform leaves a lot to be desired. For years now I've watched Terraform PRs just wither on the vine. You get the impression that nobody is working on the AWS provider at all. Every PR to the AWS provider that I've ever cared about has taken years to be reviewed and merged despite lots of thumbs-ups and comments from users begging for it to be merged. This has been ongoing for years. There is clearly a priority problem here.
A few years ago, there used to be community reviewers of pull requests to the AWS provider - indeed I reviewed dozens after leaving HashiCorp. My own access for this got removed in (IIRC) late 2018, and I’d assume this was across the board.
I don’t think it’s conceivable that any reasonable number of employees could satisfy the demand of maintaining the first-party provider set in the current form, without leveraging the community. However, I for one will not sign a CLA that allows proprietary relicensing, and I’d guess most people who could give meaningful reviews are in a similar boat, or already work on the provider teams.
However, I’m also not sure that there is a “priority problem” as such - most providers don’t make HashiCorp money from consumers or contributors, and employee time is better spent on products which contribute to a positive bottom line.
The Terraform Provider Registry has made it much more palatable to run a fork of any given provider than it was previously - I’d recommend doing so if you have functionality you need that hasn’t been integrated.
There's a group called cloudposse who have a huge repository of their own terraform AWS plugins. I haven't had to use their plugins yet (I've been lucky so far in having found a way to do most of what I've wanted through the official provider) but their selection is pretty comprehensive:
(Minor contributor, perhaps major issue-opener-commenter speaking)
I have a lot of respect for the team personally (as in myself), though I do recognise what you say completely too. I just think there's a lot of focus on trying to do things right, and long-term-maintainably, that it often presents with a poor outlook or like there's a lack of interest.
@apparentlymart from OP in particular - I have no idea who he is in Hashicorp hierarchy, I just recognise him from GitHub - in particular is really excellent in responding to good issues and adding information along the lines of 'yes we want this but unfortunately XYZ so we're hoping PQR is going to make this easier but first we need to ABC so yes but sorry not a priority right now' sort of thing.
I really don't see how you can look at the changelogs for the weekly releases of the AWS provider and think that nobody's working on it. If you want to see what a neglected provider looks like, spend some time with the poor Vault provider, where I have a two-year-old bug report about a reproducible crash condition without so much as a reaction emoji on it.
Oh, it's absolutely not a good look for Hashicorp because their company culture is the problem. They grew too fast and hired too many middle managers who brought in a brogrammer culture. It drove everyone with better options away (at least per friends who formerly worked on Terraform at Hashi). And from the resumes I see come across my desk it feels like they've been bleeding talent at all levels for a while.
One of these days Hashicorp is going to cash in and one of the major cloud operators will own the lingua franca of cloud provisioning. Oracle, for instance, directs the cloud users to Terraform as its de facto first class provisioning tool. It works rather well BTW.
I've been very happy with Terraform. I also have a huge investment in Cloudformation and it doesn't take long to discover that Cloudformation isn't implemented consistently across services, it's full of bugs, and unless your bug happens to impact Amazon internally you can wait years for a fix. New functionality for existing resources can also take years to materialize. Back when I had an eight figure AWS budget they would offer to let me fund a Cloudformation fix (seriously! They wanted me to pay them to fix their errors) but since moving to a smaller shop they don't even offer that.
With Terraform (and its AWS provider) I've found things are generally implemented consistently, I've not encountered any crashing bugs yet, and all of the manual steps I've had to do with the AWS CLI have Terraform equivalents.
I recall once upon a time there was a GitHub project wherein the owner would just immediately merge any PRs that were opened -- I believe it was a social experiment, and I don't recall the exact nature of the repo in order to know if that kind of thing is ludicrous here. But I do think it'd be good fun to take this lull and find out the outcome of a hypothetical github.com/open-terraform/open-terraform which just ran a github action that merged PRs that had more than a 5(10?) differential of :+1: to :-1: reactions on it. Build failures would instantly close the PR, and test failures would be exempt from auto-merge
If that worked sufficiently well, I'd initially mirror every repo from https://github.com/terraform-providers into that same GitHub organization and continue that exercise. IMHO the providers suffer from bitrot a lot more than formal terraform does
I think of that hypothesis as a "open source optimist" versus "open source pessimist:" are people who go out of their way to open PRs trying to improve the common good, or trying to drain the life out of maintainers?
The beauty of open source is you can run your project however you want: bazzar, cathedral, or something else. If people think its a bad choice, they can fork.
Surely community patches are such a good return on investment they should be pulling devs off other areas to keep someone on reviewing public prs. I've always been confused by companies that aren't over the moon to spend minimal review time to get the benefit of hours of work by free employees.
There are no free lunches, pull requests are no exception. For starters, before merging every pull request needs to be reviewed at a minimum. That by itself can oftentimes be a very time-consuming activity, especially if the changes are from someone outside the circle of regular contributors. Outside of fixes for typos and other trivialities, pull requests generally require a lot of back and forth to get to a good state — does this change make sense architecturally, does it cover edge cases, does it come with tests? Additionally, oftentimes pull requests expand the scope of what you need to maintain, whether you want to take on that permanent burden is a critical question in and of itself. The list goes on. There are many projects that do make it work, but make no mistake that this takes a considerable amount of effort.
My experience has been that the first-order ROI of community PRs is negative. PRs which do more than just fix a typo that you can just go "thanks" and merge are extremely rare. Most external PRs take more work to get into a good state than it would have been for us to fix the problem ourselves.
The main reason to accept community PRs is because it helps you get passionate users, not because they're free labor.
In my experience, getting a high quality PR that you’d want to maintain is exceedingly rare. Getting a community submission to that standard takes a lot of effort - sometimes more than if you just did it yourself.
On top of that, a lot of developers tend not to enjoy reviewing and massaging community PRs all day. They want to write code themselves, and they want it to be important code. Putting your team on review duty is a great way to make people feel like their role is low impact and unrewarding. Again, they’d rather write the code themselves.
I find it takes a lot of experience for developers to recognize the value, impact, and reach of indirect contributions like that, so it’s rare to have a team with enough people who will do a great job of reviewing, supporting, and maintaining quality community submissions. If you assign it to relatively inexperienced developers you’re likely to wind up getting a lot of things merged that shouldn’t be in a rapidly growing project that’s increasingly difficult to maintain.
It’s a hard problem to solve. But again, this is just my experience.
I would guess that the signal to noise ratio is pretty poor on community submitted patches. You'd rather just submit a bug to an employee and then get a more consistently correct solution than sift through potentially poor PRs.
It's cool that they're being open about this, but I'd be curious to know if the situation was their own doing or not? For example, how many non-hashicorp employees are maintainers? Do they allow this? (I'm actually asking-- I don't know the answer.)
Open source is great, but a single SPOF in one company is becoming too much of an healthy norm. If you love your software, set it free. And if you're worried about people^W companies taking it proprietary and not giving back, then use copyleft.
This is pretty sad as it has too much of a lost potential with the slow updates of the core. I've been waiting for dynamic providers (i.e. created via for_each, count, or dynamic), but they are not coming to Terraform anytime soon and the copypasta must go on. Some of the providers, which HashiCorp maintains are pretty behind. It used to be where people used Terraform for AWS, because CloudFormation was so behind, but nowadays it's the opposite story.
ARM is a complete joke, and Bicep compiles down to ARM.
(More details: ARM is simply a dumb script that says "do this, do that", it doesn't interact with your cloud resources in any smart way. As one example: You can download a template for an Azure SQL instance from the Azure portal. That template will then randomly fail to execute, because it contains two "configuration" child resources of Azure SQL, which ARM will try to deploy in paralell, but oh, they touch the same parent sources, so they crash with an error...
Then try to add depends_on in order to have it, perhaps, not fail.
Or how about the Azure SQL feature where, if you block Azure SQL to only AD logins, you'd have to declare an administrator password on first ARM run (resource creation), then remove it on subsequent ARM runs (resource update) because having it is then prevented...
These aren't minor issue or glitches; it's symptomatic of a system that's just built in the wrong way from ground up. ARM isn't a stateless description of your resources, it's an awkward scripting language (although since the APIs it interacts with are idempotent the difference isn't obvious at first).
How Microsoft could decide to have Bicep compile to ARM is beyond me -- Azure has some good features (refer to resources by name rather than allocated ID) that could greatly simplify the approach that Terraform/Pulumi takes if they only targeted Azure -- why didn't Microsoft do that instead, give us Terraform/Pulumi for Azure without having to keep a statefile (especially a statefile with secrets in it).
So Terraform manages to become the recommended DevOps tool for most cloud providers and now they won't even accept PRs to improve and add features from the community? I think there are greater issues here, first that we centralized around so few major providers instead of improving tooling to scale to any hosting provider and 2 that we let hosting providers create so much abstraction that each one requires an entirely different provider API. Clouds should be as simple as renting VMs or dedicated servers from hosting providers and having an image that automatically brings everything up for you.
> So Terraform manages to become the recommended DevOps tool for most cloud providers
It's not the recommended devops tool for any cloud provider.
> and now they won't even accept PRs to improve and add features from the community?
Random people writing code doesn't make that code valuable or of any sound quality. They have employees whose jobs it is to improve and add features to their software.
> Clouds should be as
Clouds are and should be exactly as simple or complex as their customers request. Clouds should not be built around opinionated forum posts.
[+] [-] danpalmer|4 years ago|reply
It would be easy to say that this is a failure of open-source in some way, but to do so would be unfair to the huge amount of work that companies put into tools like this, and the stewardship that they offer, both of which take a lot of time and money. If periods of low activity while teams change are the cost the community needs to pay for that, I think that's very fair.
[+] [-] leetrout|4 years ago|reply
I stand by my statement then and now: there is nothing worse than contributing to something open source and then have your PR completely ignored.
[+] [-] throwaway09223|4 years ago|reply
I have seen far more commercial, closed source products go through similar staffing crunches. The difference is that the problems are hidden away behind misdirecting sales teams and so on.
I can't tell you how many times I've reached out to someone on the inside of a company to get a straight answer as to whether a product is being properly staffed and supported. Or, conversely, how many times I myself have had to decide to orphan some commercial, customer facing work to meet a goal with a higher priority.
In my experience, useful open source products are less likely to suffer from inadequate staffing than closed.
[+] [-] mpd|4 years ago|reply
It's distressing personally though, that it's an issue unknown to me before I read this post, and affects a product I use and champion.
[+] [-] benatkin|4 years ago|reply
Perhaps this is apples and oranges, but I'm most interested in open source projects that are governed by a foundation.
[+] [-] terrathrowaway|4 years ago|reply
Phinze was a large part of feeling like my contributions were welcomed, even just as a community member. A few months back I encountered something of Paul's, noticed his GitHub work had tapered off and found the blog posts entitled "diagnosis" and "treatment" on his blog.
I know nothing more about current events pertaining to Hashicorp or Terraform, but seeing some negativity here coupled with the experience of encountering that sad news led me to comment.
That team has made world class tooling, with the community. The people I know who work there are some of the sharpest and kindest people I've ever met. I'm willing to give them the benefit of the doubt and I hope you yourself will as well before presuming anything that leads to more negativity.
It's obviously not ideal, but perhaps there are legitimate reasons and at least they were transparent.
[+] [-] electroly|4 years ago|reply
[+] [-] jen20|4 years ago|reply
I don’t think it’s conceivable that any reasonable number of employees could satisfy the demand of maintaining the first-party provider set in the current form, without leveraging the community. However, I for one will not sign a CLA that allows proprietary relicensing, and I’d guess most people who could give meaningful reviews are in a similar boat, or already work on the provider teams.
However, I’m also not sure that there is a “priority problem” as such - most providers don’t make HashiCorp money from consumers or contributors, and employee time is better spent on products which contribute to a positive bottom line.
The Terraform Provider Registry has made it much more palatable to run a fork of any given provider than it was previously - I’d recommend doing so if you have functionality you need that hasn’t been integrated.
[+] [-] beaconstudios|4 years ago|reply
https://registry.terraform.io/search/modules?namespace=cloud...
https://github.com/orgs/cloudposse/repositories?q=aws+terraf...
[+] [-] OJFord|4 years ago|reply
I have a lot of respect for the team personally (as in myself), though I do recognise what you say completely too. I just think there's a lot of focus on trying to do things right, and long-term-maintainably, that it often presents with a poor outlook or like there's a lack of interest.
@apparentlymart from OP in particular - I have no idea who he is in Hashicorp hierarchy, I just recognise him from GitHub - in particular is really excellent in responding to good issues and adding information along the lines of 'yes we want this but unfortunately XYZ so we're hoping PQR is going to make this easier but first we need to ABC so yes but sorry not a priority right now' sort of thing.
[+] [-] BurritoAlPastor|4 years ago|reply
[+] [-] wayoutthere|4 years ago|reply
[+] [-] sneak|4 years ago|reply
[+] [-] topspin|4 years ago|reply
[+] [-] zxcvbn4038|4 years ago|reply
With Terraform (and its AWS provider) I've found things are generally implemented consistently, I've not encountered any crashing bugs yet, and all of the manual steps I've had to do with the AWS CLI have Terraform equivalents.
[+] [-] bostonsre|4 years ago|reply
[+] [-] mdaniel|4 years ago|reply
If that worked sufficiently well, I'd initially mirror every repo from https://github.com/terraform-providers into that same GitHub organization and continue that exercise. IMHO the providers suffer from bitrot a lot more than formal terraform does
I think of that hypothesis as a "open source optimist" versus "open source pessimist:" are people who go out of their way to open PRs trying to improve the common good, or trying to drain the life out of maintainers?
[+] [-] kubanczyk|4 years ago|reply
Pieter Hintjens "Why Optimistic Merging Works Better" (2015) http://hintjens.com/blog:106
[+] [-] bpodgursky|4 years ago|reply
[+] [-] bawolff|4 years ago|reply
The beauty of open source is you can run your project however you want: bazzar, cathedral, or something else. If people think its a bad choice, they can fork.
[+] [-] braddeicide|4 years ago|reply
[+] [-] Etheryte|4 years ago|reply
[+] [-] plorkyeran|4 years ago|reply
The main reason to accept community PRs is because it helps you get passionate users, not because they're free labor.
[+] [-] steve_adams_86|4 years ago|reply
On top of that, a lot of developers tend not to enjoy reviewing and massaging community PRs all day. They want to write code themselves, and they want it to be important code. Putting your team on review duty is a great way to make people feel like their role is low impact and unrewarding. Again, they’d rather write the code themselves.
I find it takes a lot of experience for developers to recognize the value, impact, and reach of indirect contributions like that, so it’s rare to have a team with enough people who will do a great job of reviewing, supporting, and maintaining quality community submissions. If you assign it to relatively inexperienced developers you’re likely to wind up getting a lot of things merged that shouldn’t be in a rapidly growing project that’s increasingly difficult to maintain.
It’s a hard problem to solve. But again, this is just my experience.
[+] [-] devoutsalsa|4 years ago|reply
[+] [-] void_mint|4 years ago|reply
[+] [-] OJFord|4 years ago|reply
[+] [-] purpleidea|4 years ago|reply
Open source is great, but a single SPOF in one company is becoming too much of an healthy norm. If you love your software, set it free. And if you're worried about people^W companies taking it proprietary and not giving back, then use copyleft.
[+] [-] nikolay|4 years ago|reply
[+] [-] unknown|4 years ago|reply
[deleted]
[+] [-] shadycuz|4 years ago|reply
[+] [-] mrtweetyhack|4 years ago|reply
[deleted]
[+] [-] Aeolun|4 years ago|reply
[+] [-] awinter-py|4 years ago|reply
[+] [-] lloydatkinson|4 years ago|reply
[+] [-] dagss|4 years ago|reply
(More details: ARM is simply a dumb script that says "do this, do that", it doesn't interact with your cloud resources in any smart way. As one example: You can download a template for an Azure SQL instance from the Azure portal. That template will then randomly fail to execute, because it contains two "configuration" child resources of Azure SQL, which ARM will try to deploy in paralell, but oh, they touch the same parent sources, so they crash with an error...
Then try to add depends_on in order to have it, perhaps, not fail.
Or how about the Azure SQL feature where, if you block Azure SQL to only AD logins, you'd have to declare an administrator password on first ARM run (resource creation), then remove it on subsequent ARM runs (resource update) because having it is then prevented...
These aren't minor issue or glitches; it's symptomatic of a system that's just built in the wrong way from ground up. ARM isn't a stateless description of your resources, it's an awkward scripting language (although since the APIs it interacts with are idempotent the difference isn't obvious at first).
How Microsoft could decide to have Bicep compile to ARM is beyond me -- Azure has some good features (refer to resources by name rather than allocated ID) that could greatly simplify the approach that Terraform/Pulumi takes if they only targeted Azure -- why didn't Microsoft do that instead, give us Terraform/Pulumi for Azure without having to keep a statefile (especially a statefile with secrets in it).
[+] [-] encryptluks2|4 years ago|reply
[+] [-] void_mint|4 years ago|reply
It's not the recommended devops tool for any cloud provider.
> and now they won't even accept PRs to improve and add features from the community?
Random people writing code doesn't make that code valuable or of any sound quality. They have employees whose jobs it is to improve and add features to their software.
> Clouds should be as
Clouds are and should be exactly as simple or complex as their customers request. Clouds should not be built around opinionated forum posts.