The Linux kernel has become such an integral, core part of pretty much all aspects of the technology world, and corporate contributions to the kernel make up such a huge chunk of the kernel’s ongoing development, it’s easy to forget that some parts of the kernel are still maintained by some lone person in Jacksonville, Nebraska, or whatever. Sadly, we were reminded of this today when the sole maintainer of a few DRM (no, not the bad kind) announced he can no longer maintain the gud, mi0283qt, panel-mipi-dbi, and repaper drivers.
Remove myself as maintainer for gud, mi0283qt, panel-mipi-dbi and repaper. My fatigue illness has finally closed the door on doing development of even moderate complexity so it’s sad to let this go.
↫ Noralf Trønnes
There must be quite a few obscure parts of the Linux kernel that are of no interest to the corporate world, and thus remain maintained by individuals in their free time, out of some personal need or perhaps a sense of duty. If one such person gives up their role as maintainer, for whatever reason, you better hope it’s not something your workflow relies, because if no new maintainer is found, you will eventually run into trouble.
I hope Trønnes gets better soon, and if not, that someone else can take over from him to maintain these drivers. The gud driver seems like a really neat tool for homebrew projects, and it’d be sad to see it languish as the years go by.
So goes the myth of “many eyes make bugs shallow”. There is no “many eyes” for most open-source code. With the exception of corporate-sponsored open-source code, most open-source code is an 1-2 man show.
This is sadly very true. And combined with the fact that some of those projects have become dependencies in others we rely on.
This will accelerate over the next few years as the last of the boomer generation retires and Really when Linus’ and his generation reach retirement (less than a decade away).
It will be fine and each new generation deserves its own era anyway. For example Windows is not all that relevant any more either. Times change.
Some people used to feel proprietary code is supreme, now you claim corporate sponsored open source code is supreme. Reality being all this claims are shallow and GNU/Linux runs the world.
kurkosdr,
I think it’s also true of most proprietary software too. People may wrongly assume the standards are higher in corporations.
But yeah I think you’re right. I had a motherboard with a chipset driver supported by a single developer, meaning fans/sensors. Everyone was making demands and he was getting nothing for his work. Due to kernel politics he wasn’t getting support from upstream either. It was just causing stress so he just threw in the towel and there were no new takers.
Given time and dedication, a single person really can achieve a lot and be extremely useful for FOSS. But it can also be thankless especially if you are supporting yourself financially and you have demanding users who don’t help. The burn out is real. What’s more is that if instead of creating your own work you try supporting other people’s code, you may not get the credit and recognition for it even if you end up doing more work than the original authors. Although I’ve experienced this same phenomenon in the corporate world too.
It’s quite a strange situation though, with so many FOSS advocates, the RTFM mentality, I thought that more people would be involved in the creation and maintenance of this “freedom” legacy, willingly stepping in when someone was stepping out. Obviously there are more Karen-like vocal brats than silent heroes out there. That doesn’t shine a good light on this fragile ecosystem.
Obligatory XKCD : https://xkcd.com/2347/
Read any “GNU/Linux” thread or backlash against something Red Hat has done and the “Karen-like vocal brats” problem is right in the spotlight. It is clear that many “communities” are filled with entitled takers that never contribute anything and have VERY strong opinions abou their rights and the obligations of others. Their core function seems to be mostly to complain about the people doing the actual work, be those individual contributors or paid developers at corporations.
Over the years, I have really come to appreciate the subtle difference between the definitions between Open Source and Free Software. Open Source is a better way to build a lot of software and even greedy corporations figure that out a lot of the time. We all benefit from that and I think it accounts for the vast majority of software in the ecosystem but Open Source is more of an engineering philosophy than a political one. No surprise then that the people most vocal about the politics are often contributing the least. Sadly, the “everybody pulling together for the common good” ideal works about as well in Free Software as it does in economics.
In Free Software, the Pareto Principle ( 80 / 20 rule ) is in full effect. I think that less than 5% of the “community” contributes 95% of the code. It may be less than 1%. The people that do though are real super-heroes. At the very least, we should treat them better.
LeFantome,
There’s undeniably a lot of friction there. Redhat’s case is particularly interesting because they are playing both sides of the field. They want to cut off downstream users who use the GPL’s redistribution rights, yet it’s these very same rights that entitle redhat to bundle thousands of FOSS packages into RHEL. They want the benefits of the GPL for themselves, but don’t want to extend those benefits to others.
It seems like we need to solve the problem of FOSS funding in order for contributors to be economically stable, but funding is challenging especially when FOSS licenses literally entitle others to give away one’s work for free.
Yeah, there are many freeloaders. I contribute a few patches, but I’m guilty as well. I think many corporations are using FOSS but not contributing back.
I agree, but I don’t know how to get there.
You can bet the people maintaining the Windows version of the driver are more, because that’s where the money is.
kurkosdr,
I wouldn’t call that a sure thing though. I’ve experienced countless devices becoming unsupported on windows. I’d even go as far as to say it genuinely concerns me when I buy new hardware because of these experiences. Planned obsolescence is very real.
My latest purchase is an oscilliscope and I find myself in the same boat once again, I absolutely hate being stuck with proprietary drivers with an uncertain future. I would far rather have open drivers that I can support if need be than proprietary ones that I can’t. The problem is that the majority of manufacturers don’t offer FOSS drivers to begin with, but that’s the way it is.
@Alfman
Absolutely, a LOT of commercial software is staffed even more poorly. For one thing, if it is “well managed”, commercial software is staffed “minimally” whereas FLOSS receives contribution based on interest of developers. It is why many software categories are led by an Open Source alternative that proprietary options struggle to compete with (or decide it is not worth competing with). Not only may the FLOSS option have broader participation but that participation may include world-class talent. You would never pay talent like that to work on some classes of problem. Some things that are not “commercially important” can by very interesting, quite fun, and maybe even very useful..
On the other hand, most commercial software at least gets the “minimum” developer support that it needs. If paying customers rely on something, generally the supplier will ensure that developers are assigned to it. They may not be world class but they are likely to at least be competent. They may not enjoy it but this does not matter if it is their “job”. Of course, sometimes they are also talented and love it. The point here though is that they are there, doing what needs to be done. FLOSS cannot make the same promises.
When proprietary software is no longer interesting or important to its supplier, it is going to become orphaned by its developers and it may not even be possible for volunteers to step in even if they want to. When FLOSS, at least there is the possibility that somebody could step in. If you rely on the software, at least you have the option that it could be you.
Perhaps the best of all worlds is commercial Open Source. Projects get staffed, we all get to use it, and anybody that relies on it can continue to do so (if they are willing to do that work).
LeFantome,
I agree with pretty much everything you’ve said in the post.
We need more FOSS friendly companies & manufacturers. It’s hard to convince corporations to release their own software as FOSS when software is the product. But when it comes to hardware drivers it seems like they already have a sustainable business model in place: sell the hardware, give away the drivers. The drivers are already “free”, meaning no cost to users. Making the drivers open source would solve a lot of long term hardware support problems.
I strongly favor hardware with FOSS support, my wish is that more manufacturers would actually cater to us.
Not quite so. kurkosdr the upstream project to a Li8nux Distribution normal does not provide the LInux Distribution packaging maintainer.. The major used open source projects make it into Linux Distributions this on average adds 4 more people looking at the code. There is a reason why you see more open source projects on Linux because the distribution maintainer system has resulted in the software developed for Linux being a lot larger team than it first appears.
There is a bug count difference between the windows and linux versions of open source projects that does line up. So I am not sure that the “many eyes makes bugs shallow” is a myth because there is a relationship between number of people looking at the code and the types and number of bugs that is in the code.
kurkosr the 1 to 2 man show is counting just the upstream developers not the downstream people like distribution developers who are also looking at that code. Reality is most small team open source projects have more people looking at the code than most closed source small team because of distribution maintainers looking at the code that most people fail to count.
proprietary software small teams when you truly add up who looking at the code compared to open source small teams are generally smaller. Coverity now made by black duck has been funded quite a few time by USA government to compare code defect rate in open source vs proprietary software. Yes they found open source has a low defect rate and this does align to the fact more people are looking at the code. Yes it about half the number of defects in open source vs proprietary. Yes twice as many defects using proprietary.
Like it or not “many eyes makes bugs shallow” is most likely true point but there is a evil part in the details here. Solo developer vs Solo developer + 4 distribution maintainers the difference is basically 50% the defect rate. Solo developer + 20 distribution maintainers is about 49% of defective rate of the solo developer alone. There is for sure a law of diminishing returns throwing more humans at this problem after you have 4 distribution maintainers. There have been studies on this some went as far as finding projects that had up to 100 outside maintainers there was still small reduction in defect rate. To get to 100 percent defect free just throwing humans at it it was working out to be take the lines of code of the project times this by 10 and that is how many humans you need yes times that by ~`1.9 to get the number of eyeballs looking at the project (yes some people will be blind and some people will be missing eye reason why its not 2). Then you have to manage to this hurd of cats not to have projects forking and other disruptive things.
This is why we need automated code auditing mandated by places like github. Yes instead of a 50-40% reduction in defect rate using humans the automated code auditing can cause a 90%+ reduction in the defect rate. Yes we need machines for code auditing. Yes using more than 1 automated code auditing tools does result in a low defect rate than using a single one. This is the same as using more than 1 compiler effect.
“many eyes make bugs shallow” is most likely not myth from all studies so far into code quality. Yes open source does result in more eyes looking at the code in majority of cases. Problem is the quality of the eyes and the volume you in fact require to get major results.
kurkosdr “There is no “many eyes” for most open-source code. ” this is myth. The majority of open source is shipped by Distributions. Yes this myth comes from just counting developers working on projects not maintainers making the packages for distributions. Yes you look at github with like 2/3 of open source projects having a single developers then you look at how many of those are not some developer prototype fork that number cuts in half. So making it 50/50. Then 90% happens to be items picked up by one distribution or another and this being a different person doing the package than the single developer.
Yes the open source mode of here the source code built it yourself followed by you are too lazy so we have a distribution maintainer build the code for you equals more people looking at the code than the raw developer count. Now the problem is how to improve quality of those eyes now.
oiaohm,
I thought this as well after reading that sentence, however then I read the next sentence where kurkosdr qualifies the reasoning. It’s not the eyes to bugs relationship that’s being questioned so much as the assumption that open source automatically has many people looking at it.
Obviously this varies from project to project, some get a lot more resources and attention than others. Still, some projects do face labor problems and every now and then this can have drastic consequences for the projects involved.
https://en.wikipedia.org/wiki/XZ_Utils_backdoor
Distro maintainers may catch bugs as users report them in testing distros. But if a vulnerability doesn’t otherwise cause a bug/crash, then it’s easier for it to fly under the radar.
Just to be clear though, I don’t consider this a criticism of FOSS projects specifically, rather corporate developers and FOSS developers have these kinds experiences in common. It’s just a consequence of under resourced projects that happen to be FOSS or proprietary when there aren’t enough resources.
1. readers aren’t automatically writers
2. is it really orphaned or have just no people had the time to step forward ?
Well, if things would slow down a little bit, perhaps maintainers would not be under so much stress.
There are millions of new libraries for absolutely everything and my fastest computer, in terms of responsiveness, remains my ThinkPad W530 with FreeBSD and SSD.
There has been tangible progress with things like Wayland and a few others, but we keep reinventing the wheel, and millions of hours of work in the form of code go to trash for little practical (emphasis on practical) benefit.