Why Linux Is Not Attracting Young Developers

judeancodersfront writes "Jonathan Corbet recently pointed out at the Linux Foundation Collaboration Summit that the Linux kernel team was getting older and not attracting young developers. This article suggests the Linux kernel no longer has the same appeal to young open source developers that it did 10 years ago. Could it be that the massive code base and declining sense of community from corporate involvement has driven young open source programmers elsewhere?"

Comments

older developers...

[mayberry42]

would also imply more experienced developers. And that's not (necessarily) a bad thing.

Re:older developers...

[Magic5Ball]

The bigger problem appears that CS programs now focus on teaching tools and how to Google as opposed to thinking or problem solving, in order to meet perceived industry demand. In industry, I've had to teach too many youngling graduates about basic data structure and database concepts, memory and hardware addressing, protocol encapsulation, AAA, synchronous vs asynchronous operation, and other fundamentals which would be needed to understand why things such as kernels are implemented as they are. The way in which FOSS support forums and listservs generally respond to noob developer and user questions--some variation of RTFS without providing a way of understanding which documentation to read--does not invite exploration of concepts embedded in the current software architecture, let alone ways to identify entry points into interesting sub-components. This is a barrier since popular CS program tools to which students are exposed, such as RHEL, gcc, etc. are provided as finished products in the same way as Access or BOS.

Separately, I have a dream where all of the Alans Cox get together to write an operating system.

Re:older developers...

[Magic5Ball]

> Maybe it's because there are basically ZERO jobs in most places for real hard-core CS.

There are close to zero jobs for hard-core anything, but that's not the goal of earning or producing a BA/BSc in CS.

The most important goal of a university degree program is to teach students how to think critically, how to evaluate and apply information, and how to perceive and act professionally outside themselves. Theoretical knowledge is helpful not because industry does a lot of relational algebra or computability analysis directly, but because CS graduates should be able to make a critical business case that an Oracle implementation would be better/worse than a Sybase implementation for a particular use.

Local technical/trade school graduates can and should easily out implement degree holders in identical fields. If the post-secondary education market is segmented ideally, CS graduates should be have the knowledge and conceptual tools to run rings around technical graduates in terms of understanding and designing principles and solutions in a broader corporate or societal context. As it stands, recent crops of technical graduates seem to understand more about both what they're doing locally, how they got there, and why they're doing it in the community, than the CS graduates who seem weak with both theory and implementation. Some of my colleagues have been seeking out CCNAs, biologists, and ex-military officers, and training them to program because they have better tools to understand systems and business context than recent CS graduates (who /should/ be able to apply the "science" part of their tools to figure it out).

