we support our employees working on open source during their Friday projects
This is very different than hashicorps model of paying people to work on the opensource project during their working hours. Making it a core part of their job.If we are to accept that the OpenTF foundation is going to be a better maintainer of terraform we need something better than "Hack on opensource if you want to!"
Spacelift doesn't have a good track record of contributing to opensource so the current model isn't working.
Also, Jacob started OctoSQL before ever joining Spacelift so its pretty odd to use that as an example of spacelift doing OSS well. Especially since his activity on his has tanked since joining you.
The plan is for the foundation to employ dedicated engineers that we can sponsor.
Regarding open source vs closed source, I have nothing against closed source software. I think the outrage about Terraform specifically is caused by people seeing it more as an ecosystem, not a product (like Vault or Consul), and the whole thing looks like a bait-and-switch of reaping the benefits of open source (and others building a provider ecosystem) and then closing that down, once you start getting the cons of open source (healthy competition building inside of that ecosystem).
Honestly, I'm grateful for Hashicorp for the contributions they've made over all these years, and the libraries they've built. And as is the beauty of open source, in a situation like this, we can just fork, which we're doing.
In a dream scenario, HashiCorp would eventually join us working on OpenTF in the open, with the load much better distributed across companies, and the roadmap better reflecting the community's needs. I don't think, however, that it's fair to call these companies freeloaders who just now decided to contribute, as HashiCorp quite openly didn't encourage community involvement in the development process of their core open source projects.
All in all, I hope we'll do a much better job of involving the community in the core development and decision-making process (via public RFCs), while the foundation part means you don't have to trust any of the companies specifically. A healthy open-source ecosystem here is both good for the companies using it (partly due to no vendor lock-in, better competition, more innovation, lower prices), as it is for companies building products that extend tools in that ecosystem, as it is for any individuals involved. It's a win-win-win situation.
Disclaimer: Work at Spacelift, and currently temporary Technical Lead of the OpenTF Project, until it's committee-steered.
The employes can do open-source on Friday but no part of Spacelift is actually open-source?
https://github.com/spacelift-io/celplate https://github.com/spacelift-io/prometheus-exporter https://github.com/spacelift-io/spacectl https://github.com/spacelift-io/spcontext https://github.com/spacelift-io/terraform-provider-spacelift https://github.com/spacelift-io/vcs-agent
Whenever we're extending an external library, we're submitting the change upstream. Whenever there's an opportunity to sponsor a project on which we heavily rely, we do that. But yes, we don't maintain any major open source projects as a company. And neither will we with OpenTF, because our active involvement with it is only temporary - we are just helping it get off the ground. Long term we will be primarily a sponsor of a dedicated team (see our pledge), not a core maintainer.
I'm not sure what spcontext does because it has no documentation but I'm sure I could read the 10 commits to find out. The only none trivial project in the list is celplate which actually looks nice, but even there most of its complexity is in cel-spec.
> Whenever there's an opportunity to sponsor a project on which we heavily rely, we do that.
Come on, on Spacelift GitHub profile there is one project sponsored, and only since August 24!
> we don't maintain any major open source projects as a company
So you never had to handle project management of large open-source supports, community support, doing code reviews every day and handling feature requests from the community?
Yes, HashiCorp has been slow to respond to PRs and did not always commmunicate clearly, but so does many large open-source project like PostgreSQL, Python, Linux, etc. Managing a large open-source project takes more time than clicking on the merge button on GitHub. Users don't magically come fix all the bugs in the software, and develop complex new features.
HashiCorp did contribute a lot, and there is still a lot to learn from their projects, there is Raft, the autopilot, various library that are used a lot in the Go ecosystem, including go-plugin, a programming language with its specific type system and plenty more. After all, the change of license is making noises because we their tools defines part fo the DevOps world and we all use them a lot.
I wish HashiCorp would have kept using the MIT license, but using the BUSL is still miles ahead better than companies that are completely closed source.
From the outside perspective it looks like you support Free Software as in Free Beer more than in Free Speech. You are supportive when others are actually maintaining the projects for you, and you just want them to merge your contributions quickly. It is a very efficient way to externalize some of your costs, but you only step forward to actually to help manage them when your bottom line is threatened.
That's ok, it looks like you love money more than open-source ideas. That's perfectly fine but don't pretend otherwise.
Some others companies that signed the pledge have actually been maintaining open-source projects and have a leg to stand on. Spacelift loves having the high moral ground and the extra publicity.
Release the core of your product as open-source, like HashiCorp did for 9 years, and it will change my mind.
Cut the bs please, this is just a self-serving fork. You all don't give a shit about open source, you just want to keep using TF in competing services for free.