Why Linux is not attracting young developers(jfplayhouse.com)
jfplayhouse.com
Why Linux is not attracting young developers
http://www.jfplayhouse.com/2010/04/why-linux-is-not-attracting-young.html
15 comments
Can't agree with you more (except I can't buy people beer in the US...). Open source is fun! I've made tons of friends through it, participate in a podcast, and every conference I have awesome people to hang out with.
Apparently this guy would agree:
http://www.theinquirer.net/inquirer/news/1047633/one-writes-...
And you never know if something like that will contribute to the success of the project. It could be that a non-working webcam would be the straw that broke the camels back and sent a newb back to Windows. Lots of people have given up on linux because their hardware didn't work.
And you never know if something like that will contribute to the success of the project. It could be that a non-working webcam would be the straw that broke the camels back and sent a newb back to Windows. Lots of people have given up on linux because their hardware didn't work.
Linux is not attracting young developers because most young developers don't have problems that need solving in the kernel.
The amount of change an individual developer can effect on a project is inversely proportional to the amount of code already written.
The amount of change an individual developer can effect on a project is inversely proportional to the amount of code already written.
The age of a project matters too, I think. If you got into Linux kernel development in 1995, you had no experience, but not many other people did either. If you start becoming active in 2010, you're 15 years behind, and there's no possible way to catch up to someone like Alan Cox or Andrew Morton in influence.
You know both will, someday, retire.
It sounds like the author is reacting to the flood of ooh-shiny iPhone app kiddies that have captured a lot of media attention lately, but I don't think these are the people who would have been attracted to Linux anyway. And I don't think it's fair to lump all this together into an amorphous concept of "Linux" when the problem is a bit more nuanced.
Linux, as a kernel and as a platform, has matured, but there's still plenty of opportunity for new people to explore new territory. Some of it may be extending the existing "boring" infrastructure, which the author seems to blame for turning developers away, but nobody should feel restricted to working on those things. There's still a lot of exciting application development to be done, and as an added bonus, if the platform needs improvements to support your application, you're encouraged to contribute those as well.
Also, if you want a counterpoint, the Arch Linux developers page certainly makes me feel old already: http://www.archlinux.org/developers/
Linux, as a kernel and as a platform, has matured, but there's still plenty of opportunity for new people to explore new territory. Some of it may be extending the existing "boring" infrastructure, which the author seems to blame for turning developers away, but nobody should feel restricted to working on those things. There's still a lot of exciting application development to be done, and as an added bonus, if the platform needs improvements to support your application, you're encouraged to contribute those as well.
Also, if you want a counterpoint, the Arch Linux developers page certainly makes me feel old already: http://www.archlinux.org/developers/
the Arch Linux developers page certainly makes me feel old already
I think this is more reflective of what the "free software" community really is.
I think this is more reflective of what the "free software" community really is.
>Also, if you want a counterpoint, the Arch Linux developers page certainly makes me feel old already: http://www.archlinux.org/developers/
Thanks for making me feel young at 30.
Thanks for making me feel young at 30.
The same list made me feel old at 40. :-(
As the person alleged to having made the initial remark: nobody at the Collaboration Summit panel said that Linux is not attracting younger developers. Every three-month cycle gets contributions from over 1000 developers, many of whom are new to the process. Attracting developers is not the problem.
The thing I was concerned about was the ageing of the core group of subsystem maintainers - who have been doing the same thing for a long time - and whether there was room at the upper levels for up-and-coming hackers. A real concern (though not a huge problem, yet), but a different one.
The thing I was concerned about was the ageing of the core group of subsystem maintainers - who have been doing the same thing for a long time - and whether there was room at the upper levels for up-and-coming hackers. A real concern (though not a huge problem, yet), but a different one.
Is the iPhone to kernel developer comparison really sensible? It's two very, very different skill-sets we are talking about.
I think it is because the learning curve for a kernel is so steep that you will have to spend a lot of time and energy learning the kernel before you can do any significant development. It would have been more meaningful if the author had compared linux attraction to that of any bsd clones. Comparing to iphone is kind of misleading.
At least for KDE it feels like they are on the 3rd or 4th generation of developers. I am not sure how many of the developers from 10 years ago are still around.
Visible, and amusing example of this: last time I went to FOSDEM, a couple years back, they tried to sell me a KDE t-shirt at the booth. (For those outside of the community, icefox and I think both showed up on the KDE radar about a decade ago.)
Though, with the graph that papachito it got me wondering what "active" means. I've done 9 commits in the last year (whereas I used to do several hundred) and suspect I thusly get counted as "active". It might be more interesting to see things computed as something like people above one standard deviation below the mean...
Though, with the graph that papachito it got me wondering what "active" means. I've done 9 commits in the last year (whereas I used to do several hundred) and suspect I thusly get counted as "active". It might be more interesting to see things computed as something like people above one standard deviation below the mean...
Writing drivers is a less appealing than writing small apps regardless of platform.
I've wanted to get involved sometimes, but I always hear only the best developers get actual commits, and I know I am not an amazing programmer so I haven't bothered :(
Your conception is largely false. I can't think of any project I work on regularly that won't give a commit bit to anyone who asks.
But keep in mind, for best success, the order of operations is "step 1. write code. Step 2. ask for commit bit". Sometimes it works the other way, but not as often.
But keep in mind, for best success, the order of operations is "step 1. write code. Step 2. ask for commit bit". Sometimes it works the other way, but not as often.
Of course. It's not that commit access is my goal, it's that I'd want my work to stand a chance of being integrated into the kernel instead of rejected out of hand, and I've never been sure just how much that happens w/ no-names. If it's horrible code, then yes reject it, but besides esoteric drivers it's always seemed like a bit of an old-boys-club to this outsider.
These days having a commit access for occasional contributors is largely unnecessary. Most modern VCSs (i.e. not SVN) can distinguish between the committer and the actual author. This means that regardless of who commits your patch, you still get the full Ohloh-happy credit for your contributions.
Believe me, when you become a regular and valued contributor, the maintainers will gladly grant you the access. It's in their interest: less time to spend on patch reviews and commits, and an additional incentive for you to keep contributing. All sane maintainers care about the growth of their projects.
Believe me, when you become a regular and valued contributor, the maintainers will gladly grant you the access. It's in their interest: less time to spend on patch reviews and commits, and an additional incentive for you to keep contributing. All sane maintainers care about the growth of their projects.
He's not talking about commit access. He's talking about actually having a chance at getting code in, rather than rejected outright.
The entire process is daunting. Here is the problem in a nutshell (or a comment):
1. I have an idea for something. I'd like to code it. First, I want to find if someone is working on it.
2. I try to search the mailing list, but don't find anything. Some things slightly cover it, but most don't.
3. I'd ask in the mailing list, but frankly, I don't want to sound stupid. Besides, talk is cheap, code matters, right? Besides, what I want to code up is small.
4. So I just code it up. I hack it up, and get it to work. Yay! It works for me!
5. So, now I need to send it back in. Hrm, who do I send it to? Lots of emails. Do I submit a bug report and then a patch? I can try that.
5a. Hey look! No one responds to my patch after weeks of sitting there! 5b. Hey look! Someone responded! Yay! They explain briefly that this is the wrong place for the patch. 5c. Hey look! Someone responded! Yay! They ask a question regarding something you have no idea about that possibly relates to your patch and Sparc processors. WTF!?
Here's the thing: open source projects generally make it difficult to contribute easily. This is a good thing. It forces people to truly commit to getting their code live. However, it is also a deterrent. Couple this with piss-poor documentation, and you have a serious problem. I'd love to develop user side apps for Gnome, but honestly, I just don't have the desire to wade through the mountains of misinformation and back and forth. I want to code, not spend time Google searching every 2 minutes.
This is something MS does very well, and why it gets the love of developers. They present an easy way to get up and developing on the MS platform, on any MS platform, with little to no effort. Developers spend their time developing, not installing half a dozen packages and then finding out that they don't have the exact version number of the package they need to have.
Yes, I've contributed to OS projects. I've contributed fixes to problems I've had. Heck, I remember doing some stuff with X to get multihead monitor support in my WM of choice at the time, and sending it in for a fix (not sure what came of it).
A lot of rambling here. I guess it comes down to developers scratching an itch. And since developers who are developing already have an environment setup, there is no need to scratch that itch anymore.
I should point out that most of my OS/Linux days were pre 2005. Mostly 99-2004, and so things probably have changed since then. I just remember the confusion, the lack of direction, etc. Maybe it was my inexperience at the time.
Edit: A good example is: http://live.gnome.org/JoinGnome This is where I was directed on joining Gnome development (from here: http://library.gnome.org/devel/gnome-devel). And currently it's down for me. Maybe it's just coincidence. Ahh, so much fun.
The entire process is daunting. Here is the problem in a nutshell (or a comment):
1. I have an idea for something. I'd like to code it. First, I want to find if someone is working on it.
2. I try to search the mailing list, but don't find anything. Some things slightly cover it, but most don't.
3. I'd ask in the mailing list, but frankly, I don't want to sound stupid. Besides, talk is cheap, code matters, right? Besides, what I want to code up is small.
4. So I just code it up. I hack it up, and get it to work. Yay! It works for me!
5. So, now I need to send it back in. Hrm, who do I send it to? Lots of emails. Do I submit a bug report and then a patch? I can try that.
5a. Hey look! No one responds to my patch after weeks of sitting there! 5b. Hey look! Someone responded! Yay! They explain briefly that this is the wrong place for the patch. 5c. Hey look! Someone responded! Yay! They ask a question regarding something you have no idea about that possibly relates to your patch and Sparc processors. WTF!?
Here's the thing: open source projects generally make it difficult to contribute easily. This is a good thing. It forces people to truly commit to getting their code live. However, it is also a deterrent. Couple this with piss-poor documentation, and you have a serious problem. I'd love to develop user side apps for Gnome, but honestly, I just don't have the desire to wade through the mountains of misinformation and back and forth. I want to code, not spend time Google searching every 2 minutes.
This is something MS does very well, and why it gets the love of developers. They present an easy way to get up and developing on the MS platform, on any MS platform, with little to no effort. Developers spend their time developing, not installing half a dozen packages and then finding out that they don't have the exact version number of the package they need to have.
Yes, I've contributed to OS projects. I've contributed fixes to problems I've had. Heck, I remember doing some stuff with X to get multihead monitor support in my WM of choice at the time, and sending it in for a fix (not sure what came of it).
A lot of rambling here. I guess it comes down to developers scratching an itch. And since developers who are developing already have an environment setup, there is no need to scratch that itch anymore.
I should point out that most of my OS/Linux days were pre 2005. Mostly 99-2004, and so things probably have changed since then. I just remember the confusion, the lack of direction, etc. Maybe it was my inexperience at the time.
Edit: A good example is: http://live.gnome.org/JoinGnome This is where I was directed on joining Gnome development (from here: http://library.gnome.org/devel/gnome-devel). And currently it's down for me. Maybe it's just coincidence. Ahh, so much fun.
I'm surprised no one here has mentioned what I see as pretty obvious.
Startups are perceived as the quick way to fame and fortune.
There are not a lot of apparent Startup opportunities in the kernel space.
Startups are perceived as the quick way to fame and fortune.
There are not a lot of apparent Startup opportunities in the kernel space.
[deleted]
I don't checkout Linux source because I don't have the skills to ...ooo look at that shiny app.
He's comparing KDE and Gnome core components (window management) and the linux kernel with developing iPhone apps. That's a bad comparaison in my opinion. Hacking on an operating system kernel or a window manager requires great skills that most kids (and adult devs) do not have.
A fair comparison would be iPhone apps Vs KDE or Gnome apps. And here KDE and Gnome get tons of new contributers each months, check how active is http://kde-apps.org for example, or the Ubuntu developer activities. Tasks that require less skills will always attract more developers or cooks or whatever in all professions.
Here's a Graph of KDE contributers http://dot.kde.org/2009/07/14/growth-metrics-kde-contributor... up to July 2009. As a KDE dev that follows the mailing list, I can tell you the list of contributers is still groing well. Not to mention all the people that build KDE apps without being official KDE devs.
A fair comparison would be iPhone apps Vs KDE or Gnome apps. And here KDE and Gnome get tons of new contributers each months, check how active is http://kde-apps.org for example, or the Ubuntu developer activities. Tasks that require less skills will always attract more developers or cooks or whatever in all professions.
Here's a Graph of KDE contributers http://dot.kde.org/2009/07/14/growth-metrics-kde-contributor... up to July 2009. As a KDE dev that follows the mailing list, I can tell you the list of contributers is still groing well. Not to mention all the people that build KDE apps without being official KDE devs.
Without reading the article i can say that the following reasons are not attractive for young developers:
1. They have to read tons of documentation and cant use a 2 lines tutorial 2. They have to know byte compiled languages 3. They have to know lot of internal stuff to use linux the good way
The point is, everything which is hard to understand and cant be learned within 8 hours sucks... thats the way most younger people think about developement because they have no motivation at all to be a part of a long growing environment.
Hate me now ;)
1. They have to read tons of documentation and cant use a 2 lines tutorial 2. They have to know byte compiled languages 3. They have to know lot of internal stuff to use linux the good way
The point is, everything which is hard to understand and cant be learned within 8 hours sucks... thats the way most younger people think about developement because they have no motivation at all to be a part of a long growing environment.
Hate me now ;)
Thinking about all the software I use regularly, I know pretty much all the authors. Some of them I have even met in person, and they have gotten free beer as a result.
I guess if you are outside the community, it doesn't seem very exciting, but if you are in the community, it is exciting. Kind of the opposite of high school cliques...