Edd Dumbill posted his take on the next steps for GNOME. There’s been a debate going on about the future direction for the project, I posted a few links a little while ago myself. I have some points that I want to throw in myself, cause I somewhat disagree with Edd. I agree with his points in general - that better documentation and IDEs will go a long way to getting the Linux desktop adopted as a platform of choice. But I think that the techniques proposed would also go a long way toward destroying the platform. I want to address this issue right off:
Microsoft’s genius is in enabling the hoardes of mediocre programmers who just do their job from 9 ‘til 5 each day. GNOME’s weakness is in only making developer tools for core GNOME hackers: if you really want to find out how to code for GNOME, you must enter the inner circle.
Now it’s true that this reduces the number of people who develop for GNOME, but it also means that the average skill level of the developers is higher. I think this is actually an important control mechanism within open source projects. Just like in evolution, sometimes there are sets of attributes that just don’t work out. Open source projects work along a set of rules that seems very similar. Some developers just don’t have the right set of skills and motivation in order to work with the project as a whole. The correct answer isn’t to lower the bar for them however. All that would happen is that you would end up with a polluted project. The core developers would have less time to work on what they need to get done because they’re helping newbies and trying to clean up crappy code that got into the code base.
To see an example of how this works out correctly, just look at the core Linux kernel development team. Many people describe that group as a gruff and rather uncompromising band of elitists. But the project keeps going and the output keeps getting better and better. Their personal demand for excellence is what ensures that the overall project maintains the required degree of quality. Does that mean that sometimes someone with a good idea but without the ability to implement it gets ignored? At times, yes. But if the idea was really necessary, it will eventually get picked up by someone with the right set of skills to take it to completion. It sounds rude, and maybe a bit brutal, but it’s a system that works. And given the distributed nature of these projects, and the fact that the projects are really kept alive by the sum of individual motivations, diluting the core group is a very dangerous proposition.
I think the ideas that Edd lays out are good ideas in general. I just think that the core team should be left to develop as kick ass of a desktop system as they can (I refer back to a post by Havoc Pennington for the initial motivations myself). And if there’s also a goal to take the Kick Ass Linux Desktop Environment and make it more accessible to the average developer that should be another project. Just like the way that the Linux Documentation Project is not the same as the Linux Kernel Project, I don’t think that making the desktop system more accessible to the average user fits well with the role of the core technology developers. I think that providing a resource for GNOME which fills the documentation role as well as MSDN does would call for providing a lot of general background info. The resource would need to describe not just how the technology works, but general high level concepts, the motivations for certain design decisions, and common usage patterns. The same thing goes for development tools such as IDEs and interfaces for high level languages. Maybe this means that the developers of the documentation and user tools have to do some extra running around in order to track down the rapidly evolving system… But if they give up because they can’t do it that means it’s not yet time for it to be attempted. To burden the core developers with the additional role of increasing accessibility would only end up coupling the two tasks. If the documentation part fails it risks bringing down the whole desktop project. But if we let the geeks run off and make a kick ass core system, and just let them do their thing, they are more likely to succeed. It might take us two, or three, or three dozen attempts to figure out how to bring that desktop system to the masses. But at least if they develop the system we know what we’re working toward, and we have a working system while we do it.