One thing I was conscious of at FOSDEM was that while there are a lot of us of the (slightly) elderly persuasion, overall most attendees were quite a lot younger than myself.

I'm starting to suspect that the problem isn't really bringing in younger developers as such, it's bringing any developers at all into a mature project. So, over time, mature projects tend to stick with the same core of contributors, which naturally ages.

I'm 28 and this matches my experience.

The problem is that CS education has also diverged from being a pursuit, pushing boundaries and building shit "just because," to "applied computer science" with more business-class busywork, project management, etc. You're not allowed to meander on "dead ends" (unless you're shilling AI) and iterate on stuff, so younger devs are indoctrinated to be less patient with some of the more idiosyncratic elements of FOSS.

Depends on the project.

I was at the Embedded Open Source Summit EOSS2023 in Prague, specifically for the Zephyr developer summit. The demographics there are pretty healthy, a lot of young developers there, maybe because it's a fairly new and fast-moving project.

That said, there is a very high bar to getting code accepted to [1]Zephyr , and for good reason. But the other devs are very helpful with pull requests to get it up to the required standard.

[1] https://docs.zephyrproject.org/latest/

Well, that's really exploitative, and you don't even become rich, most ot the time. As more and more people see some developers getting rich selling their startup to some IT Moloch, I think only people with a religious attitude would choose to sacrifice themselves. Espeically in a society that is become more and more exclusive and costlier.

FOSS is not a sustanable model and doomed to fail.

Absolutely disagree. I contribute to several projects and this regularly sends work my way. If you actually know a real world system inside and out, there are people who want to leverage your knowledge to help introduce it into their work.

Contracts like these tend to work as part development / design, part training developers within the company on the software / mindset of said project.

Been my experience as well. The work on open souces projects themselves may or may not be financially rewarding, your experience with it almost certainly will be. And there has been a change over the last 20 years or so. Back in the early 2000s, companies were, somewhat understandably, wary about engaging in open source and potentially contracting for improvements or changes without ownership . That is no longer the case as many CIOs or CTOs have grown up with open source themselves, appreciate the value is in the openness and are comfortable engaging with developers.

One thing I see as a contributor to a long-existing and large FOSS project is the generational difference in coding styles.

It quite often occurs that contributions from the new generation needs a fair amount of work simply because the younger coders have been taught different styles of coding to older ones.

And for a mature project, everything is in the older style simply due to being written by people who grew up learning such older/established standards.

If the new stuff gets included as-is, then you get issues of readability and debugging, but conversely it's not unknown for newer coders to get disheartened by the requirement to follow standards (especially given the volunteer nature of the contribution, even leaving aside any "ego" thinking that the code is perfect as it works).

And unfortunately I can see tools like ChatGPT and CoPilot potentially making this even worse, or requiring older code to be completely rewritten if it's output does become the new standard.

I'm a long retired coding fossil now, but just during my own career, the conventions changed more than once for how you name variables, functions and subroutines. I've no idea what the conventions are now. It can be a little disorienting reading code written in a different style. Lack of suitable coding comments can be a real issue too with complex code.

"(...) if you're contributing your own code, there is a high bar to clear. It often feels as if you need to surpass whatever the existing functionality is. Just to get accepted, you have to offer something better than some existing product that may have been around for decades."

If you have nothing better to offer than what already exists, what is the value of your contribution?

Contributing where there isn't existing code.

You aren't going to be making a contribution to the Linux kernel, same way as you aren't getting on the C++ standards committee as an intern

But Github is full of niche projects where there isn't an 800lb gorilla.

Especially in small HW, when Linux took off it was still difficult to make small electronics without paying $$$ for dev kits and building your own HW - now with RPi, Arduino , ESP32 etc you can build real world gadgets with a clever idea, $10 at Aliexpress and a dozen lines of embedded python

Adding better test coverage to a particular feature set would be something a lot of projects would benefit from and appreciate, without requiring a huge investment, for example.

Large, well managed projects also often have a "good first issue" tag, which can help people gain familiarity as well.

I think the problem to a certain extent is, particularly with new developers, there is no real guidance to how any of this works, and it will often require reaching out to the developers directly to find out where to begin, which instantly discounts a lot of people nervous to do so.

I think there's also another possible factor to consider. Having offered opportunities for involvement in foss projects both independently and through universities, I've found no young developers have been interested unless [a] it's a mass market or trendy product or [b] there's payment involved. There seems to be no desire for intellectual challenge or recognition of engagement as a path to professional development, just a desire for kudos or dosh.

Is the best way I've found to getting into a project: you're using something and it doesn't do quite what you want or it has a bug. I susepct this is how most people get involved and how you maintainers handle it is key. In my experience, if someone is really interested then they will invest time and effort into learning what is necessary to do. Maintainers can help them along but the real experience of learning how to do something can itsef be rewarding.

But I've also learned to be picky because, unfortunately, there is also a culture of entitlement that means people bitch about stuff but aren't prepared to contribute time and effort to fix things. Basically, they're wasting our time and we could just tell them to fuck off and sometimes that's really the only way: users are not customers.

We recently had a talk about maintaininng SciPy and my advice was that: you can make changes to the API, including breaking it, if you feel they're necessary, you're doing the work and you communicate it properly. Users who want things to stay that way, because they've always been like that, probably aren't worth listening. "Foolish consistency is the hobgoblin on tiny minds" as the Zen of Python puts it.

The article talks about young people having a high bar to submit something new. Most projects that I use have much more need of people to fix bugs, write documentation, etc. than to add yet another half-broken feature hardly anybody wants. (I fix bugs when I can, but some things (e.g. the Xorg input/events layers) are just too hard). It's hard, not always interesting, work.

There are tons of projects out there that younger people have written for fun - games written in Python, home science projects, all sorts of things. A lot of it isn't of great "professional" quality, but so what? Everybody's gotta start somewhere, and complaining that you can't get code into the Linux kernel or some other big name project at the age of 24 is a bit like a newly qualified engineer complaining that they don't get to design a big suspension bridge but have to maintain small unexciting things : you have to earn the experience and prove yourself to progress up to the big stuff.

I suspect a lot of complaining from the younger folks comes from people used to a world of instant online celebrity who feel this should apply to online code contributing too. The older folks complaining about the quality of young people's work have forgotten that they were once young and inexperienced too. Younger folk who are into programming are going to grow older and wiser themselves, and have new ideas and start projects of their own which will have their own successes and failures. They may well develop ideas and practices which feel alien and objectionable to people used to current ones. But this is what progress looks like, and has always been the way of the world.