Relating this back to the Linux kernel, good luck finding a recent CS graduate who understands that MPLS exists, let alone one who can grok the concept (let alone specifications) well enough to understand why Linux will want to support MPLS if it wants not to be locked out of an important part of the enterprise market relating to the current network neutrality debate. (Incidentally, I've pointed some international relations friends at the Wikipedia page who understood the consequences immediately.)

Perhaps there should be a return from quantity to quality in undergraduate CS programs.

Re:older developers...

[Blakey Rat]

Separately, I have a dream where all of the Alans Cox get together to write an operating system.

Yeah, they'd spend 5 years perfecting every single line of code for the USB subsystem. Meanwhile, nobody cares because the optimizations from those 5 years were completely leap-frogged by hardware improvements, and normal people want an OS that they can use to get shit done.

Sometimes I think the concept of "pragmatism" is entirely absent from this field.

bad attitudes

[Anonymous Coward]

Maybe it's because a lot of devs from the 90s were and are quite rude due to their lack of social skills. Most people don't put up with that kind of crap.

Re:bad attitudes

[mc moss]

I know a few people who have been turned away from Linux whenever seeking help online from linux users. The whole "you're stupid if you can't figure it out" attitude by some users is really off-putting.

Considered a solved problem?

[Geirzinho]

Could it be that since Linux has become somewhat mainstream kernel developement is considered a "solved problem" to young programmers looking for an interesing project? Maybe new programmers are tackling other open source problems instead.

Age is the reason

[taleman]

Perhaps age difference itself is the reason. Young persons may not like the 20 years older hackers. And old wizened developers may dislike young whippersnappers.

What about the barrier to entry?

[krelian]

Contributing to and old and large code is much more difficult than contributing to a small one. Getting your head around a large code base is no small task and documentation is often lacking. Even if the code is well commented it could be very difficult to understand the overall design of the software and how things interact with each other.

Programming job bad reputation

[The Abused Developer]

that's all folks - the youngsters are much more socially connected and skilled than we were at their age; also, they get the clue of the social context much better than we did 15 years ago. And what they see is a career in an unregulated domain, totally havoc and chaotic, where the abuse and the overwork is the norm. there is no career path marks to follow and nobody can tell you where you going to be in 2 or 3 years. A continuously changing professional knowledge baggage is not attractive, its consequence is obvious - your whole time life should be allocated for keeping up. The dreamland of computing is not anymore there - the harsh reality has taken its place and young people are not stupid; they want to be able to enjoy their life normally instead to enslave to the corporate. 15 years ago the Linux and the Open Source was started with lots of fuel from people keeping strong to a beautiful idealism - this is gone; they are not to blame - myself I have respect for a generation who has the power of the dignity and the will to say NO! STOP! this is my life! - we should all do the same.If a profession takes away your life - forget it, it's just not wort it.

A couple of things going on here

[PPH]

First, it takes a certain amount of financial security before most people are willing to contribute their time to any effort. I think this is true for everything from the Linux kernel to Habitat for Humanity projects.

Second, this greybeard phenomena is occurring throughout not only the entire s/w industry, but other technical fields in the USA as well. Not enough CS majors, engineers, scientists, etc. Math literacy is suffering and practically every company is screaming for more H1B visas. Or just sending the work offshore.

Finally, some of the noteworthy exceptions to this trend (Microsoft, for example. But also many other big corporations) have an ulterior motive behind keeping their staff green. Hire CS grads straight out of college, put them on a couple of projects and get them built. Once your developers start to get some industry experience and a peek at the big picture of the company, they'll start to second guess management decisions. Out the door with them and bring in some fresh meat.

Monolithic Kernel = Death of Self-Teaching

[mosel-saar-ruwer]

Have any of you guys ever looked at a picture of the Linux kernel?

My best guess [and I am not trying to be facetious] is that unless you were in on kernel development in the very early days [so that you had some hope of learning it when it was still tractable], then the thing has gotten so big now [what is it - like 20,000 files which get compiled in the basic kernel?], and the learning curve has gotten so steep, that no new developers have any realistic hope of grokking it anymore.

Seriously - at this point, just learning the kernel would be akin to a 6- or 8-year PhD project [in something like a Department of Archaeology, studying ancient Egyptian hieroglyphics].

Re:Monolithic Kernel = Death of Self-Teaching

[Anonymous Coward]

Yeah... sorry. In-depth documentation written by a novice is worse than no documentation at all. Not only that, it will take about one hundred times the amount of time to write. Kernel developers should be writing the majority of it. It's simple work ethic, little different from maintaining code quality, and is beneficial for other reasons, such as aiding in design (documentation before code).

Re:What does Linus always say?

[ShinmaWa]

I still use Emacs proudly. I find big bloaty IDEs like Eclipse get in the way

Really, the only thing you are saying here is that you like YOUR big, bloaty thing over someone else's big, bloaty thing. There's really nothing insightful about that at all.

You have a set of tools you are comfortable with, and others have theirs. Each have their merits and each have their drawbacks. What is new is not necessarily an improvement and what is old is not necessarily the best. To discard either out of hand on their "whiz-bangedness" or "tried-and-truedness" rather than on its merits is the mark of a fool.

Re:What does Linus always say?

[Anonymous Coward]

You are confused. One minute you claim long winded text entry for 30 years beat tools designed to replace the drudgy or trivial stuff is better, then you claim you write noddy script to toy server duties. A developer, as it a real developer and not some perl dweeb, doesn't touch server admin. So what is it? I suspect you're a low skilled UNIX package user that's been using packages for your job, but you dabble in code for trainee level work.

IDEs have a place, they can get the cruft out of the way, if you're development time is cheap, you're not a real developer. Get back to your 10 line "scripts".

Re:What does Linus always say?

[BitZtream]

A developer, as it a real developer and not some perl dweeb, doesn't touch server admin.

The best C developers I know, are or were admins at one point.

Writing software for servers is a fuckton easier when you actually understand what a server does and what goes on from the admin point of view.

A decent developer that understands administration if FAR better than some hot coder that doesn't have the security insight of a gnat.

You know at those 'BIG' sites you see on the Internet ... facebook, wikipedia, myspace, google ... guess what ... All of their senior level developers ... regularly play admin as well to deal with large problems.

I'm going to have to wager that you are a developer with no admin experience and little actual development experience since you don't recognize something thats pretty common.