terraform-provider-airbyte VS terraform-provider-stateful

In my mind the analagous behaviour would be if the golang checksum database added in license terms that stated "you need to abide by a BSL to use data from this service". What that actually would mean is so nebulous that it feels threatening.

[0] Source: https://registry.terraform.io/v1/providers/airbytehq/airbyte...

[1] Source: https://github.com/airbytehq/terraform-provider-airbyte/tree... gzipped : ~300 resources, ~300 data sources

(NB: in airbyte's case the TF Provider was generated from a ~150Kb OpenAPI spec via https://speakeasyapi.dev: implying docs could be compressed even more)

It's... effort consuming, but is doable and more like a 1-time effort.

A while ago I built an alternative plugin manager for Terraform (https://github.com/paraterraform/para) and explored the idea of distributed indices (where you just host a file in the repo as seen in https://github.com/ashald/terraform-provider-stateful/blob/m...).

So at the end of the day, it's either about the effort to inventory the current registry and find sources that are available, or do this on an ongoing as-needed basis (eg something like para would allow an index to be hosted in a github repo managed with PRs).