Absolutely this. A series of commits dealing with different aspects (e.g. whitespace fix, minor related bug fix, necessary refactor, then the feature) is ideal.
For a start, it's easy to review, and easier to disect if something breaks.
When messy git history is provided (i.e. a history of the developer fixing their own code that they missed), squashing can be a reasonable fallback. But it's never the best option, IMHO.
Hmm, I don't think separating independent units of work into separate pull requests is "overhead", I think it is good practice.
And the benefit is that instead of humans spending time deciding whether or not to squash commits in some branch before merging, or being asked to do so by a maintainer, a computer just does it automatically. It's a lot like automatic code formatting; it's a big win to have tools do things automatically, rather than requiring human time and judgement and communication.
> Hmm, I don't think separating independent units of work into separate pull requests is "overhead", I think it is good practice.
They're not independent, they're related. Having multiple levels of "namespace" - repo -> PR -> commit - makes things easier to navigate, just like having multiple levels of folder in your filesystem.
> And the benefit is that instead of humans spending time deciding whether or not to squash commits in some branch before merging, or being asked to do so by a maintainer, a computer just does it automatically.
If you demand that each PR must be a single commit you just force the human to make that decision earlier and more manually.
Agree to disagree on the first point. I think if something is enough of an atomic unit to be a good commit in the trunk, then it is a good candidate to be its own pull request, which can be discussed independently.
> If you demand that each PR must be a single commit you just force the human to make that decision earlier and more manually.
How so? I think you may be misunderstanding the suggestion... The pattern is that people can have whatever commits they want on their own branch, but when that branch gets merged into the trunk, all those commits are automatically squashed into a single one. I don't see how that is "forc[ing] the human to make that decision earlier and more manually".
> The pattern is that people can have whatever commits they want on their own branch, but when that branch gets merged into the trunk, all those commits are automatically squashed into a single one. I don't see how that is "forc[ing] the human to make that decision earlier and more manually".
Right, so that means people have to decide whether something's going to be a separate commit immediately when they're working on it, and start a new branch if so. Or they could mess around splitting their branch into smaller branches at the end when they're ready to PR, but that's fiddlier than rebasing to split/merge commits.
The up-front process is identical: create a branch to work on something. The development process is identical: create whatever little commits are useful to you personally, don't worry about whether they'll end up in main. At some point you can decide whether you have ended up with another independent unit of work, and point a new branch at the separate unit, without needing to squash any of the commits you have (branches are cheap).
I don't know what you mean by making PRs being "fiddler than rebasing to split/merge commits". What is the fiddliness you see?
> At some point you can decide whether you have ended up with another independent unit of work, and point a new branch at the separate unit, without needing to squash any of the commits you have (branches are cheap).
That's a horrible way to work because when you squash a branch it breaks the history of any other branch that's based on it. So you'd have to do a fiddly rebase when you merge your first branch in.
> I don't know what you mean by making PRs being "fiddler than rebasing to split/merge commits". What is the fiddliness you see?
Imagine I've done a bunch of work in a branch, and then decide I want the contents of that branch to become three commits on master. With your workflow I have to split my branch into three branches, retroactively. That's fiddlier than just turning the commits on my branch into three commits.
> With your workflow I have to split my branch into three branches, retroactively. That's fiddlier than just turning the commits on my branch into three commits.
It really isn't. Branches are just as cheap as commits. It's super easy to create three branches pointing at three arbitrary commits.
I don't think I ever saw one. The director of the product I worked on (comprising a few hundred people spread across a few offices and countries) sat a few "pods" over from me for awhile. He did have priority use of a 1:1 meeting room though.
I couldn't agree more, but this is a discipline that is rare in my experience. With GitHub lacking fast forward merges, I've struggled to articulate why it's important.
I just re-checked github.com, and the only options are merge commit, squash commit and rebase commit. Rebase comes the closest, but none of these are fast-forward merges. Worst of all: you can't disable the green button if you don't like any of them.
EDIT: and just to point out. If you have 1 PR with 19 commits that break the test suite. The last commit fixing it doesn't matter as you will be hitting one of those 19 commits at some point during a bisect.
>Could you expand? You choose a sensible commit message on squash, while the PR's commits become fairly irrelevant at that point.
It's optional. Nothing prevents you from just adopting whatever the PR said initially. Turning it on doesn't automatically make it better.
> you will be hitting one of those 19 commits at some point during a bisect
But not if you merge the PR as a squash-merge, which turns those 19 "development" commits into a single "permanent" commit.
Using PRs as the unit of development, with all intra-PR work squashed into a single atomic test-passing commit, is a well functioning process that many teams use.
This would be true if and only if GitHub allowed you to collaboratively review and modify the squashed commit message _as part of the approval_ process, a feature which I have been requesting from them ever since "squash and merge" became an option.
The teams I've worked on generally use a "copy the PR description into the commit message", which works well. And if there are oversights, the PR number is in the commit ID which is a link to the larger context.
What I’m asking for is explicitly a GitHub feature - code review around the message that will be applied when you click the “squash and merge” button in GitHub.
> EDIT: and just to point out. If you have 1 PR with 19 commits that break the test suite. The last commit fixing it doesn't matter as you will be hitting one of those 19 commits at some point during a bisect.
Then I'll `git bisect --first-parent`, and either isolate it to your merge, or mark to merge OK. `git bisect` doesn't have to walk your branch.
The other 19 commits are also not the current state of the code, and if the test suite is all currently passing, and nobody is using a version of the code in production from the other 19 commits, then none of that matters anyway. So I'm still confused why anyone should care.
The test suite did its job by alerting you to make changes before merging your work to the trunk branch, I don't see this as anything anybody could possibly pick a fight over.
And to be clear, I still use mainline terraform because I never really wanted a wrapper around terraform. It's just silly to me to take issue with the terraform wrappers for this non-issue.
Imagine you are a terraform provider developer that is working on making sure their code is working with `opentf`.
Lets imagine opentf does an initial `v1.0.0` release of their code and your provider doesn't work. But you know it worked with the last FOSS release of `terraform`.
What do you do?
You find the common ancestor between these two projects, lets say 8a085b427b74ce3829500a59508b77465f1bbef0 (as that is the last commit `opentf` has from `terraform`).
You will now run `git bisect` on the history between `8a085b427b74ce3829500a59508b77465f1bbef0` and `v1.0.0`.
You will do a binary search on the 100-200 commits here, and everytime the source fails to build, or the test suite doesn't pass for whatever reason, you are making it much harder for the downstream provider to figure out why their code doesn't work.
You can easily just try do this today and see what happens. Does the current untidy git history cause you any problems?
My bias here is that I don't tend to use commits the same way you do. I would look through each PR that had been merged between now and then. Specifically looking for PRs that look like they might change the thing that I'm having issues with. Untidy git histories are so common that it's not really worth counting on, to me. A PR is a body of work that I find actually seems to matter. I wouldn't reach the same hangup you had. On the flipside, when people overload their PRs with 3-4+ deliverable items, that tends to irk me.
Bisecting can be a good strategy. But you need to look through 100 commits. I need to look through 5-8 PR diffs. Everyone thinks they have the best strategy because they get results with it. Anyway, I'll try your strategy if mine is failing.
You should play around with git bisect - seems like you've not used it much. It's a life changer when it comes to finding what broke.
Don't forget, a project like Terraform is too big. No one person can know how the whole system works. Trying to look through PRs as a means of debugging is a fools errand. You have to take on a different mindset when working on these large codebases.
Don't sweat much over it yet. Default / point people to something like merge into PRs, squash PRs when bringing them to main branches, and keep everyone follow https://www.conventionalcommits.org/en/v1.0.0/ for commits untill you find your way / more edge cases crop up and you're set.
Give them some time to figure out what merge strategy they want to enforce - it was probably overlooked as a repository setting and they probably clicked Merge instead of Squash and Merge by accident.
Your comments here should go in the textbook for "why people often prefer to work in private for awhile while zeroing in on their processes for a new endeavor".
There will always be someone who will gleefully jump down your throat for imperfections.
But on balance it's probably better to work in public anyway and ignore the haters (while also continuously improving processes).
Most people don't spend this much time on PR before releasing their fork though.
If they had worked on this publicly from the start I'm sure a lot of the current PRs would have generally been of better quality as they could get community input earlier.
Oh I see now! Your comments about the merits of the pull requests are just bad faith; you're actually making this totally different point about the project that has absolutely nothing to do with squashing or commit messages. Thanks for clearing that up.
It was definitely not bad faith. They're pointing out that OpenTF isn't bothering to hold to quality standards that Hashicorp had for Terraform before the fork and they aren't trying to raise beyond those standards to reach the levels common in higher quality community projects like Linux, Kubernetes, LibreOffice, and OBS Studio.
A project being run by professional developers who have a lot of experience working with the Terraform code should be capable of doing this.
If your problem with a project is that it advertised itself to its target audience prior to releasing a repository, then a good faith comment would say something like, "My problem with this project is that they have spent more time writing manifestos and blog posts and social media comments so far than they have spent developing strong processes and working on publishing a repository for the project".
But if that's your real problem with a project, then a bad faith comment might look like "This is a bad pull request, how could you let it get merged?". The reason that is in bad faith is that it says nothing about your actual problem with the project, it's just a totally random swipe that you don't even actually care about. If there turns out to be a good answer to the question, like "Oh you're right, we forgot to require squashing pull requests when merging, I've fixed it now!", then instead of recognizing that your complaint has been spoken to, you are likely to simply find further things to criticize, because the first thing wasn't actually your real criticism, it was just a smokescreen.
Now, if you are making this other, better, point that the OpenTF project should have more mature software development practices, at least equivalent to and ideally exceeding the better-known project they have forked from, then yep, I agree with that criticism and do not think it is necessarily being made in bad faith.
However, I would be significantly more sympathetic to that criticism if it were a comment on an article entitled "OpenTF project celebrates one full year since its conception" rather than one entitled "OpenTF repository is now public".
The project is brand new, and they clearly rushed to get out a public repository because of other haters who were giving them crap about taking too long to publish the repository, and their processes clearly haven't matured yet. (Or I dunno, maybe it was even many of the same haters, because again, this is the tendency with people who criticize in bad faith, to just move on to the next random criticism that they don't actually care about.)
So if we get to a year from now and their processes remain immature, then yep, I'm right there with you on your criticism. But I think it's crazy (and, sorry to keep repeating myself: likely in bad faith) to make this criticism of such a new project. There is absolutely no indication that the developers running the project are incapable of having mature processes for the project, from the tiny amount of data available from the tiny amount of time that has elapsed since they announced the project.
I think you're confusing X/Y and faith here. You're making the basic assumption that the comment itself is in bad faith because it's not formulated the way you expect. That doesn't stand up to scrutiny because everyone evaluates and expresses things differently, and many folks would consider that a bad faith evaluation of feedback (whether it is positive or negative in reality wouldn't matter).
I think there's a stronger argument of an X/Y problem in the statement, since they talk about what they see as output vs what they expect to see instead.
And frankly, I am disappointed too, as these people working on this project should have spent all that time understanding how Hashicorp actually handled the codebase and ensured that their own engineers followed the same quality level for development. They're all definitely capable of it, so they should actually do it.
Otherwise it's going to be hard to trust the fork to succeed.
There's nothing more I can say on the bad-faithness thing that I didn't already say in my last comment. I think the comment speaks for itself, and I don't agree that it is "X/Y", or itself a bad faith evaluation.
(I do think you may be missing that I was responding to the entire sequence of comments, which started with just a drive-by swipe at pull request merging process, not just the later comments expressing disappointment with the perceived emphasis on marketing over engineering.)
I think your direct expression of disappointment is totally reasonable. I personally think it's also super premature to be disappointed, but it's your prerogative.
But I just think the other commenter's approach to expressing this criticism was way off base.
Looks like a good PR to me. It accomplishes something useful, and the fine-grained commits are very helpful for automated bisect (and frankly, if you're not doing automated bisect then what are you even bothering with a VCS for).
It would be trivial to at least continue the standards set by the terraform project. Now there are commits messing with `internal/backend` that breaks tests with the commit message "more".
Someone is going to hit this with `git bisect` and it wont be their lucky day.
I know that you're commenting in bad faith and if it weren't for commit messages, you'd have found some other reason to spew hate. But I know that your comment will be read by people who don't come with an agenda, so I'll give it a try.
> Do you not see how it’s problematic that you have these oversights?
I do. We do. Note that none of the OpenTF folks downplayed it. We acknowledged. We will fix the process. We will move on. In my book, that's how mature people and organizations react. Mistakes are unavoidable, important is how you deal with them.
The alternative I suppose would be to collectively fall on our swords because some committers from one company had a different style of working, and the tech lead from another company took his way of working for granted. I don't think we can continue living with this shame.
> What reason would anyone ever trust your organization over Hashicorp?
NONE! Don't trust us - watch us.
Point out mistakes, too. Be a part of it, help us get better.
> focused on PR (...) actual substance
Like commits not squashed? What other substance are you missing from a spontaneously formed group that's been working together for a little over two weeks?
Be nice! They're just taking this on, and not already having sorted out whether they'll work with "all PR commits must have good messages and pass tests" vs "all PRs must be squashed" is the kind of minor issue you see with teams starting this sort of thing.
Ah yes, not having a compatible license that won't cause you legal troubles isn't why people pay for software its... checks notes the commit messages used in a PR.
I think that's exactly it, a 'straightforward rename' shouldn't consist of 20 commits with crap messages including 'missed that' (+ merge commit).
But tonnes of people don't care about git hygiene or using tools well in general, GP's in for an exhausting time caring about it much in projects they're not in control of.
I mean, I guess? Some people like small commits, and most of them looked reasonable to me (renaming one thing at a time); criticizing commit style seems like bike-shedding, anyways.
Agree. I guess it’s different styles but when reviewing code I’ll look at the whole PR and almost never go commit by commit. If you expect OSS contributors to have perfect git hygiene, your project will never get contributors. If a breaking change is introduced, revert the offending PR as a whole.
Commit messages like "more", "rollback", "missed that" are not really what you expect from such an organization, so, yeah, that should've been squashed with a descriptive and useful commit message. My repos look like this but… I'm not a professional developer.
> were too lazy or hostile to negotiate a deal with Hashicorp
And how do you know about any dealings any of us did or didn't have with them, now or in the past? Are you privy to any of that?
> lack of competency in execution, planning, strategy, and software engineering
One of my old bosses taught me a lesson. Any time you criticize something, you spend your capital. This capital is earned by building value, by being constructive. If you have any constructive feedback, now is the time to speak up or remain silent forever.
I think this whole process has been beautiful. Hashicorp was well aware that licenses are tagged to versions of projects rather than the "project" itself, and used that to its advantage as a business to start maximizing profits to its enterprise offerings.
The community was well aware that once you tag a license to a version, you can't undo that. And they're well aware that they can fork from that license forwards and build their own "new" project, version by version, that stays open source.
This is going to be fascinating to see play out, and I think a case study in software licensing going forwards...can't wait to see how OpenTF does down the road.
There is no distinction between licenses tagged to "versions of projects" (whatever that means) vs the project itself. Hashicorp was well within their rights to change the license moving forward, and you or I or anyone else are within their rights to continue using an older version and fork it – which is exactly what happened here.
The fact that you can continue to use an older version and fork it supports your parent's statement that the license is tied to a specific version. The new license only affects newer versions and can't be retroactively applied.
Yeah, but that's a weird way to put it. Meaningless truism.
Copyrights are never not tied to a "version." There is no concept of "version."
Copyright applies to a bunch of data. You have a copyright on a song. If you create a second song you can call it a new "version" of the original or not, none of this matters for copyright.
> You have a copyright on a song. If you create a second song you can call it a new "version" of the original or not, none of this matters for copyright.
Well, some of it matters:
"If you pay close attention, you can hear it: there’s a new lushness in the opening banjo twangs, and an extra beat when she sings the lyric “Just say yes.” But the difference between the 2008 version of Taylor Swift’s “Love Story,” which helped propel Swift to pop stardom, and the 2021 rerelease of that same song is pretty subtle..."
"Her hope, it seems, is to override those archival works with these new versions..."
"What’s truly different about Swift’s “new” work is the intention behind it, and developments that have brought her to the place to own it."
"In an interview with CBS’s Tracy Smith, Swift said that she planned to sidestep Braun by rerecording everything in the songbook that he now owns, meaning all the songs she had released prior to her August 2019 album Lover."
"When Swift switched over to Republic Records in the fall of 2018, she negotiated to own the master rights to all the music she creates going forward."
"By rerecording her old songbook with Republic Records, she will own the copyright to all of the new recordings."
TL;DR: Arguably, re-recording and re-publishing is just a new pull request and commit, but that gets you a new copyright.
But technically, it's the performance that has these financial rights, so perhaps this is more like a clean-room re-implementation so you can re-license the binary. :-)
This is how all copyright and licensing works. There's nothing unique about Terraform. You can't go back and retroactively take away a permission that you granted someone.
I'm guessing the issue is that it's obviously "inspired" by "Terraform" which shorthand is TF.
My second guess is that using "Open" together with something that implies "Terraform" is also a problem, as Hashicorp might sue them for defamation, as that name would imply that Terraform is not "Open". I'm not personally against that, I wouldn't consider Terraform "Open" anymore, but I'm not sure a court would see it the same way.
The criteria for trademarks is not defamation, but confusion.
Given a product TerraForm, known also as TF, how likely is it that a consumer would be confused into thinking "OpenTF" is made by the same people who make TF?
That's the bar to clear. In the past, some trademark owners have been fairly lax, allowing unrelated "Open" versions of their software to be established. The classic case was "SUN OpenOffice", but I suspect they got away with it because "office" was not a wordmark - the trademark was for "Microsoft Office", which is very different. In a lot of cases, the "Open" versions emerged once the software was not sold anymore, so it was impossible to be confused.
In this case, though, the software is still sold and likely carries trademarks and wordmarks. Unless OpenTF's pockets are deep enough for some serious lawyerin', it will be easier to rebrand.
I'm not seeing any trademark registrations by Hashicorp on TF, nor any mentions of TF in any of the Terraform marketing pages. Not to say that Hashicorp couldn't try to be difficult anyway, but it feels like at this point doing this would just raise the visibility of the OpenTF project.
Tensorflow isn't a direct competitor. My understanding (and I am not a lawyer) is that enforcing trademarks is based around whether or not a consumer could reasonably confuse the product with the trademark owners. A user wouldn't reasonably confuse tensorflow with terraform, but might confuse openTF with terraform
The first is, please provide a standalone registry package for both modules and providers - the only I'm aware of is Artifactory, and I don't really feel like running another big repository software in a Nexus shop.
The second is related: please allow for easier forking of provider modules. The current workflow of either building locally and distributing binaries with collaborators that are manually copied sucks or waiting for upstream to accept PRs, particularly if upstream wants CLAs signed.
> The first is, please provide a standalone registry package for both modules and providers - the only I'm aware of is Artifactory, and I don't really feel like running another big repository software in a Nexus shop.
Could you expand on this? Do you mean you'd like a self-contained binary to run a private provider/modules registry? If that's the case, then there are some open source projects for that, and we've done a proof of concept of an approach in which you can distribute providers via OCI registries like DockerHub or the GitHub Container Registry[0] as those are actually perfect for the use-case.
This PoC will be followed by a public RFC soon.
> The second is related: please allow for easier forking of provider modules. The current workflow of either building locally and distributing binaries with collaborators that are manually copied sucks or waiting for upstream to accept PRs, particularly if upstream wants CLAs signed.
> Do you mean you'd like a self-contained binary to run a private provider/modules registry?
Yes, indeed. But it seems the problem more was something with Google's algorithm, I swear a month ago this here [1] wasn't on the first page when searching for "terraform private provider registry".
Btw, unless you mean to say '... But I'm commenting here in a personal capacity, not necessarily representative of the views/policy of the organisation', that's a claim, not something you're disclaiming.
It's sort of a disclosure (which is almost an antonym) but you're not acknowledging a potential bias, you're saying this is why you should listen to me/care to reply, so even that doesn't really fit IMO.
I'm just skimming, but it looks like the docs are fantastic. I've spent some time with terraform internals, and this seems like a significant improvement for a dev looking to work with this codebase. Gives a great overview to get started. well done!
I'm not sure which docs you mean specifically, but most of the docs are fairly unchanged (other than trademark stuff) from the original repo, so if any of the docs improved, then to give credit where credit's due, the kudos should go to the Terraform Core devs.
Disclaimer: Work at Spacelift, and currently temporary Technical Lead of the OpenTF Project, until it's committee-steered.
Nice, on a total side tangent, the logo looks fairly awkward in dark blue against a dark background. The white stroke also isn't bold enough so it looks very pixelated when also combined with a dark background.
Definitely bikeshedding, but it also kind of looks like the TensorFlow logo and for a second I thought there was a group breaking the project free from Google.
The logo on the Github page could do with an improvement on dark backgrounds - specifically, the dark text has a light outline (alpha bleed?) which aliases.
Unlikely to get accepted by CNCF (I would think). There's big movement by the cloud vendors to create IAC-first APIs. Once those APIs gain traction and the industry as a whole signals that that's the direction to go, we'll see a standard emerge, and a new general purpose tool get built that will replace Terraform and all of its providers. That's a few years away however, assuming that effort doesn't die down.
OpenTF core member from Gruntwork here. All great products require focus, and right now our sole focus for OpenTF is creating the best possible truly open source and community-driven successor to legacy Terraform.
I'd personally love to see an open source path forward on other products that Hashicorp re-licensed like Packer, but those will need to be a separate project and initiative.
I think it is reasonable for a company to start OSS and then change its license. But it indeed feels like a rugpull for all the contributors.
That is why OpenTF is on its way to CNCF. To ensure it stays OSS forever.
There is a difference between "true OSS" like K8s, OPA, etc and "temporary OSS" (backed by a company) like what Terraform used to be, Pulumi, GitLab ,etc. Those can be changed in the future.
When developers chose OSS, they should consider if it is a CNCF OSS or a vendor backed OSS. What Hashi did is an important example.
(disclaimer - env0 founder here, co-lead the OpenTF initiative)
> Pulumi is true open source, uses the Apache 2.0 license, and does not and never will depend on BSL-licensed software in any way, HashiCorp owned or otherwise.
Disclaimer: the following is my own opinion as an engineer at Pulumi.
Pulumi is true open source, with a relationship similar to git and the many SaaS services that layer on top of git to provide meaningful value.
To contrast with our competitor, Pulumi relies on open source languages and protocols. We could not, even if we wanted to, change the Python license. Nor could we change our protocols without breaking our users and our growing ecosystem.
That's the value of building on open protocols and standard languages.
I suspect this project is going to consist of a very loud minority of folks. I'm working for a very large company right now and they've been mandating us to move all of our TF code to Terraform Cloud for the last year, and I've not heard a peep about this licensing issue. I'm assuming they're going full steam ahead and don't care about this issue. As long as the TF Cloud service is easy to use, still a SaaS so it's TF's problem vs the companies, and they allow a robust login / access pattern via OAuth / SAML, all is well.
OpenTF core member here. If you're comfortable opting into an ecosystem where most of the key products are offered and supported by a single vendor (in this case, Hashicorp), then yes, there are no licensing issues to worry about and basically nothing needs to change for now.
But our philosophy at OpenTF is that users would rather participate in an open ecosystem where multiple vendors compete for their business. If you're not happy with one vendor, you can easily switch to another; competition works to make all vendors better.
When we look back at this comment a year from now, I'll wonder how your company will feel about the responsiveness and new features they're getting from Terraform Cloud when the primary incentive to stay is not because you think it's the best product available, but because switching costs are so painful.
Honestly, I think when it comes to the large companies I've worked for, they care more than anything else revolves around "support". 15+ years ago the my previous company was all Sun Microsystems based, owned millions of dollars in 880s, 6800s and even an E10K. They said Linux was off limits because they couldn't blame/call anyone when they needed "support", even when Redhat was already around.
Eventually they saw the writing on the wall and moved to Linux systems and replaced all of the hardware, and have an enterprise RHEL subscription that we could call when needed.
I think the story is going to be the same with the current company, mainly "who can we blame if there is a security incident, or get me a Hashicorp person on the phone if we have some kind of Terraform related production issue." Having this in place seems to matter more than everything else honestly.
I'm not sure companies care much about support for "simple" tools like Terraform, at least the non-hosted version. Operating systems have lots of dark corners, but if your Terraform deployment isn't working then the problem is likely your code.
I have come around to the idea that it's good to firmly discourage this kind of late-in-the-game license change.
But I also think that, on net, this episode will lead to fewer businesses choosing the open source model for their software, from the start. It just seems like playing business on hard mode to try to build an open source or source available product, when you can just build a SaaS and charge for it. I think this is really bad (I have a strong preference to not be stuck with opaque SaaSes for most things), and I'm not sure what incentive there is to try to find new business models, when you risk becoming public enemy number one amongst a big chunk of your potential customer base.
Well that's the core problem - what is the product here. Terraform Cloud and Terraform Enterprise are products for sure. They're not open source, though. Is Terraform a product? Well, it doesn't do anything on its own, it requires plugins ("providers") for anything it does. Plugins are developed by or at least with third parties. It's a gatekeeper of an ecosystem that at this point is a common good.
Whether the ecosystem would exist without the permissive license and external contributions - really hard to say. But if your main play is to foster the growth of an ecosystem and then turn it into a product exclusive to your business, then I guess you should look for alternatives.
AWS probably doesn't care much for it being closed either. But the benefit of being open is that folks can investigate, report and fix bugs. For example, at Spacelift we found a fascinating corner case where an RDS DB could be dropped if the call to get its details resulted in a transient API error. We wouldn't be able to do it if the code wasn't open. I also believe that the AWS provider in particular gets quite a bit of attention from the community outside Hashi and AWS.
All the providers are still MPL licensed, however. Maybe I'm missing something, but what part of the license change for Terraform core prevents someone from investigating and fixing a bug in the AWS provider in a similar manner going forward?
Even Terraform core remains source available and so 'community' users can still take a look at the source code and identify/report/fix errors.
If a company isn't ready to compete against someone/something that is using the code the company has written and published as FOSS, then yes, please do not use FOSS licenses for your "Open Source" product.
One would think that the companies thought this through before publishing FOSS code, but seemingly there is a lot that didn't do that.
This is essentially where I have landed. I think these companies should have just used a license like BSL from the get-go, and I hope that the next generation of product companies will learn that lesson.
But unfortunately I think the lesson they will take from this instead is "we should just build a SaaS with no source availability because that's way easier and source-available just makes people mad anyway".
> I think these companies should have just used a license like BSL from the get-go
I think that's the general attitude the software companies will have going in the future. Why even bother dealing with negative PR and push back against their ability to make money by going with FOSS? In hindsight, TF should have been released with BSL from the beginning.
I am not a huge fan of Hashicorp changing its licenses for future releases but I am also skeptical of OpenTF's motives since their members have big financial stake in that decision.
Acknowledged, there are always self-serving motives involved. Generally things don't happen without a reason. But we donated the project to a foundation, and will over time build (and fund) a dedicated independent team who will follow their own vision and the community needs, not ours. So please judge us by our actions, not assumed motives.
> their members have big financial stake in that decision
I can't speak on behalf of others but to us at Spacelift it's less about direct financials (we are actually not directly affected by the license change!) and more about being in charge of our own destiny and product roadmap.
Except you can't say they're "leeching" when they're using the software on the terms you offered it to them.
I'd also love to know how much Hashicorp chips in to maintain the projects they build upon. For example, I'd bet the vast majority of Terraform usage is on Linux. Do they support Linux development? Do they support Go language development? It seems like the companies complaining about "leeches" (eyeroll) aren't the ones actually paying people to work on upstream FOSS projects.
The major difference here is that they are not making a directly competing product to Go, Linux, etc. I find the word "leeching" appropriate because here, it's not simply someone building on Terraform to sell something else, they are selling a direct competitor to hashicorp's products.
In another era "building on X to sell something else" would be still considered "embrace, extend, extinguish" (in the actual, originally intended sense), depending on the market power of the players involved.
At least if the "something else" isn't free software.
I get what you're saying, but on a strictly legal standpoint, everything Hashicorp is doing is by the books...all previous versions of Terraform will remain under the old license and everyone can still use Terraform without fearing a future lawsuit, as long as they stick to those version. So no one made any legal missteps here, neither the users nor Hashicorp.
I think its the ethical side, rather than the legal side, thats more complicated...the contributions from the community contributed to the Terraform "brand" that got bigger and bigger, and now Terraform is attempting to secure their monopoly on capitalization of the brand when previously there was an implicit understanding that the "brand" was open-source.
However, you might also argue that there was an implicit understanding on Hashicorps side that the community wouldn't build directly competitive projects when they held the lions share of the funding on the contribution/maintenance side...
I think the whole thing is pretty complicated - is Hashicorp leeching off of the contributors or are the competitive contributors leeching off of Hashicorp? Honestly I see both sides.
The beautiful thing is that its totally legal and acceptable for OpenTF to do their own thing and continue Terraform under their own terms...so either way we get to see this play out :)
I agree that it seems to be an ethical issue rather than a legal one.
I'm coming down strongly on the side of the users, though. Hashicorp chose the original license, and the one they picked is perfectly fine with the idea of someone else building off it. I mean, it was written by the Mozilla folks. They want people to build off their projects and make a nicer Internet!
Hashicorp could've used a different license if they wanted to. They deliberately chose one that gives users the rights to build on Hashicorp's work -- and yes, even to profit off it at a competitor. What I don't think HC has is the right to act shocked when others use the software under the terms they were allowed to use it.
There is a difference between maintaining something, and maintaining something for your competitors. The second one can reasonably be described as a burden IMO.
I do have principles but they aren't really aligned with the OSI or anything like that. They didn't suddenly change, they are just not aligned with this aspect of FOSS anymore.
Also, when FOSS was created, these concerns were simply non-existing. Times have changed massively in 30 years, "leeching" like this simply didn't exist when those licences were drafted. So no, I don't lack principles, the world simply changed.
the "leeching" in question is Hashicorp leeching off open source developers before closing the source
FOSS generally allows competitors to use your product to compete against you, and always has (the "free" in FOSS refers to freedom), so either you were never okay with FOSS, or you were okay with it and then abandoned those principles to not be okay with it, but having a "principle" that only holds true until you don't like the result is unprincipled
have times changed in a way that justifies abandoning FOSS principles, which include being okay with your competitor using your FOSS software to compete against you? I don't think so.
well, today's society is much more polarised, for example. (see the entire discussion lol)
and also, the whole ecosystem didn't exist when FOSS was created such as selling your software AND a cloud offering for it. If you created let's say an office suite and made it open, your competitor couldn't sell SaaS based on it 20 years ago because SaaS just didn't exist as a concept.... they could try to sell the same product debranded but that's not a very good business strategy.
hashicorp made a good decision here by being FOSS while it made sense, and when the leeches appeared, they decided to restrict future versions. This kind of leeching is the next m$-like EEE (extend, embrace, extinguish) - steal FOSS, host it and capture all the profits, while not maintaining or improving the software at all.
This kind of rent-seeking was simply unimaginable in the 90s when FOSS became a thing.
Also, hashicorp didn't leech off anyone (they didn't make the licence change retroactive, it's only future versions) because their contributions remain available under the same licence - it only applies to future hashi commits. Why shouldn't hashicorp have the freedom to commit in the fuiture with a different licence?
the "leeching" in question is Hashicorp leeching off open source developers before closing the source
the "rent seeking" in question is Hashicorp seeking rent, here, now
FOSS generally allows competitors to use your product to compete against you, and always has (the "free" in FOSS refers to freedom)
also, nobody leeched off Hashicorp, they used the software as the license and Hashicorp intended, until Hashicorp changed their mind on being FOSS. Why shouldn't they have the freedom to use software in accordance with the license?
In a similar way, why shouldn't Hashicorp have the freedom to use a different licence going forward? They didn't leech off anyone, the software was under MPL previously, under which people contributed. Now it is not anymore, you can decide whether you want to contribute under BSL or not.
"FOSS generally allows competitors to use your product to compete against you, and always has" Sure, I know, but I don't think that's viable when you are running a business. You have to take some freedoms away if you want to have a viable product.
In a similar way, why shouldn't software users have the freedom to use Hashicorp's software in a way both Hashicorp and the license intended? Such users didn't leech off anyone.
> I don't think that's viable when you are running a business. You have to take some freedoms away if you want to have a viable product.
I don't agree with this opinion, but even if it were true, it raises the question of why, then, Hashicorp chose that path in the first place, when they knew what FOSS meant?
If they didn't like the freedom part of FOSS, they didn't have to embrace it, but they did, and they did
Allowing what you call “leeching” is a well-considered, purposeful choice on the part of the people who created these licenses. So yes, it should mean that, and if anybody doesn’t like it then they can use a different license. They shouldn’t use a license that is specifically designed for this purpose and then complain when it is used for that purpose.
Although we are not there yet, but if we don't do something to change it, there will be a moment where it will be true that "no reasonable person releases anything under a permissive licence", sadly.
Just see the latest serde "drama", where everyone disregarded the "no warranty" clause in the licence and loudly demanded changes/wanted to fork the project/etc.
FOSS has a huge problem of expectations from both upstream and downstream. There are very common arguments about "I use this, you broke it/made changes I didn't like, so you are a horrible maintainer and person and you will have zero credibility forever". If anyone uses FOSS dependencies, they also accept the risk of future versions being different. No one breaks versions already released, this is always about future versions. Demanding the maintainers to make specific changes/not to make them for your usecase is extremely entitled.
The whole point of permissive licenses is to permit this kind of thing. It sounds like you think every company out there choosing permissive licenses doesn’t actually want to be permissive. Has it not occurred to you that people choosing permissive licenses usually want to be permissive?
That's a good thing. Either launch a closed proprietary product from the get go or commit to maintaining a real open source project. You can't have all the monetary advantages of the first while enjoying the goodwill and community support of the second.
This attitude will just lead to pretty much every product being closed and proprietary. Which sucks for me, because I like to be able to read the source and run modified versions of tools I use, and have no interest in creating competitive derivations of them. So I think it's a shame that people who try to make software like that get pilloried for being neither proprietary enough (which is apparently fine...) nor open enough.
As many of you asked for, we've finally made the repository public and will continue developing it in public from now on.
This took us some time, but you can now read our announcement for more details[0].
Thanks everybody for the support so far, and I welcome you all to interact with the repo, join the discussion, or even contribute.
A possibly noteworthy detail as it's been discussed on HN here a bunch, we've settled with the DCO[1] for contributions.
Also, happy to answer any questions!
[0]: https://opentf.org/fork
[1]: https://developercertificate.org
Disclaimer: Work at Spacelift, and currently temporary Technical Lead of the OpenTF Project, until it's committee-steered.