Live data from Hacker News

What Happens to Relicensed Open Source Projects and Their Forks?

thenewstack.io

1–10 of 33 posts

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

#3
The diversity measures used in this study are a fascinating window into some unusually measurable communities. The count of contributors and volume of their contributions are proxies to many things, including project popularity, ease of contribution, number of approachable fixes (tantamount to how many simple/low-hanging bugs there are), and diversity of use cases exposing the product to new situations (i.e. potential growth of project scope). These things need to align for diversity of contributors' motivations to arise and contributors to approach the project initially, but different things need to arise to sustain involvement: introduction of new bugs, need for completely new features (i.e. a growing project scope), continuing need for refinement of otherwise battle-tested code (i.e. performance gains remaining on the table), and continued relevance as other alternative packages and paradigms rise and fall. I can't wait to read their future work, and I hope it includes measures of project maturity (in the senses of feature-completeness/code quality as well as whether functional scope is growing or not). Surely there are projects that lack contributors for the simple reason that the projects are "done", and surely there are projects where engagement looks like disproportionately many shallow contributions due to immaturity of the product, and surely there are projects that have wider or shallower pools of scope to draw from (as well as management ethoses that readily take on new scope or are avoidant of the same).

Some opposing examples are the Linux kernel (eternally growing scope, with huge motivation by many user communities) and libpng (which is relatively fixed in scope, with desirements like security increasing the bar for contributions to an already mature and popular product).

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

#6
post #4

Hm, I was expecting more business point of view in this article. Right now we are looking information about financial results from relicensing open source. Unfortunately, it is about repositories health. But the article still interesting.

There's some more discussion https://thenewstack.io/why-open-source-forking-is-a-hot-butt... that may be interesting.

Are you in the UK by any chance? I'm sure OpenUK would be interested to chat more (given they've been working on research and impact analysis in this area)

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

#7
> It is still too early to understand the ultimate success or failure of these projects — both the original and the fork.

Mm. This is more “here are some projects and their forks” than “what happens to…”

Ie. TLDR; they’re both going fine in all cases, so far.

Guess we wait and see eh?

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

#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? What about Opentofu?

Even something basic like a graph of LOC changed over time, with a fork in the middle would help to put the article into perspective.

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

#9
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 cares about distributing the GPL code of the BSP, mainly due to fear of violating chipset vendor NDAs.

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

#10

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 like AWS KMS, or static keys.

- Early Evaluation - the ability to parameterize initialiation-time values, like module versions and sources, backend configuration parameters, etc. and keep them DRY.

- (Coming in 1.9) - provider iteration, which lets you use for_each with providers, e.g. create one provider per region, something that currently requires a bunch of copy-paste, or tools like Terragrunt

- (Coming in 1.9) - -exclude flag, which is the opposite of the -target flag, letting you skip planning/applying certain resources.

Probably the best way to see a summary is check out the release blog posts for 1.7[0], 1.8[1], and 1.9-beta[2]. Many of those required non-trivial changes to existing parts of the codebase.

One of the biggest Terraform contributors has also joined Spacelift a couple months ago to work on OpenTofu. All things considered, I'm very confident that the team will be able to handle any feature it sets their minds to, and that those improvements will keep coming. There's a ranking of top-voted issues which is probably the best way to loosely see what will be tackled next[3].

[0]: https://opentofu.org/blog/opentofu-1-7-0/

[1]: https://opentofu.org/blog/opentofu-1-8-0/

[2]: https://opentofu.org/blog/opentofu-1-9-0-beta1/

[3]: https://github.com/opentofu/opentofu/issues/1496

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

Post reply on HN