Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What Happens to Relicensed Open Source Projects and Their Forks?

thenewstack.io

Post reply on HN
Print view View original

11–20 of 33 posts

Re: What Happens to Relicensed Open Source Projects and Their Forks?

#11

Post by gioazzi »

cube2222 wrote: post #10
alexey-salmin wrote: post #8

The topic is indeed very interesting but before studying commit author diversity it would be useful to understand the volume and traction. Statistically most of the forks are dead ends, even if maintained by a few enthusiasts for some time. I'm sure opensearch won't die until it's a commercial offering of AWS but how is going? Any new features coming, a product roadmap exists? Or it's mainly bugfixes and maintenance?…

OpenTofu is doing really well I'd say, and only picking up steam as it's going. Product roadmap-wise, the team has made some big improvements that have been requested by the community for years, with another big release coming very soon (I believe next week or the one after), here's some of the major ones: - End-to-End State Encryption - lets you encrypt your state-file end-to-end, either with a key management system…

Provider iteration is a really nice one - I had a big monorepo that would deploy some baseline services in many AWS accounts, across multiple regions, generating tf.json files for each provider to match all accounts that were created.

However, what really broke this model at some point was the fact that we were running so many providers instances that our Terraform Cloud would go out of memory! Since each provider instance in tf is really launching a new process it really adds up... At some point I was thinking since the engine and the providers use gRPC to communicate, it MAY be possible to distribute providers across machines, but I never investigated it further... I'm pretty sure there was a notice in the tf plugin SDK stating that it was not possible to connect them over a network... but why not? ¯\_(ツ)_/¯

Re: What Happens to Relicensed Open Source Projects and Their Forks?

#12

Post by cube2222 »

gioazzi wrote: post #11
cube2222 wrote: post #10

Earlier quoted context omitted.

OpenTofu is doing really well I'd say, and only picking up steam as it's going. Product roadmap-wise, the team has made some big improvements that have been requested by the community for years, with another big release coming very soon (I believe next week or the one after), here's some of the major ones: - End-to-End State Encryption - lets you encrypt your state-file end-to-end, either with a key management system…

Provider iteration is a really nice one - I had a big monorepo that would deploy some baseline services in many AWS accounts, across multiple regions, generating tf.json files for each provider to match all accounts that were created. However, what really broke this model at some point was the fact that we were running so many providers instances that our Terraform Cloud would go out of memory! Since each provider in…

Yeah, esp. the AWS provider is pretty memory-intensive.

I believe someone on the team did some investigation into this (running providers remotely) but it's not really a priority (if it is for you, feel free to voice that on the issue tracker!).

Frankly though, with pricing for cloud instances being generally linear wrt to the CPU/memory size of the instance, I don't think there's much reason to prefer many smaller machines over just using a larger single one and avoiding all this added complexity.

Re: What Happens to Relicensed Open Source Projects and Their Forks?

#13

Post by graemep »

mschuster91 wrote: post #9
msla wrote: post #2

Related: "Fear of Forking" by Rick Moen http://linuxmafia.com/faq/Licensing_and_Law/forking.html

> That's why forking is uncommon in open-source code, and even more so in (specifically) GPLed code: The improvements one group makes in its would-be "fork" are freely available to the main community. Unfortunately, in the smartphone world this just isn't reality. Trying to obtain code dumps is hard enough for major brands, outright impossible for the myriad of cheap clones. And embedded is even worse, almost no one…

> Trying to obtain code dumps is hard enough for major brands, outright impossible for the myriad of cheap clones. And embedded is even worse, almost no one cares about distributing the GPL code of the BSP, mainly due to fear of violating chipset vendor NDAs.

Sounds like an opportunity for the copyright holders to make some money by suing and dual licensing.

Re: What Happens to Relicensed Open Source Projects and Their Forks?

#14

Post by bhaak »

alexey-salmin wrote: post #8

The topic is indeed very interesting but before studying commit author diversity it would be useful to understand the volume and traction. Statistically most of the forks are dead ends, even if maintained by a few enthusiasts for some time. I'm sure opensearch won't die until it's a commercial offering of AWS but how is going? Any new features coming, a product roadmap exists? Or it's mainly bugfixes and maintenance?…

We’re just migrating to OpenSearch from Xapian and it was one of the question we had. We didn’t want to go from a solution in maintenance mode to one which could be a dead end soon.

From what we’ve seen there is lots of active development going on with many features being added.

But we don’t yet use any fancy features and could easily switch to ElasticSearch if need be. So we got a backup plan.

Re: What Happens to Relicensed Open Source Projects and Their Forks?

#15

Post by chippiewill »

bhaak wrote: post #14
alexey-salmin wrote: post #8

The topic is indeed very interesting but before studying commit author diversity it would be useful to understand the volume and traction. Statistically most of the forks are dead ends, even if maintained by a few enthusiasts for some time. I'm sure opensearch won't die until it's a commercial offering of AWS but how is going? Any new features coming, a product roadmap exists? Or it's mainly bugfixes and maintenance?…

We’re just migrating to OpenSearch from Xapian and it was one of the question we had. We didn’t want to go from a solution in maintenance mode to one which could be a dead end soon. From what we’ve seen there is lots of active development going on with many features being added. But we don’t yet use any fancy features and could easily switch to ElasticSearch if need be. So we got a backup plan.

> But we don’t yet use any fancy features and could easily switch to ElasticSearch if need be.

I think the decision paralysis is the big deal here. I have the exact same situation with OpenTofu and Terraform, they're diverging rapidly yet it's not entirely clear which way the wind is blowing. They both now have compelling and interesting features that the other doesn't have.

