Great writeup. I had a similarly frustrating experience getting a minor but popular improvement submitted to VS Code (but at least it got accepted in the end!). They are both great products and I respect their development teams, but it’s extremely annoying when there’s clearly something the company doesn’t like about the PR but they refuse to elaborate or even acknowledge it.

So they changed the license because they said they weren't even getting good community contributions... and in reality they just made it impossible to get community contributions to begin with and turned everyone away.

I guess at least by closing up the license they are more honest about how they never wanted to play ball.

The answer from CraigW is in direct contradiction with his opening comment. Toxic.

Haha holy shit that response from Craig. Might as well told the poster to go fuck themselves.

I've had similar experiences with Hashicorp and small bugfix pull requests.

The "Thank you for your feedback, we appreciate it" comment in response to a full page of well constructed feedback is exactly the kind of empty corporate responses Hashicorp gives all the time now a days.

They will also note in issues that they would happily accept a PR for it. However if you look at how they deal with PR's that's a very disingenuous statement.

This is why OpenTF will be the dominant tool in the future.

Semi-related, but I reported a broken and un-maintained "partner" status provider, and Hashicorp asked for details and said they'd look into it. After a couple months I sent a follow up email with no response. It's still a partner provider.

The community provider qualifications are a joke and shows how much they care about users/the community overall.

We had a meeting recently looking over an internal PR.

I suggested that maybe the best idea was to do something else, but it was going to be more complex, but better in the long run.

After I realized how complex it was going to be, I suggested that maybe the PR implementation was the best idea for now.

This is the definition of the moral of "Don't let the perfect be the enemy of good".

I want to take these concerns seriously but I got to this and I had to LOL a bit:

> if there was anything that would receive attention for Terraform, I figured it would surely be a pull request fixing the six-year-old, number-one-most-popular feature request on the issue tracker

Working on an open source project, I see a lot of popular feature requests that don't fit into the roadmap and aren't aligned with the design of the project.

It's sometimes very difficult to tactfully explain to folks that "your idea is not aligned with the vision" but I have gotten better at it over time. It still takes a lot of emotional energy to wind yourself up and explain the vision, even after doing it before. And sometimes it falls on deaf ears. That's why we write FAQ documents. But not every FAQ belongs in the FAQ document.

Some questions shouldn't even be asked, because they betray the misunderstanding of the asker and in doing so they may prompt a new chain of even deeper misunderstandings that can only be prevented by heading off directly at the pass and not even entertaining the notion.

Now I'm absolutely not saying this issue is one of those issues in so many words or less. I'm not a keeper of the vision for Hashi. But I am saying, as far as selection algorithms go, if you wanted to pick a PR that would be likely to get merged...

Well, sure, you could do much worse than:

> a pull request fixing the six-year-old, number-one-most-popular feature request on the issue tracker

But I am saying that understanding that this PR having gone un-merged for 6 years in spite of being submitted multiple times, might be a signal that this change is not aligned with the intended direction and that it probably won't be merged...

I mean, it could go either way, but accepting that it can go either way, and that includes the possibility that it doesn't turn out the way you hoped, is kinda table stakes when you're dealing with a project that has like a zillion users. I mean, you wrote that big gnarly regex script to solve the issue, didn't you? How many of those things do you think went into production based on the number of people impacted? I'd say thousands. How would you have felt if the next release broke your fixup script but didn't actually solve the issue? (It kinda reads like that's what happened, anyway, so I mean, how does it feel?)

I'm not saying I wouldn't write a 10 paragraph diatribe like this, but I am saying I understand the terseness of the reply. The alternative is falling on one's sword and I don't expect anyone to be doing that for my benefit, and IMHO neither should anyone expect that of any OSS maintainer or anyone else.

"Thanks for the feedback, we appreciate it!" is the corporate forum response equivalent to texting someone a long blurb of grievances and them sending back "K".

Actually, in this instance, maybe it's more of "k.". They took the time to lowercase and add punctuation to that one.