I think I may have been too subtle with the point about security. Hashicorp’s providers are more trusted because they come from the tool vendor, they are using

I think I may have been too subtle with the point about security. Hashicorp’s providers are more trusted because they come from the tool vendor, they are using them in a commercial product and running them on their own hardware as part of terraform cloud. They are all but “implicitly” trusted since you trust Hashicorp code with secrets in order to have Terraform do its job. Yes you can architect a lot of safety layers around credentials and treat Terraform as untrusted, but it’s a sliding scale. There is an incentive for project management on the AWS, GCE, Azure, Kubernetes, and the other Hashicorp maintained providers, to not prioritise work that reduces the number of potentially chargeable resources. The first one I thought of was the time provider. It’s a virtual module like the null provider and all it does is put a logical delay into the dependency chain to handle edge cases… it would be all too easy to start assuming that customers use this module more in order to handle functionality that would require more code in other modules. They probably have metrics on resource and module use via terraform cloud (I don’t have the privacy policy and ToS memorised) How strong the incentive is and if it’s ever really more than a subconscious influence on Hashicorp’s code the code that customers are more likely to use than 3rd party providers… is basically impossible to tell, but the inventive is absolutely there because Hashicorp’s pricing changes have made “number of resources in use by a terraform cloud customers” into a metric that the management will be looking at… the business development, the parts of the company that are responsible for making the money happen, will be measuring this number because it’s obviously important to them now… And once you begin to measure something as a metric the incentive to game the metrics begins.