X
Tech

Supporting the minority: Is open source over-extended?

Slashdot has singled out a Live Journal entry by Red Hat's Ulrich Drepper titled "Dictatorship of the Minorities" that raises an interesting topic. Drepper argues that it doesn't further the cause of free software to continue developing on closed platforms, and that there's little benefit in supporting "minority" architectures like m68k, PA RISC and so forth.
Written by Joe Brockmeier, Contributor

Slashdot has singled out a Live Journal entry by Red Hat's Ulrich Drepper titled "Dictatorship of the Minorities" that raises an interesting topic. Drepper argues that it doesn't further the cause of free software to continue developing on closed platforms, and that there's little benefit in supporting "minority" architectures like m68k, PA RISC and so forth.

There are many that will argue that this is one of the strengths of open source. We're the "big tent" party. To join Microsoft's party, or at least to keep up, you need to have a relatively recent computer in the x86 or x86-64 family. You won't be installing Windows XP on that 486 or aging Sun Sparcstation. But you can install Linux and some of the BSDs on it. (I grant you, it won't be very speedy to run Linux on a 486 these days -- but it should still be possible to do so, even with the most recent versions of the kernel.)

But, that flexibility does come at a cost, in terms of complexity. Supporting multiple platforms requires additional testing, introduces additional hurdles when code that works on x86 or Linux doesn't work quite right on UltraSPARC or AIX. In short, it's not as easy to develop for multiple hardware platforms and operating systems as it would be to develop for, say, Linux and x86/x86-64 alone.

Drepper suggests that open source projects drop support for proprietary OSes and  take a hard look at which hardware architectures are supported as well. This wouldn't preclude support for "minority" hardware platforms or proprietary OSes, since the code is still open and available, but the interested groups would have to maintain their own trees and deal with the necessary changes to make a project run on their target hardware and/or operating system.

My first question is, has open source been unduly hampered by providing support to so many different hardware platforms and OSes? Are we over-extended, as it were?

If open source projects hunkered down and started to focus solely on Linux on a few hardware platforms, would development speed up significantly? Would quality be greatly improved? It's easy to reach the conclusion that fewer platforms equals faster development, but I'm not sure that's the case. I've exchanged e-mails with several Debian developers about the delays with Sarge, and found that several thought that dropping support for architectures in Debian would not speed up development -- and would reduce the quality of Debian overall.


My next question is, what would the cost be? Drepper suggests that many of the "minority" platform supporters fail to pull their weight when it comes to actually helping the projects. Whether or not that's the case, I can't say. I'm sure many developers who contribute to open source projects are doing so in order to help development on their favorite platform. What about companies that sponsor development or allow employees to contribute to projects like GCC, GNOME or Samba? Would it be in Sun's or IBM's best interest to contribute to Samba, if the Samba team suddenly decided that it would treat Linux on x86/x86-64 as the preferred platform? It's worth considering that many projects might lose some top-notch developers if the focus is narrowed to just Linux and common platforms.

Dropping support for proprietary OSes is also a double-edged sword. A project might save time and energy by not worrying about Cygwin, for example. Those of us who use Linux on the desktop care very little whether a program also runs on Cygwin on top of Windows, so long as it runs on Linux. However, there are still significant numbers of users who have to use Windows at work, but want the tools they use at home. There are also many users who get their first tastes of open source on proprietary platforms. Reducing their options may not be the best way to promote open source and free software.

Editorial standards