5 ms·

My experience contributing to HashiCorp open-source projects

62 points by raxod502 3y ago

klardotsh 3y ago
"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.
- upon_drumhead 3y ago
  I take it more of a “F off” than a “k.”. Doesn’t give me a great impression of the company
- deleted 3y ago
  [deleted]
- yjftsjthsd-h 3y ago
  No, it's stronger than that because of the context; by default "Thanks for the feedback, we appreciate it!" == "K", but when it's a response to complaints about your interactions with the community it's more like a middle finger.
bb88 3y ago
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".
Plasmoid 3y ago
This is why OpenTF will be the dominant tool in the future.
- benterix 3y ago
  Well, the problem with OpenTF is that they will have to stay compatible with TF at all levels. If they decide to enhance the product, things could quickly become messy. There are areas where they won't be able to innovate at all (e.g. the state file format) and some where OpenTF extensions could be possible if marked as such (in a similar way as the GNU project did).
  - upon_drumhead 3y ago
    Well, they decided to fork now https://opentf.org/announcement https://opentf.org/announcement
atbpaca 3y ago
The answer from CraigW is in direct contradiction with his opening comment. Toxic.
richwater 3y ago
Haha holy shit that response from Craig. Might as well told the poster to go fuck themselves.
zeroimpl 3y ago
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.
jordigh 3y ago
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.
- NBJack 3y ago
  Big brain move. Gives them a nice easy public exit from what was nothing more than virtue signaling. I agree with the license change being honest. They clearly didn't give a shit.
yebyen 3y ago
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.
- NBJack 3y ago
  What you wrote here disagreeing with the author is probably more than what Hashicorp has collectively communicated in the last 5 years. At least you cared to do so. It's cool if they don't agree with something being trivial. It's fine if they disagree with the implementation. But, wow, the lack of real communication and the canned responses are basically a middle finger to anyone even attempting to help them. Shit, at least Linus took the time to actually explain his reasoning when he berated people.
rendaw 3y ago
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.
jsiepkes 3y ago
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.

62 points by raxod502 3y ago

"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.

upon_drumhead 3y ago
I take it more of a “F off” than a “k.”. Doesn’t give me a great impression of the company
deleted 3y ago
[deleted]
yjftsjthsd-h 3y ago
No, it's stronger than that because of the context; by default "Thanks for the feedback, we appreciate it!" == "K", but when it's a response to complaints about your interactions with the community it's more like a middle finger.

bb88 3y ago

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".

Plasmoid 3y ago

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

benterix 3y ago
Well, the problem with OpenTF is that they will have to stay compatible with TF at all levels. If they decide to enhance the product, things could quickly become messy. There are areas where they won't be able to innovate at all (e.g. the state file format) and some where OpenTF extensions could be possible if marked as such (in a similar way as the GNU project did).
- upon_drumhead 3y ago
  Well, they decided to fork now https://opentf.org/announcement https://opentf.org/announcement

atbpaca 3y ago

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

richwater 3y ago

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

zeroimpl 3y ago

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.

jordigh 3y ago

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.

NBJack 3y ago
Big brain move. Gives them a nice easy public exit from what was nothing more than virtue signaling. I agree with the license change being honest. They clearly didn't give a shit.

yebyen 3y ago

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.

NBJack 3y ago
What you wrote here disagreeing with the author is probably more than what Hashicorp has collectively communicated in the last 5 years. At least you cared to do so. It's cool if they don't agree with something being trivial. It's fine if they disagree with the implementation. But, wow, the lack of real communication and the canned responses are basically a middle finger to anyone even attempting to help them. Shit, at least Linus took the time to actually explain his reasoning when he berated people.

rendaw 3y ago

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.

jsiepkes 3y ago

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.