These things happen, props to Hashicorp for communicating about it.<p>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 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.<p>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.<p>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.<p>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.<p>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 <i>years</i>. There is clearly a priority problem here.
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 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 <i>hypothetical</i> 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<p>If that worked sufficiently well, I'd initially mirror every repo from <a href="https://github.com/terraform-providers" rel="nofollow">https://github.com/terraform-providers</a> into that same GitHub organization and continue that exercise. IMHO the providers suffer from bitrot a lot more than formal terraform does<p>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?
I don't see anything wrong with that.<p>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.
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.)<p>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.
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.