>We tried many times to contribute upstream fixes to Terraform providers, but HashiCorp would never accept them. So we've had to maintain forks. They lost their OSS DNA a long time ago, and this move just puts the final nail in the coffin.
OSS doesn't mean that you have to accept any PRs that showed up in your repo, nor does it mean that you have to let a competitor steer your project simply because you're building in the open. Without further elaboration, what you're calling "upstream fixes" may have been considered "working as intended" at HashiCorp. As I'm sure you're well aware, every contribution has to be maintained and each increasing contribution comes with an additional burden. Responsible maintainers on large scale OSS projects must be selective about the code they let in.
You have to acknowledge that all these OSS projects officially backed by a corporation don't want you to contribute certain features that are part of their enterprise offering. As soon as there's an "enterprise" tier, contributions are not only based on their merit, but also evaluated as a threat to their business model.
Sometimes it's not even obvious for external contributors, but there may be some small overlap with other paid features that are part of their product roadmap.
If a project on Github only has maintainers from the corporate side, you can be certain that they will ultimately drive the product for their own interest solely.
We should always pay close attention to the governance model of projects we depend on or that we wish to contribute to.
Of course, but the major difference is that if I don't like the maintainers, I can create a fork, build a community around it and happily run it in production. Imagine where nodejs would be right now if they had been BSL licensed in the iojs times.
Sure, OSS doesn't mean you have to take all PRs, but if your claim is that others are just taking your code and not giving anything back, one of the alleged leeches showing up to talk about how they've tried to give back is very much pertinent.
Having been on the upstream side of things, it's very he-said-she-said. HashiCorp code could be a PITA to contribute to, or maybe this particular provider was bad at contributing.
The only way to know for sure is to dive into the merged and unmerged PRs and see how they were handled.
I'm not affiliated in any way with one of their competitors. Co-workers and I sent bug fix PR's to for example Vault. The last couple of years almost none of them were merged. These were small bug fixes, not (large) feature additions.
I’m sorry, but no. These are usually simple bugs like “forgot to a set a field during refresh”. They almost always correspond to one or more Terraform issues too, often ones that have been open for 4-5 years or have been “marked as stale” by some infuriating bot.
Then don't complain about people not contributing to your projects. You reserve the right to reject my PR, and I reserve the right not to contribute any more.
I don't know if it is the case for the fixes pulumi sent, but for PRs I've made to terraform providers it can take a very long time for them to be looked at, and even longer to get merged. And I think it is mostly from nor having enough resources to approve and merge PRs. Although that could possibly be fixed by inviting developers outside the company to help with approval and merging, especially for providers.
That's a lot of assumptions you're making here. From my little use of terraform it did had a bunch of issues that were purely a bug and laying unfixed for a long time.
For example, the widely used 'count' anti-pattern is still present, and no actions have been taken up to this day. This topic has persisted for 5 years. 5 YEARS!!! That's what triggered my decision to migrate to Pulumi.
isn't the simpler explanation that they would in effect lose the ability to relicense the project and therefore lose control of their baby?
To not lose control you need to have people assign copyright which is generally a headache. I've only heard of the FSF doing that .. (not sure why this hasn't been streamlined electronically somehow)
OSS doesn't mean that you have to accept any PRs that showed up in your repo, nor does it mean that you have to let a competitor steer your project simply because you're building in the open. Without further elaboration, what you're calling "upstream fixes" may have been considered "working as intended" at HashiCorp. As I'm sure you're well aware, every contribution has to be maintained and each increasing contribution comes with an additional burden. Responsible maintainers on large scale OSS projects must be selective about the code they let in.