Every volunteer group eventually starts to look alike.
This is as it was explained to me over a decade ago, and I don’t really need to change much since human nature doesn’t change very fast, and this holds for all the groups I’ve belonged to.
You get a lot of young adults who have more time than money. Their contributions are energetic but often short lived. They move away, their sense of self shifts away from the cause, their lives get too complicated, or they overdo it. It’s the people who pace themselves that avoid burnout. The trap is caring so much about a cause that they hurt themselves and have to step back. You get a smaller number of generally older regulars who keep the wheels on, and you have a few old timers who remember all the way back to the beginning. What has been tried. Who we have collaborated with or gotten donations from in the past.
So attract your volunteers, identify and groom some for small leadership roles. But make sure not to overload them, and encourage them to set healthy boundaries. It’s keeping them that kills many orgs. Though some only focus on retention and become an echo chamber of greybeards. I don’t believe Linux has that problem. Yet.
Getting smart young people to contribute to Linux Distros (and BSD for that matter) to me is a tough job.
Linux kicked off in the 90s because young people at that time wanted a real OS, so Linux came out and people flocked to improve it.
Today, almost all kids use Cell Phones, which are all locked down. I think only a few young kids rely on PCs, thus the issue. I hope it can be solved at some point and good contributors can be found. Otherwise we will be left with just IBM Red Hat.
I suspect the same number of people want a real OS as before, the difference is that everyone now has an OS of a weaker kind that gives them access to the same web that we're all on. So it's a similar problem that we have on the web as a whole—it's not that there's less good content (there's actually dramatically more), it's that it's hard to find it in the deluge of bad content.
The trick that we have now is that young people with potential to be highly technical won't just come to us automatically like they did when we were 60% of the web. Instead we have to make a more conscious effort to do outreach and give people a taste of the power of real computing.
I agree with your assumption that there’s the same number of people who want a real OS as there ever was.
However, I believe there are more active distros and related highly-technical projects today than ever. So everyone has to share fewer contributors, except of course whatever the few hot/popular projects are (the latter is nothing new).
I do worry though. Major academic institutions are having to put freshmen in remedial computer classes to teach them what files, folders, and devices are.
The average persons is getting farther and farther away from an actual PC and deeper into the “app” world. Everything is moving to “the cloud”. Even software development is being pushed to virtual desktops/thin clients (look at GitHub workspaces [or whatever it’s called] as an example). The extremely large majority of software development today is web/cloud based. There are more and more of the non-technical buying “computers” that are really just glorified tablets.
At some point, likely not/hopefully not in our lifetimes, it could become unprofitable for manufacturers to build PCs or only a few remain and the costs become prohibitively expensive to anyone but for-profit companies/corps.
There are still a bunch of young ones on PCs because of gaming, unfortunately the gaming scene is chiefly on Windows. Proton and Steam Deck were improvements, but the market share is still heavily leaning towards Microsoft.
Maybe if things get better we could see a steadily increase in Linux users, as we are already seeing
> Getting smart young people to contribute to Linux Distros (and BSD for that matter) to me is a tough job.
I mean, they came with enthusiasm and a lot of hard work, brought a new language with many advantages (as said by the BDFL humself), dusted off the whole GPU stack, tried to formalize a bit the FS systems, then got shunned out by the greybeards because “muh youngsters and their religion”.
That's not really a fair representation of the argument, and the stereotyping of everyone who disagrees or expresses some caution as an old stubborn greybeard who refuses to learn anything new is exactly the thing people (rightfully) complain about.
Rust on Linux will happen. One way or another. At the worst, one funeral at a time. I wouldn’t sweat it.
I remember a HN comment that I really liked and can’t find now that went something like:
You know what stopped me from programming? It wasn’t that I didn’t have a good computer. It wasn’t that I started later than all the other kids. It wasn’t that I had to work. Nothing. Nothing stopped me from programming.
There’ll always be folks like that. And I hope I’ll be like that for some thing too!
> Linux kicked off in the 90s because young people at that time wanted a real OS
It's easy to underestimate how inferior MS-DOS was, unless you lived through it. Windows (3.x and later 9x) was slightly better, but still had severe issues. Modern Windows is, from what I've heard, a lot better, so the incentive to migrate is not as strong.
> Today, almost all kids use Cell Phones, which are all locked down.
Not just cell phones; with Secure Boot and BitLocker, computers are more locked down too. In particular, BitLocker means that it's harder to share disk space between Windows and an alternative operating system; back in the MS-DOS (and Windows 9x) days, it was not unusual to install Linux in a directory (or a disk image file) on the same partition used by the other operating system.
> Not just cell phones; with Secure Boot and BitLocker, computers are more locked down too.
You can just disable secure boot, no? I just got a brand new laptop today, and I could just disable it. I know you can get Linux to work with it, but I can't be arsed to mess about with it and the practical security benefits for me are basically zero.
Also, don't underestimate the friction that existed in the 90s or early 00s. Nothing worked on Linux or BSD. My government sent me .doc files. Tons of stuff was Windows-only desktop software.[1] Mucking about with xfree86 -configure and /etc/X11/.... was far from easy or straight-forward. Internet access was far more rare and "just Google it" wasn't really a thing, etc. etc. etc.
If I look at the amount of effort I spent to "just get Linux running" back in 2000 or so when I first tried it vs. today, then I'm fairly sure the overall experience is a lot better today. Sure, you need to deal with some stupid nonsense, but that was always the case.
[1]: For all the hate the "modern web" gets from some people here: it does replace tons of crappy desktop stuff with an abstracted isolated VM which, among other benefits, makes running "alternative" systems like Linux or BSD far more viable.
Debian losing contributions is a fairly big deal because Debian and its derivatives represent the most popular Linux distributions.
You'd think Canonical would contribute more...
I think there's also a larger conversation of what folks really need from a Linux distribution in the year 2020+. Desktop Linux is fairly needy but AppImage and flatpak have largely fixed that.
Do we want canonical that involved in our beloved Debian? Look at what they did to glorious Ubuntu, if they think Snap is a good addition to any OS then should we listen to their input?
Context: I have +10y exp with Python, Linux (some packaging, kernel hacking, sys admin / SRE), C, several cloud providers (AWS, Azure, Hetzner, DO, OVH), etc...
Applied to a Canonical position (Senior Python Eng + required Linux exp + nice to have cloud knowledge), got rejected automatically because I don't have a university degree.
Tweeted about it, asking for some feedback. Tons of replies, same opinion: Canonical are plain elitists.
How much is enough? Did you know that significant contributions to Debian are made by Canonical employees who are Debian Developers being paid to do so?
As a recent example, Debian's recent 64 bit time_t transition was driven by Canonical employees. Canonical employees continue to maintain various packages in Debian, but it's not obvious because they use their Debian "hats".
From my point of view it doesn't seem like really appreciate the Debian-style integrated self-contained OS model; what people want (these days) is more just a platform to run 3rd party applications. It is easy to see why some people see Debian more just getting in the way rather than being an asset.
Part of the problem might be that Debian is something for everyone, and has cast a very wide net in terms of packages. Especially not all packages are all that integrated to the whole, or follow Debian guidelines very closely. I don't know if it would help if Debian would tighten ship, raise the bar for packages and cull more aggressively some of the less maintained ones. Although on the flip side one of the big advantages of Debian is its vast package archives so its a balancing act.
Regarding the language aspect, that is the focus for much of the article, while I think local communities working in their native languages is definitely good thing ultimately I believe that any potential Debian contributor needs to be somewhat fluent in English. Debian is communal project after all and I imagine all the official discussions happen in English; its difficult to see someone being effective contributor if they can not communicate comfortably in community.
I'm not qualified to comment on the larger Debian ecosystem, but having been forced (due to work) to create some Debian packages... the tooling is awful. Packages are two(?) layers of tarballs, there's the option of free-form shell scripts in there to do whatever as a pre/post-install step, etc. etc. There's even several ways to try to hide some of that awfulness under the carpet, and yet it's still there.
If they want to attract people who care in the least about developer experience they'll need to consolidate and fix their package system and tooling.
Personally I have given up on Debian packaging. Work applications get shoved into /opt and configured via Ansible, and desktop systems run other distributions with simpler packaging formats (with internal or home stuff wrapped into proper packages).
I've thought about alternatives for the servers, but Alpine et al have their own issues. Nothing has been decided yet.
I can't find it now, but I read something just a few days ago saying that some prominent Debian members very much want to see the development/maintainership experience of the OS modernized and improved. They are suggesting (but not demanding) that packages be maintained by teams rather than individuals, manage source packages on Debian's own Gitlab instance, accept issues and PRs via Gitlab, better CI and testing infrastructure for packages, and so on.
I respect the fact that current Debian development practices have carried the OS this far, but lowering the barrier to entry for volunteers to help maintain the OS going forward could only be a good thing.
Lowering the bar to entry in software can absolutely be a bad thing in a wide range of ways.
The most obvious in the current context is possibly well intentioned amateurs proposing LLM generated patches for the usual developers to fritter away their time on until patience runs out.
I made my own custom packages for Alpine Linux and Arch Linux for personal use. It is so easy that I am honestly I'm not seeing the point in doing things the way Debian does it. It just makes things unnecessarily difficult for no reason.
What does a maintainer realistically do?
He builds the software, so you expect that the package builder automatically installs the development dependencies and runs the build software inside a chroot.
In case the software requires modifications, there needs to be a way to deliver patch files or additional files that aren't part of the original software or at least a standard location to store the distro specific fork that everyone agrees on.
Once the software is built, the maintainer creates a directory structure that conforms to the distributions's conventions, adds things like systemd unit files or desktop shortcuts and other distro specific changes that exist outside the software.
I would encourage everyone to at least give Alpine or Arch Linux packaging a try. It really is quite easy. Almost as easy as writing a docker file.
Debian maintainers have to coax upstream packages to behave like other Debian packages and use supported linked dependencies. This covers everything from log and config file locations, startup scripts patching dependencies to match the versions supported by the release, backporting security updates, and documenting.
I trust Debian (and in turn Debian maintainers) more than I trust the upstream developer of lib-random-4-dev. I only ever had to build a custom package from source a handful of times.
I agree and add Void Linux to the list in the same vein.
Generalley, ports-like package repos (all package build recipes in one repo) are really beneficial for large-scale operations or simply rollbacks.
Being able to bootstrap the distro from a git repo and a well-defined set of bootstrap tools is really nice. try that with debian.
See Void Linux and Alpine for a simple, yet refreshing aproach to distro package maintenance, with low overhead.
It's easier because you get a sane shell instead of a poor reimplementation of a tiny subset of one.
I maintain many aur packages, and wrote the first one in half an hour, knowing nothing about Arch packaging at the time. Now it takes me maybe 5-10 minutes to package a small application that adheres to the standard conventions.
I spent maybe two days on my first Debian package. It was also the last one (not really, but almost so).
I'm very conflicted, because Debian's strength is the intensity of package maintainership, but it's weakness is the intensity of package maintainership. Debian has a strong focus on being a in-group culture, believes in maintainers as strong operators over their fiefs, with freedom to operate in manners they like, usually with little support or help.
I do think there would be a lot of help that would show up, a lot of drive by contributions. And some people actively converting to maintainership that wouldn't have. But at the risk of a lot of people being able to help, without acculturating onto Debian, contributing more without becoming a full maintained.
My only real Debian developership attempt was a go at packaging wayvnc a long time ago, and it's deps, well before it was available. Seems fairly straightforward, but I felt very unwelcome when I tried to ask about finding a maintainer or getting mentorship; it was a long time ago so I don't fully remember, but it was pretty discouraging and experience having re-learned so much about Debian & having some the deeds, only to feel turned away for unclear reasons.
The problem with these large open source projects is that they are already on maintenance mode and the fun part has already been done a long ago. Who wants to work for months doing menial tasks so that when they "graduate" they can start doing maintenance.
Truly. God bless the maintainers and we couldn't do it without them, but I cannot imagine myself sitting down on the weekend to do maintenance on a 20yo disk partition utility or something.
Readit News
This is as it was explained to me over a decade ago, and I don’t really need to change much since human nature doesn’t change very fast, and this holds for all the groups I’ve belonged to.
You get a lot of young adults who have more time than money. Their contributions are energetic but often short lived. They move away, their sense of self shifts away from the cause, their lives get too complicated, or they overdo it. It’s the people who pace themselves that avoid burnout. The trap is caring so much about a cause that they hurt themselves and have to step back. You get a smaller number of generally older regulars who keep the wheels on, and you have a few old timers who remember all the way back to the beginning. What has been tried. Who we have collaborated with or gotten donations from in the past.
So attract your volunteers, identify and groom some for small leadership roles. But make sure not to overload them, and encourage them to set healthy boundaries. It’s keeping them that kills many orgs. Though some only focus on retention and become an echo chamber of greybeards. I don’t believe Linux has that problem. Yet.
Linux kicked off in the 90s because young people at that time wanted a real OS, so Linux came out and people flocked to improve it.
Today, almost all kids use Cell Phones, which are all locked down. I think only a few young kids rely on PCs, thus the issue. I hope it can be solved at some point and good contributors can be found. Otherwise we will be left with just IBM Red Hat.
The trick that we have now is that young people with potential to be highly technical won't just come to us automatically like they did when we were 60% of the web. Instead we have to make a more conscious effort to do outreach and give people a taste of the power of real computing.
However, I believe there are more active distros and related highly-technical projects today than ever. So everyone has to share fewer contributors, except of course whatever the few hot/popular projects are (the latter is nothing new).
I do worry though. Major academic institutions are having to put freshmen in remedial computer classes to teach them what files, folders, and devices are.
The average persons is getting farther and farther away from an actual PC and deeper into the “app” world. Everything is moving to “the cloud”. Even software development is being pushed to virtual desktops/thin clients (look at GitHub workspaces [or whatever it’s called] as an example). The extremely large majority of software development today is web/cloud based. There are more and more of the non-technical buying “computers” that are really just glorified tablets.
At some point, likely not/hopefully not in our lifetimes, it could become unprofitable for manufacturers to build PCs or only a few remain and the costs become prohibitively expensive to anyone but for-profit companies/corps.
Hopefully that’s a pessimistic outlook.
Maybe if things get better we could see a steadily increase in Linux users, as we are already seeing
Something that I hope dies off in the next decade is corporations leeching off of passionate volunteers doing free work.
I mean, they came with enthusiasm and a lot of hard work, brought a new language with many advantages (as said by the BDFL humself), dusted off the whole GPU stack, tried to formalize a bit the FS systems, then got shunned out by the greybeards because “muh youngsters and their religion”.
I remember a HN comment that I really liked and can’t find now that went something like:
You know what stopped me from programming? It wasn’t that I didn’t have a good computer. It wasn’t that I started later than all the other kids. It wasn’t that I had to work. Nothing. Nothing stopped me from programming.
There’ll always be folks like that. And I hope I’ll be like that for some thing too!
Dead Comment
It's easy to underestimate how inferior MS-DOS was, unless you lived through it. Windows (3.x and later 9x) was slightly better, but still had severe issues. Modern Windows is, from what I've heard, a lot better, so the incentive to migrate is not as strong.
> Today, almost all kids use Cell Phones, which are all locked down.
Not just cell phones; with Secure Boot and BitLocker, computers are more locked down too. In particular, BitLocker means that it's harder to share disk space between Windows and an alternative operating system; back in the MS-DOS (and Windows 9x) days, it was not unusual to install Linux in a directory (or a disk image file) on the same partition used by the other operating system.
You can just disable secure boot, no? I just got a brand new laptop today, and I could just disable it. I know you can get Linux to work with it, but I can't be arsed to mess about with it and the practical security benefits for me are basically zero.
Also, don't underestimate the friction that existed in the 90s or early 00s. Nothing worked on Linux or BSD. My government sent me .doc files. Tons of stuff was Windows-only desktop software.[1] Mucking about with xfree86 -configure and /etc/X11/.... was far from easy or straight-forward. Internet access was far more rare and "just Google it" wasn't really a thing, etc. etc. etc.
If I look at the amount of effort I spent to "just get Linux running" back in 2000 or so when I first tried it vs. today, then I'm fairly sure the overall experience is a lot better today. Sure, you need to deal with some stupid nonsense, but that was always the case.
[1]: For all the hate the "modern web" gets from some people here: it does replace tons of crappy desktop stuff with an abstracted isolated VM which, among other benefits, makes running "alternative" systems like Linux or BSD far more viable.
BitLocker is completely optional, even on Windows 11 (although in some cases encryption does kick in automatically - but you can revert it).
And if you want to both use BitLocker and share files with another OS, you can easily do it with a separate unencrypted drive or partition.
You'd think Canonical would contribute more...
I think there's also a larger conversation of what folks really need from a Linux distribution in the year 2020+. Desktop Linux is fairly needy but AppImage and flatpak have largely fixed that.
They've been there for 20 years already.
Context: I have +10y exp with Python, Linux (some packaging, kernel hacking, sys admin / SRE), C, several cloud providers (AWS, Azure, Hetzner, DO, OVH), etc...
Applied to a Canonical position (Senior Python Eng + required Linux exp + nice to have cloud knowledge), got rejected automatically because I don't have a university degree.
Tweeted about it, asking for some feedback. Tons of replies, same opinion: Canonical are plain elitists.
Don't expect them to contribute.
How much is enough? Did you know that significant contributions to Debian are made by Canonical employees who are Debian Developers being paid to do so?
As a recent example, Debian's recent 64 bit time_t transition was driven by Canonical employees. Canonical employees continue to maintain various packages in Debian, but it's not obvious because they use their Debian "hats".
Part of the problem might be that Debian is something for everyone, and has cast a very wide net in terms of packages. Especially not all packages are all that integrated to the whole, or follow Debian guidelines very closely. I don't know if it would help if Debian would tighten ship, raise the bar for packages and cull more aggressively some of the less maintained ones. Although on the flip side one of the big advantages of Debian is its vast package archives so its a balancing act.
Regarding the language aspect, that is the focus for much of the article, while I think local communities working in their native languages is definitely good thing ultimately I believe that any potential Debian contributor needs to be somewhat fluent in English. Debian is communal project after all and I imagine all the official discussions happen in English; its difficult to see someone being effective contributor if they can not communicate comfortably in community.
If they want to attract people who care in the least about developer experience they'll need to consolidate and fix their package system and tooling.
Apparently the solution is to write yet another automation utility:
https://people.debian.org/~nthykier/blog/2023/a-new-debian-p...
Personally I have given up on Debian packaging. Work applications get shoved into /opt and configured via Ansible, and desktop systems run other distributions with simpler packaging formats (with internal or home stuff wrapped into proper packages).
I've thought about alternatives for the servers, but Alpine et al have their own issues. Nothing has been decided yet.
I respect the fact that current Debian development practices have carried the OS this far, but lowering the barrier to entry for volunteers to help maintain the OS going forward could only be a good thing.
The most obvious in the current context is possibly well intentioned amateurs proposing LLM generated patches for the usual developers to fritter away their time on until patience runs out.
What does a maintainer realistically do?
He builds the software, so you expect that the package builder automatically installs the development dependencies and runs the build software inside a chroot.
In case the software requires modifications, there needs to be a way to deliver patch files or additional files that aren't part of the original software or at least a standard location to store the distro specific fork that everyone agrees on.
Once the software is built, the maintainer creates a directory structure that conforms to the distributions's conventions, adds things like systemd unit files or desktop shortcuts and other distro specific changes that exist outside the software.
I would encourage everyone to at least give Alpine or Arch Linux packaging a try. It really is quite easy. Almost as easy as writing a docker file.
Debian maintainers have to coax upstream packages to behave like other Debian packages and use supported linked dependencies. This covers everything from log and config file locations, startup scripts patching dependencies to match the versions supported by the release, backporting security updates, and documenting.
I trust Debian (and in turn Debian maintainers) more than I trust the upstream developer of lib-random-4-dev. I only ever had to build a custom package from source a handful of times.
Generalley, ports-like package repos (all package build recipes in one repo) are really beneficial for large-scale operations or simply rollbacks. Being able to bootstrap the distro from a git repo and a well-defined set of bootstrap tools is really nice. try that with debian.
See Void Linux and Alpine for a simple, yet refreshing aproach to distro package maintenance, with low overhead.
It's easier because you get a sane shell instead of a poor reimplementation of a tiny subset of one.
I maintain many aur packages, and wrote the first one in half an hour, knowing nothing about Arch packaging at the time. Now it takes me maybe 5-10 minutes to package a small application that adheres to the standard conventions.
I spent maybe two days on my first Debian package. It was also the last one (not really, but almost so).
There's been suggestions - ideas that maybe Debian should be a little more open to outside contributors, should have ci/CD tools & accept PRs more publicly. https://salsa.debian.org/dep-team/deps/-/merge_requests/8
I do think there would be a lot of help that would show up, a lot of drive by contributions. And some people actively converting to maintainership that wouldn't have. But at the risk of a lot of people being able to help, without acculturating onto Debian, contributing more without becoming a full maintained.
My only real Debian developership attempt was a go at packaging wayvnc a long time ago, and it's deps, well before it was available. Seems fairly straightforward, but I felt very unwelcome when I tried to ask about finding a maintainer or getting mentorship; it was a long time ago so I don't fully remember, but it was pretty discouraging and experience having re-learned so much about Debian & having some the deeds, only to feel turned away for unclear reasons.