What Happens to Relicensed Open Source Projects and Their Forks?
thenewstack.io
thenewstack.io
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?
I am quite curious as to your take on a few metrics that would help evaluate the health of a code base. It's a dirty job, but we all have to do it every time we look for something new.
Said company was bought by a large US company where one of their key metrics for a developer was number of new lines of code.
It went down-hill from there. 10% of people were fired because mothership instituted job cuts globally, and then people were leaving, then another round of cuts, then most people left, then the company was sold, I think losing a fairly hefty part of its valuation.
Eventually large US company was bought by Oracle, which to my eye indicated Oracle is like MS; they have a single product, which is a massive cash cow, and for the rest, they serially make terrible decisions (a la Nokia et al).
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.
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.
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? ¯\_(ツ)_/¯
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.
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.
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.
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.
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.
Sounds like an opportunity for the copyright holders to make some money by suing and dual licensing.
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.
Most problem of BSP programming is it is really complicated, because need to fit within limits of hardware and need to have deep knowledge of DSP environment.
So it is very interest question, who will do complicated things for free, or who will dive deep for free.
Unfortunately, too many people compare apples with carrots, in this case compare definitively shallow frontend/full-stack programming vs hardcore embedded.
And returning to question, in real life, nobody want to rewrite all core code for BSP, but really use huge chunks of ready made code, provided by vendor, so, sure they have very tight coupling to vendor copyrights.
Sometimes, things are even worse with hardware limitations, which just made impossible to write other way than does vendor.
Other problem, regulations - using vendor code you automatically obey laws, or to be honest, you shift responsibility to vendor, but if write your own code from scratch, will need someway create proof that people could trust to your code.
OSS has basically theseus shiped into something completely different. Not a criticism just an observation.
The more open the license, the more options available.
Why would a company ever open-source their product then? Giving up that complete leverage can be a selling point during the purchasing process, making buyers more comfortable that they won't be (completely) locked in, and be a net positive on revenue through faster sales.
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)
I understand that the companies probably did majority of the work, However I can't put my finger on this comparison... Sounds strange and inaccurate
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?
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).