OpenTofu may be showing us the wrong way to fork | Hacker News Reader

OpenTofu may be showing us the wrong way to fork

infoworld.com

I have no horse in the race, but as an outside observer, and involved in some small open source stuff, I find it interesting the dynamics of these kinds of large public events and forks. Looking at the contributor activity from Aug 13th 2023 to today, there seems to be slightly less activity in the OpenTofu repo vs the original Terraform repo, but small sample size and just eyeballing it, don't take this as an accurate statement.

I wonder how viable this fork will end up being. To contrast with the recent Redis debacle, Redis is by some measure a completed piece of software, as suggested by the Redict fork. But with the moving target of the Cloud, is Terraform in a similar bucket? Will there be enough support behind this fork 5 years from now? And by support I don't mean is some big tech company's logo displayed on the website - are there multiple contributors or is it some random person in Nebraska doing what they can during evenings and weekends?

Might be an unfair comparison, but I'm reminded of the Reddit API uproar last year. It did what exactly? Reddit IPO'd, got their cake, the people who threw up their arms got what? Some maybe left, others just quietly returned to their corners of Reddit and continued using it? Will these large publicity forks end up being healthy and viable or end up open-source abandonware that once promised the world?

To be clear, I'm all for competition, FOSS, and all the stuff. I just genuinely worry about big bang, high publicity stuff. Is it big bang and then a quiet whimper, or a self sustaining entity for the long term?

> slightly less activity in the OpenTofu repo vs the original Terraform repo,

There is actually quite a bit of difference in activity level, if you consider unique people engaging with both projects. In the last 30 days, Terraform had 205 unique users interact with their repo vs 62 for OpenTofu [1].

[1] https://devboard.gitsense.com/opentofu?id=82c4b68df1&nb=all

Edit: If you only consider people with merges, then the activity level is very similar

https://devboard.gitsense.com/opentofu?id=82c4b68df1&nb=all&...

Note 1: Full disclosure, this is my tool

Note 2: You can't read too much into the trending insights for now, since I need to spread the API limit across many repos, so I only go back so far for each repo.

I think comparing number of contributors is not the point here. I would not be surprised if Hashicorp can put more people on their proprietary heavily modified version, and it will be more advanced. Yet the Open Source version can be good enough, and prefered for 95% of folks out there

My question is, how do Env0, Spacelift, and other Terraform automation and collaboration tool vendors make money if they make OpenTofu so good that it's preferred for 95% of folks out there? Do they fight over the support money scraps?

Env0, Spacelift, and (my company) Terrateam compete with Terraform Cloud not Terraform. Terraform and OpenTofu are CLIs that turn HCL code into living infrastructure. The business model of these offerings, including TFC, is to provide the layer most organizations need above that, such as collaboration, interfacing with VCS, etc.

Git being better does not make GitHub bankrupt. They operate on different layers.

Hey, OpenTofu core team-member here. I'd like to leave a note on what seems to have caused a lot of the confusion in this article.

The copyright headers in the new files are necessary because we sometimes need to move around code from older files.

For more information you can see this issue: https://github.com/opentofu/opentofu/issues/454#issuecomment...

I diffed one of the example files. I don't see clear copying. It looked at a moderate glance to be a different implementation of similar functionality.

I didn't spend time looking at the others as I felt the argument as put forth was already weak.

I'd suggest comparing yourself and not assuming that the author's points are all valid.

I had a skim as well, and they're substantially different. Sure there will be some similarities since they're trying to achieve the exact same results given equal inputs but I don't know how you could qualify OpenTofu's code as "copy-paste and change the license".

These types of things are very hard to definitively prove one way or the other. I was once loudly accused of plagiarizing someone's answer on Stack Overflow. And they were right, the answers were very similar – the code was near-identical and even some of the verbiage of the explanation was quite similar.

Luckily I was able to prove my innocence quite conclusively as my answer was several months older that theirs. Whoops! We had a laugh about it and it all ended well, but it's a nice example on how two strangers can arrive at very similar code.

Should probably look at the original commit in the PR, rather than the current state of the repo. There's quite a bit of feedback on that PR and there may have been other changes since: https://github.com/opentofu/opentofu/pull/1158/commits

It's certainly not a blind copy/paste, but I find it very hard to say if it's a reworked version of terraform or a clean re-implementation. I think both are possible, or something in-between: they looked at the terraform patch to see what approach they took, went "ah right, that approach will work", and then implemented their own patch "from scratch". Is that legal? Probably. Is it moral? Well, you decide.

OpenTofu already requires a Developer Certificate of Origin: https://github.com/opentofu/opentofu/blob/main/CONTRIBUTING.... – basically we have to believe people are not lying when they say they're the author. While there are perhaps some eye-brow raising bits of code here and there, I think the current evidence is not even close to strong enough to call people liars.

The author is paid to make these articles, it is his job to make these points, valid or not. "Infoworld" is putting itself as an outlet for corporate propaganda providing a sneaky disclaimer at the bottom.

