There are certainly many more projects out there, increasing the “breadth” (acceptance) of the Open Source and Linux community, but as you have all mentioned, not really increasing the “depth” (killer app) of the Linux community. Hit Freshmeat and see how many new toolkits, bindings, php-based “forum” applications, web mangling tools, etc. show up daily. Dozens. This is how the “new and nimble” are penetrating into the Open Source and Linux communities. They may not be able to write a Mozilla replacement, but they can prove they understand code (in some cases), the licensing, their peers, and how to get their name out there.
The point that’s missing, is that back when we all got started in the early to mid 90’s with Linux, it was easy to know everyone that was doing it. You knew who Linus was. You knew who RMS was. You knew the key people responsible for making it happen. You could email them. They would respond. But more importantly, you could easily contribute to their projects. Patches and suggestions were implemented almost by design, rote.
Now however, the bar has been raised by quite a few notches. It’s much, much harder to get a patch accepted to the Linux kernel than it was 5 years ago.
Let’s look at the PHP project for example; when it was authored, it was successful. It filled a growing need (and still does today), and it was used by thousands of people. If that project were to have started this year, it would have been buried under the “noise” of the other thousands of “web mangling” applications out there. It would take much longer to grab hold of the market it
currently has. It may not have even been a successful project, certainly not like it is today.
The fallout of the “bar” being higher for acceptance, and that the older projects still move forward, is that new users don’t know where to contribute. And as lkcl said, maybe they don’t have the skills to take on the project or task they want to use or contribute to. New Open Source and Linux community members are actually afraid to contribute because they fear being shunned, ousted, or humiliated publically for their patches, code, suggestions. We need to nurture those new users, new contributors. As we age and elder, we have to begin connecting people who we believe can take the project(s) forward. Assign like people to like tasks, make sense of the noise, and act in a more “educational” role than a “physical” role. Once they get it, they’ll get it.
One of my own projects has recently fallen under this spell. I have found some skills that I lack, and have been trying to make a call out to those who I believe can help, both in code and in testing. Some have responded, some have hinted that they can help, and the majority of others have indicated they just don’t know where to begin, but they would if they had that answer.
I’ve been taking steps to clean up my codebase, documentation, and even the way I respond to people on related mailing lists, so that the “vision” behind that particular project remains clear and focused, and that there are enough little compartmentalized sections that people who wish to contribute are not being asked to eat the elephant. The people who are here and know what I’m talking about know, because I’ve been plugging person A into person B, on task C, and so on. When I see a need, I find a person that I believe can fill it, or at least guide another person into that hole. It’s worked well.
That’s just my 0.02c, but I’ve seen the frustration from users, developers, and people who have contributed and now refuse to, as well as people who want to contribute, but can’t find a way to “scale the castle walls”. The skills are out there, we were all not unique, but there’s just more people than there were before. It’s both a good and a bad thing. More forks, more fractures, more “distractions”, but it’s also more eyes, hands, testers, and contributors.
Nurture. If the new contributors think the bar is too high, let’s give them a boost to help them climb that wall.