Are there too many Linux distros? Michael Dominick, in Episode 23 of Coder Radio clearly says that there are too many distros. This is not a fresh dilema, and I’ve written about it in the past. It is a basic point: in any community where proficiency is valued and lumber is free, you will never find two carpenters who build the same chair. The thousands of Linux distributions we find today are an evolutionary explosion submitting solutions to the needs of the few in the long, long tail of possible requirements. And there will never be a tangible method to restrict this growth.
Commercial vendors have always had trouble with what they viewed as a slithering mass of mostly academic and hobbyist level distributions. Clearly, Redhat, SuSE and Debian/Canonical have been the most stable presence in this realm. Software availability is more ubiquitous, more consumer focused, and more competitive than ever. The Linux Standard Board has always been a watered down standard that never lead the distros, but merely tailed them. And now when OS vendors tend to proffer “blessed” software development paths, the LSB has yet to address this, or even think ahead to application development life-cycle standards. This is a failure in stewardship of Redhat, Novell, and Canonical in general.
Long has it been clear that each large Linux vendor has their own software architecural style. Seeing how much effort software developers put into competing with iOS and Android requirements, developing desktop software for Linux is only going to be more neglected if these vendors don’t provide a unified approach to for desktop application development. Just having a pretty desktop is insufficient. Just having an app-store is insufficient.
Providing a reference-distribution application development life-cycle and a stable reference desktop application API is crucial for Linux to be competitive in the network-enabled software market. This is a vision that Sun took a stab at, Trolltech, RealBasic and Bryan Lunduke have all taken their own stabs at, but seems roundly ignored by the large distribution providers. I think that Bryan Lunduke’s Illumination Software Creator was an earnest answer, as well has been Qt, and Java to this problem (at various points in time). Michael Dominick articulates these issues very clearly on Coder Radio.
What kind of compromises are necessary for this to happen? Will distros need to focus less on architectural evolution and more on community economic development? Would the most indignant and proud developers have to get a) offfended b) dismissed and c) ignored in favor of the vanilla approach?
And is this an unjust route? Michael Dominick and Chris Fisher were discussing Alan Cox’s upset over the Nvidia kernel code sumissions, and it reveals a core tenant of the Free Software and Open Source origins of Linux: progress made in spite of the licensing of the progress is fundamentally damaging to the rights and mores of the project and its license. The wholly opposite side, but on the same axis or licensing and rights is the realm of DRM. If Nvidia’s patches are unacceptable and have to only live on as tainted modules or binary blobs, is progress actually lost? Which is the greater loss, if by accepting proprietary property into a code-base you open the door to other corporate exceptions to a community effort? I can see both sides and clearly there must be some compromise possible.
Linux, Free Software and Open Source have deep academic roots as well. The merits of the “more correct language” and the “more refined approach” have always held sway within many of the developer communities that provided many of the packages present in all Linux distros. What happens to this varied set of rarefied projects, hardly even a community by many standards, if Canonical and RedHat unexpectedly decide that desktop applications need to standardize on Qt…and that any other languages may not be available thru app-stores on both their distros? Many would likewise call this unjust as well. Would it actually be progress? Would it also be unjust? Would focusing on enrolling developers by restricting choice raise Linux adoption?
I think that there will always be a libre-Linux ecosystem on the internet. The benefits of providing a competitive similar commerce-oriented (if not commercial, and certainly not proprietary) desktop/mobile software platform on Linux might never be known if it is never attempted, however. Isn’t it possible that the LSB could define a fully featured language, development- and deployment-life-cycle that can enrol or even entice developers and shops presently producing titles for iOS, Windows and Android?