Did the same with the same conclusion.

Take a look at the actual commit history. It's clear copying the BUSL files and then changing things.

https://github.com/opentofu/opentofu/pull/1158/commits

I see lots of new activity in there, including reviews and feedback etc. What makes you feel they are copied?

> Matt Asay runs developer relations at MongoDB.

Explains the lack of factual basis. It is literally a PR campaign.

It's a PR campaign?! What?

MongoDB is mentioned in the footer, in greyed text. MongoDB benefits from Terraform vs OpenTofu tensions how?

Do you run or work for a DB company? Because your comment sounds like a PR campaign by that logic.

It is not really hard to put two and two together about what a source-available software company's developer relations person has to gain by publishing a hit piece on community forks that are created to oppose source-available licences.

That aside, it is literally in the title "developer relations." I am not sure what is outrageous in pointing that out.

Fair enough. I get what you're saying.

But is this about MongoDB trying to deter forks? Are there any live MongoDB fork? Hasn't the MongoDB hype train derailed a long time ago?

Beyond the license issue, the promised features vs. difficulty of implementing them is a knife in the 'if you don't like it, it's open source -- you can do anything you want'.

It's a technically correct statement. But that is all it is.

To get the full benefit of OSS, it's not enough to make open source software. You have to make forkable software. Sure, projects such as Chromium and Keycloak are technically OSS, but they're so massive and complicated that very few have the resources to fork them. It's not as bad as proprietary software, but it has some of the same drawbacks.

Technically correct is the best kind of correct (tm)

Just to update on how this continued to unfold, following a detailed response by the OpenTofu team, this is the official statement by Matt Aasy the author of the article, apologizing and acknowledging that he was wrong to rush to conclusions:

https://twitter.com/mjasay/status/1778454498664690108

I think the great lesson here is this - if Fork is where to compete with Proprietary Source Available software, it is likely it will need to implement a lot of similar functionality and to avoid potential problems it is very important there is a process of "clean room" implementation. I would consider asking developers to speficially attest they have not been looking at the visible but proprietary implementation when contributing code to Open Source project

The OpenTofu developers take tremendous care in ensuring that no code comes from Terraform post-license change.

The claims in this post are just absolutely nonsense and if you look at diffs of the files given, they look a lot different to me. This article is a Gish gallop of public relations.

no diff referenced, incompetency or pr campaing from hc

There are links to 3 files in both opentofu and hashicorp.

You could get the diff yourself from that. The point about the header comments is pretty damming.

It’s probably just laziness / not knowing how to make diffs from 2 different repos.

I looked at the pull request that added this new feature and it didn't seem to touch the headers at all. My guess is that the headers are left over from before the fork, and anyway they are true, HashiCorp still holds the copyright to the majority of that code.

Later edit: for new files, it seems that the old copyright notice was kept until a new copyright notice was settled on [0], and anyway even the new copyright notice references HashiCorp as well [1] (I don't know the history, but possibly because they could be considered derived works?).

[0] https://github.com/opentofu/opentofu/pull/1158/commits/35d1a...

[1] https://github.com/opentofu/opentofu/issues/454#issuecomment...

The bit about the header comments is misleading, as OpenTofu attributes themselves and hashicorp, at least on the first file. If they used any snippets of code from another file in the open source codebase (eg, moved probably has very similar functionality under the hood), then it would be appropriate to attribute that code the the original author.

He's got a point because if you look at first example (didn't bother to look at others) the diff is substantial and invalidates argument made in the article. Embedding diff in website is super easy novadays and whole article talks about just that.

If true, it's impressively foolish.

Still, pre-BUSL Terraform is an achievable goal.

Also an achievable goal is reimplementing the new feature without relying on code which HashiCorp only released under the BUSL. It’s a shame they didn’t do that in this case.

It's not at all clear that they didn't. This article seems biased and misleading.

The article shows a HashiCorp copyright notice coupled with an MPL license header for a file that was never released by HashiCorp under the MPL. How is that biased and misleading?

If you look at the commit history, the reviewers actually asked why the files have the HashiCorp copyright, and it seems that the developers were not sure what is the final copyright notice for new code. The one they settled on recognizes copyright both from HashiCorp and the OpenTofu foundation, as even the new files are probably deemed to be derived works of HashiCorp.

Here is the comment I'm mentioning: https://github.com/opentofu/opentofu/pull/1158/commits/35d1a...

Thanks for that additional context. Still, there are enough other parallels with BUSL-only Hashicorp code, including several identical new filenames, that the questions raised by the article seem fair as questions to me. I don’t think the article claims to answer them more definitively than initial speculation.

(That is, the article is noting a bunch of observations and saying what it looks like to the author, explicitly without firmly asserting any underlying truth.)

At the very least, a court would probably send an infringement lawsuit on this basis to trial, surviving an initial motion to dismiss, regardless of what the eventual verdict might be after full fact-finding.

Reply on news.ycombinator.com