Report Finds Few Open Source Projects are Actively Maintained (infoworld.com) 53
"A recent analysis accounting for nearly 1.2 million open source software projects primarily across four major ecosystems found that only about 11% of projects were actively maintained," reports InfoWorld:
In its 9th Annual State of the Software Supply Chain report, published October 3, software supply chain management company Sonatype assessed 1,176,407 projects and reported an 18% decline this year in actively maintained projects. Just 11% of projects — 118,028 — were receiving active maintenance.
The report also found some new projects, unmaintained in 2022, now being maintained.
The four ecosystems included JavaScript, via NPM; Java, via the Maven project management tool; Python, via the PyPI package index; and .NET, through the NuGet gallery. Some Go projects also were included. According to the report, 18.6% of Java and JavaScript projects that were being maintained in 2022 are no longer being maintained today.
Other interesting findings:
The report also found some new projects, unmaintained in 2022, now being maintained.
The four ecosystems included JavaScript, via NPM; Java, via the Maven project management tool; Python, via the PyPI package index; and .NET, through the NuGet gallery. Some Go projects also were included. According to the report, 18.6% of Java and JavaScript projects that were being maintained in 2022 are no longer being maintained today.
Other interesting findings:
- Nearly 10% reported security breaches due to open source vulnerabilities in the past 12 months.
- Use of AI and machine learning software components within corporate environments surged 135% over the last year.
Re:Cool (Score:5, Interesting)
As far as I'm concerned there are maybe 50 worth having at all.
Each of those 50 rely on another 100. Each of those 100 rely on an average of another 30 or so (made up numbers but it won't be far off - the average number of open source components for an application is around 500).
That means you likely depend on 2500 open source projects. Which is fine, as long as we recognize that the responsibility for ensuring that all those dependencies are up to date is your software supplier such as a distribution and that the industry standard is that anyone who is responsible has paid people who ensure that all those dependencies remain up to date and get fixed if a security vulnerability is reported.
It's not enough to rely on unpaid maintainers. If you have a security problem with their software and you aren't paying them then you have a duty of care to ensure you have someone available who knows and cares about the software and who can support the maintainer to fix the security problem.
Re: (Score:2)
On .Net, half of those are probably Newtonsoft.
Re: (Score:2, Insightful)
I don't know why this post was upvoted, but then again populism does not correlate with intelligence.
You must have a really gaping egress port to keep pulling these random statistics from.
I've looked at a few of the 'essential' packages (imho) and the most I've seen has 44 external dependencies, not surprisingly its a Python project.
Most others have at most 5.
Re: (Score:3)
I don't know why this post was upvoted, but then again populism does not correlate with intelligence. / You must have a really gaping egress port to keep pulling these random statistics from. / I've looked at a few of the 'essential' packages (imho) and the most I've seen has 44 external dependencies, not surprisingly its a Python project. / Most others have at most 5.(my brevity)
There are two approaches when you see something that doesn't match with your experience. You can either just declare it wrong, move on and remain stupid forever or you can ask what could be the source of that belief [darkreading.com], perhaps question it and most likely learn something new from time to time. The number of dependencies is very language and framework dependent. Whilst I don't believe your Python numbers - I've seen lots more - they probably aren't nearly as wrong as you would be applying your experience to oth
Re: (Score:2)
As far as I'm concerned there are maybe 50 worth having at all.
Each of those 50 rely on another 100. Each of those 100 rely on an average of another 30 or so (made up numbers but it won't be far off - the average number of open source components for an application is around 500).
That means you likely depend on 2500 open source projects.
And... I imagine people probably have different projects on their lists of 50. So, all in all, it's even more in total.
Re: (Score:2)
The list of 50 may be slightly varied, but the list of dependencies isn't that much different, as those are shared libraries, framework, servers everyone uses. And 118k allows for a lot of variations.
Re: (Score:2)
Another approach to this is to look at the numbers of packages in RHEL. RedHat takes care to reduce dependencies because they end up clearly responsible for maintaining them all for years, often after support stopped for upstream. They end up with 3721 packages in RHEL9 which is not far off our number. Of course you don't use all of that, on the other hand, since they avoid high dependency software, the stuff you add will likely make up for the stuff you don't use. So something like 5k +- one order of magni
No shit (Score:3)
Open (Out)source (Score:2)
In my experience, open source means no more no less than allowing someone else, usually a big corporation, to steal your work and then demand you keep maintaining it for free because they rely on your project to make money. F... off.
Re:Open (Out)source (Score:5, Insightful)
In my experience, open source means no more no less than allowing someone else, usually a big corporation, to steal your work and then demand you keep maintaining it for free because they rely on your project to make money. F... off.
If you have a problem with this then you need to fix your software license. Normally (but not always) a license like the AGPLv3 will ensure that they are contributing back to your software base. If they demand fixes without being willing to pay, rather than providing fixes and helping you, then they are customers not collaborators. Non paying customers get non-service.
80-20 (Score:2)
Re:80-20 (Score:4, Informative)
Also refer to "Sturgeon's law".
Confounding factors (Score:5, Insightful)
Since Open Source projects don't have a sales and marketing department rending their garments for new features nor executives desperate for "shareholder value", once mature and sufficient, they tend not to be actively maintained unless or until someone actually needs another feature bad enough to submit a patch or pay someone else to.
Re: (Score:2)
I had an employer (since passed on) who had run a contracting company dependent on the US government for many years before I came to work for him. I remember him saying to me about how he'd tried many times to work in the commercial sector exclusively but he couldn't stop sucking at the tit of government.
I think this is hugely analogous to the open source thing. I've contributed to a number of OSS projects but I don't go back and look at what I submitted. It was single use, one shot that scratched *my* i
Re: (Score:3)
Re: (Score:2)
Sure, but if it is well programmed rather than relying on the flavor of the week dependencies, it can run correctly for years or decades. Many apps that don't include network functionality actually have no security implications.
Re: (Score:2)
Re: (Score:2)
Really, if your software isn't run with elevated privileges and doesn't interact with the network, it doesn't really have much relevance to security as long as it doesn't do anything really stupid like treat data as executable (looking at MS products).
Some software reaches maturity and then doesn't really need anything but a way to download it.
Shrug (Score:3)
So they're talking about dependency management.
Only 11% of Open Source projects are maintained. But most of those unmaintained projects are hobby projects where the person lost interest, or internal tools from a company (that also lost interest).
But when I'm installing a dependency in my project I'm using something like numpy or pandas. I'm not using phil_lib unless Phil did something really critical that I needed, and even then it's probably something pretty small and very specific and it probably doesn't matter if Phil moves on.
So what's the percentage of actively maintained software that has a dependency that is no longer maintained? I didn't see that figure which makes me believe it's pretty low or the "software supply chain management company" would have made it the headline.
There's a ton of "open source projects" that are some individual's hobby, or a company's internal tool. It becomes a project until they lose interest, and then it's gone.
Re: (Score:2)
Not to mention that I'm surely not the only person to have a few "open source projects" on Github which are just a minimal reproducible demonstration of a bug which I needed to put online before submitting the bug.
Re: (Score:2)
Dependency management is hard. Deps go wonky all the time even when they are actively maintained. Example: security issue forces a breaking API change, breaking my code.
Which is why I'm ok with using Newtonsoft.Json or NumPy, but not so much gfhs.ciwn.H4ck4r3.DoEverythingLib with 400 recursive dependencies, including multiple incompatible versions of the same exact ones. Or for that matter HansReisersCoolNewKillerFS.
I try to audit all direct and indirect 3rd party dependencies of the software for wh
Yes, so? (Score:5, Interesting)
There are a lot of FOSS projects that are not relevant. There are also some that are stable and do not need maintenance. For example, gzip will likely need maintenance when systems move to 128 bit.
The metric metric is mostly bogus. This seems to be somebody that thinks they can compare commercial software and FOSS in this way. Just shows a lack of clue.
Re: (Score:2)
This seems to be somebody that thinks they can compare commercial software and FOSS in this way. Just shows a lack of clue.
Except they show all these open source statistics but none on closed source. They don't actually DO a comparison.
Most proprietary programs I ever used have been discontinued and not all ever had a patch. Some were dropped by the company stopping my use as they no longer operated the online component needed to run it. So how is that any different?
Re: (Score:2)
Indeed. Teh whole "analysis" is deeply flawed.
OMG, so few?? (Score:4, Insightful)
Seriously. I read this as "there are around 130,000 projects actively supported". That is not a small number, so I am not sure why I am supposed to be worried. It's easy to submit, there is early excitement by the developers etc. etc. Seems to be human nature, not a software thing.
From my perspective, if that number _stays_ in that range for an extended amount of time, that may just be the natural level. Besides, sometimes even a not actively supported project may be useful, at least until a major software upgrade breaks things. Not everything needs to be updated all the time. Granted, (very) small percentage of total projects.
Anyway, I find this number to be interesting and, ultimately, not surprising. Moving on, nothing to see here.
As a prof... (Score:5, Insightful)
All of my coursework and projects are BSD licensed, so open source. Ones that are no longer in use are still available, but "unmaintained". That's probably 30 or 40 repositories on various platforms.
So what? Someone may still find them useful. There's no need for maintenance.
I expect a lot of open source projects are similar. How many of you have some personal project out there, that you haven't changed recently? I have sudoku and nonogram games, they work, they're finished. Again, there's no need for any maintenance.
In related news... (Score:5, Insightful)
Likewise, only a tiny percentage of all of the closed-source software that has ever been released is still actively maintained.
Re: (Score:2)
And you can't even fork and maintain it yourself if you wanted.
I suspect that... (Score:2)
Many are simple and work fine without maintenance
Many are unused and the developer lost interest
Many simply suck mightily
In general, creating is fun, maintaining is work, often hard, unpleasant work
Re: (Score:2)
This right there.
There are 2 kinds of projects that don't receive updates:
1) Those that are finished (or at least without any relevant issues/bugs/flaws) and don't need any.
2) Those that are abandoned and don't interest anyone.
In case of 1, be happy and use it. In case of 2, if you need it, fork it and maintain it.
In either case, there's zero use whining about poorly maintained projects.
Re: (Score:2)
Yup, a lot of the small stuff I see was "one and done". Sadly code that depends on other things, like a commercial database, accumulates defects over time until that "last maintained in 2020" git site stops working. I end up having to review their work but I'm limited to my knowledge of the language and subject and I may just have to pass on it.
>In general, creating is fun, maintaining is work, often hard, unpleasant work
The real thankless job is maintaining. Documenting is even less thanked.
It remind
You know why? (Score:3)
Because the giga-corporations that built their billions on the back of open source more often than not have never paid a single dime to the software programmers that made their fortunes.
Maintaining software is work. People tend to enjoy being paid to do work. Me, I put a few open source projects out there over the decades. I worked on them as long as they were fun or solved a problem I had, and I stopped working on them when they weren't fun anymore or they were good enough to solve my problem. Pay me and I'll keep maintaining them if you want me to.
Those who complain that open source projects aren't maintained are welcome to fork them and maintain their own fork.
How many proprietary software products are? (Score:2)
How many millions are unmaintained? Funny, I bet it won't be easy to find all those products/projects much less check for updates as easy as querying github.
And this is why node.js is such a clusterfuck (Score:4, Insightful)
If you find a page with node.js, rejoice. At least if you want to break into it. Because it's almost a given that you will find a way to abuse that page.
Node.js suffers from the "everyone and their dog" problem. Everyone and their dog can somehow hack together some javascript monstrosity. And I mean monstrosity in the Frankenstein sense. Cut together from bits and pieces that somehow fit together, a hodgepodge of code that works kinda-sorta, usually without the idiot hacking it together having even the first clue of what he does. After all, node.js was created when we noticed that we have a lot of webdesigners that can somehow write JS code but we don't need them, but we could use a few backend programmers.
And thus, this monstrosity was born.
So what you have now is a bunch of people who think they can program when all they really can do is cargo-cult some stackexchange answer together. And of course every single one of them has to write his own database module. How many "standards" for accessing PostgreSQL in node.js exist today? A dozen? More? How many of those are still maintained?
Because the same programmers that can't be assed to learn programming also can't be assed to maintain their atrocities after they lose interest. Which is about 5 nanoseconds after they finish their projects, but not before smearing their shit all over github for everyone to download, because MY database connector is HEAPS better than the score that already exists.
And now the really big problem starts.
Because now people who know even less about programming than these idiots enter the ring and download their connectors. Without checking first whether there has ever been any maintenance in the past 3 years. Hell, chances are that even if they checked, they'd find out that ALL of them didn't receive a patch in the past 3 years, so pick your poison. Or, hell, create your own and add to the mess...
And then the inevitable happens. Someone finds a security flaw in one of the more popular Frankensteins. It's not like you have to look long or far. And now you're stuck with a piece of code you'd have to fully rewrite to use some other database access code (because you don't think that they'd give a fuck about compatibility with any of the other existing code, do you?), and how many bosses will actually approve the cost of that?
Seriously, people. I had to review quite a few of node.js pages. Not a single one of them was without a critical flaw.
Re: (Score:2)
Re: (Score:2)
left-pad...
Re: (Score:2)
Re: (Score:2)
nodejs passed python in popularity? When did that happen since yesterday [tiobe.com]?
JS may have its space to spice up webpages. But relying on this ugly, bloated mess to run webservers? That's something it was never meant to do and shouldn't do.
Re: (Score:2)
Cherry-picking much? nodejs is not a language, python is a language. But you seem confused about that. Python has been less popular than Javascript depending on the hundereds of different surveys you care to look at. They are all flawed, so nice strawman you have there.
>But relying on this ugly, bloated mess to run webservers?
That's just your opinion. I find other languages far more bloated than javascript. So
Re: (Score:2)
Fuck your strawman. Learn a sensible backend language or go back to making webpages slow, where JS belongs.
Re: (Score:2)
Re: (Score:2)
I'm in security. I get to test servers on a daily base. So believe me when I tell you, yes, I do know JS better than I want to. I also get to see what technologies are used to power servers, on both sides, backend, frontend, what's used in between and so on.
The most severe problems, because they're those problems that cannot be fixed easily, are problems that arise from using outdated modules, libraries and plugins that cannot be updated. If it's just outdated and has a security issue, the fix is usually ea
Creators and stewards: Very different creatures. (Score:2)
How can they tell? (Score:4, Informative)
I have several open source project on my github (https://github.com/dj-on-github).
Many of them I haven't touch for a long time because they work and no bugs have been reported. So would those count and not being maintained? They are maintained in as much as I am available to fix bugs that are reported and add features as needed, they just don't need much maintaining.
Level finding (Score:3)
They are all maintained to exactly the level they need to be maintained.
If interest in using them is low then the maintenance is unjustified, if interest is high then there will be contributions back or, maybe even local patches applied. Either way the level of effort is ideal.
how many? (Score:2)
So 11% are actively maintained. How many are actively used? I guess the percentage is about the same.
Don't blame the authors. Blame the users. (Score:2)
Most of the open source projects I created are now unmaintained. And this trend will continue as more and more of my projects will still be publicly available, but I'm not interested in them anymore. This is just a mathematical trend.
But is it a problem?
The problem is not the maintainer's fault. The problem is on the users side. If the project is unmaintained and you care about it, take it over. Or just use something else instead.
No updates does not mean unmaintained (Score:2)