So the outcome is that I'm now not using any new features.

Re: What Happens to Relicensed Open Source Projects and Their Forks?

#16

Post by bluGill »

mschuster91 wrote: post #9
msla wrote: post #2

Related: "Fear of Forking" by Rick Moen http://linuxmafia.com/faq/Licensing_and_Law/forking.html

> That's why forking is uncommon in open-source code, and even more so in (specifically) GPLed code: The improvements one group makes in its would-be "fork" are freely available to the main community. Unfortunately, in the smartphone world this just isn't reality. Trying to obtain code dumps is hard enough for major brands, outright impossible for the myriad of cheap clones. And embedded is even worse, almost no one…

for a short time only improvements in one are available. Then the two diverge andchangesecannot merge. khtml couldn't bring in any changes from apples fork

Re: What Happens to Relicensed Open Source Projects and Their Forks?

#17

Post by cube2222 »

chippiewill wrote: post #15
bhaak wrote: post #14

Earlier quoted context omitted.

We’re just migrating to OpenSearch from Xapian and it was one of the question we had. We didn’t want to go from a solution in maintenance mode to one which could be a dead end soon. From what we’ve seen there is lots of active development going on with many features being added. But we don’t yet use any fancy features and could easily switch to ElasticSearch if need be. So we got a backup plan.

> But we don’t yet use any fancy features and could easily switch to ElasticSearch if need be. I think the decision paralysis is the big deal here. I have the exact same situation with OpenTofu and Terraform, they're diverging rapidly yet it's not entirely clear which way the wind is blowing. They both now have compelling and interesting features that the other doesn't have. So the outcome is that I'm now not using a…

I think many people have been in this situation.

In practice, and I'm extremely biased here, I'd consider the most risk-averse option to be going with OpenTofu but not using any of its exclusive new features. With this you get dependency updates and the widest competitive range of vendors in case you ever want to use a commercial orchestrator service for it.

However, it seems to me folks at companies of all sizes are increasingly deciding to bite the bullet and migrate, esp. since the last release a couple months ago. E.g. see the talk by Fidelity[0] on OpenTofu Day at Kubecon.

[0]: https://youtu.be/7Ypulc2GyoE

Disclaimer: I am involved in the OpenTofu project and was previously its tech lead.

Re: What Happens to Relicensed Open Source Projects and Their Forks?

#18

Post by cube2222 »

mschuster91 wrote: post #9
msla wrote: post #2

Related: "Fear of Forking" by Rick Moen http://linuxmafia.com/faq/Licensing_and_Law/forking.html

> That's why forking is uncommon in open-source code, and even more so in (specifically) GPLed code: The improvements one group makes in its would-be "fork" are freely available to the main community. Unfortunately, in the smartphone world this just isn't reality. Trying to obtain code dumps is hard enough for major brands, outright impossible for the myriad of cheap clones. And embedded is even worse, almost no one…

> The improvements one group makes in its would-be "fork" are freely available to the main community.

IANAL, but there's a caveat here, which is that a lot of these forks are due to companies relicensing to source-available licenses, which generally means they require a CLA (and full copyright license) from each of their contributors, so that they can relicense the codebase at will.

The code committed to the fork can't be pulled by the relicensed project in this case, unless it's the original contributor making a contribution to both, because such code would only be covered by the fork's license, not by the new license nor CLA.

Re: What Happens to Relicensed Open Source Projects and Their Forks?

#19

Post by antirez »

Every time I see some post where commits are taken as contribution metrics, I remember when, after working for months at it, I merged Redis Cluster into Redis as a single commit, and saw the pale green square appearing for that day in my GitHub contributions chart. Now it's 1.5 months that I work 10h/day at Redis Vector Sets and they will also be a single commit. It's very simple to do better than that, as a metric: different developers have different habits. For me, a stream of changes of early-day design just pollute the contribution history. Starting from a solid and advanced beta, then yes, history is great to have.

Re: What Happens to Relicensed Open Source Projects and Their Forks?

#20

Post by sgc »

antirez wrote: post #19

Every time I see some post where commits are taken as contribution metrics, I remember when, after working for months at it, I merged Redis Cluster into Redis as a single commit, and saw the pale green square appearing for that day in my GitHub contributions chart. Now it's 1.5 months that I work 10h/day at Redis Vector Sets and they will also be a single commit. It's very simple to do better than that, as a metric:…

I think the authors agree with you. They tried to look at lines of code added / deleted (eg "they consistently made over 95% of the lines added to and deleted from Elasticsearch") - although the language in the article flops between that and just saying 'commits', so it's not sure what they were actually looking at for the write up. In their scraping code / dataset linked at the start of the article, they are logging `commits_list = [commit_date, dels, adds, oid, author]`.

This is also just a blog summary of a preliminary study:

> "This is the first step in a much larger research project underway [...] we’re working toward including more repositories and additional metrics to better understand the project health dynamics within these projects."

Project activity will remain inherently fuzzy. Just about everybody who programs extensively has spent a couple days to change a line or two of code at some point in their life. No metric can capture that unless we are all journaling and publishing our life activities.

Nonetheless we can do better than commits, as you said. If you review most anything online, there is a global score and then 3-5 categories with subscores. Surely the same should be true here. Freshness of LOC changes, average freshness of the overall codebase as a percent, issues satisfactorily resolved (and not closed because they are blown off, which should be a negative indicator), merged pull requests, to think offhand of a few.

What would be your top 5 categories to evaluate the "health" of a code base, admitting that any evaluation will remain a very fuzzy approximation at best?

Post reply on HN