Crowding out OpenBSD

Benefits for LWN subscribers The primary benefit from subscribing to LWN is helping to keep us publishing, but, beyond that, subscribers get immediate access to all site content and access to a number of extra site features. Please sign up today!

Unix as a whole predates Linux by many years, and even the rather younger BSD variant was well into its teens by the time Linus released his first kernel. BSD networking defined and enabled the Internet. This illustrious history notwithstanding, BSD has long since ceded the spotlight to Linux in most settings. As Linux has come to dominate the free software development world, the result has been some occasional pain for other operating system distributions. Now, as a recent discussion on an OpenBSD mailing list shows, BSD developers are feeling that pain in a heightened manner. This situation has some serious implications.

On November 6, longtime OpenBSD hacker Marc Espie complained to the OpenBSD project's "tech" list about behavior from "upstream vendors" that, in his view, is proving harmful to the OpenBSD project. In short, projects like desktop environments are increasingly adding dependencies on changes being made at other levels of the (Linux) systems on which they are developed. That makes it harder for OpenBSD to port and support that code, to the point that "if you don't have tens of people, it becomes more and more of a losing battle". The OpenBSD project doesn't have those people, so it is hurting. Marc continued, saying:

It's also quickly turning Posix and Unix into a travesty: either you have the linux goodies, or you don't. And if you don't, you can forget anything modern... I'm pretty sure there's a lot of good intention behind the "progress" in recent desktops. But this is turning the field of OS distributions into a wasteland. Either you're a modern linux with pulseaudio and pam and systemd, or you're dying. So much for the pioneer spirit of opensource, where you were free to innovate and do cool things, and more or less have interesting software able to run on your machine...

One could easily poke holes in this complaint; the characterization of PAM as "modern" is somewhat amusing; it is 1990s technology. There is an evident case of cognitive dissonance shown in the simultaneous desire for the comfortable "Posix and Unix" world of decades past and the ability to "innovate and do cool things." It is difficult to simultaneously innovate and stand still, but that is what Marc seems to be asking for here.

In a subsequent message, Marc acknowledged the real source of the problem: OpenBSD simply does not have enough developers to influence the direction of projects like X.org, GNOME, or KDE. Antoine Jacoutot, who works on GNOME for OpenBSD, went further, stating that almost all of the work is being done by "Linux people" with little or no representation from other systems. Why, he asked, should they be concerned about portability in that situation?

In most free software projects, the developers who write the code have the most say over the direction the project takes. The BSD distributions have trouble coming up with enough developers to do the ports to their own systems; finding developers to help push projects forward — and influence their direction — is an even taller order. In the absence of active developers, they are, in a sense, just another user, able to make requests but with no ability to create the changes they would like to see. So big software projects move forward in directions that are not always convenient for systems like BSD.

One could argue that the Linux community is throwing its weight around. But we are really just seeing the way that free software development projects work; in the early 1990s, BSD-oriented developers were equally unconcerned about the difficulty of porting their code to Linux. When developers have enough problems of their own to solve, trying to make life easier for operating systems they do not use tends to end up fairly low on the list of priorities.

Where this is heading seems reasonably clear: without the ability to participate in these projects, or at least to keep up with them, the BSD projects will have an increasingly hard time supporting contemporary desktop environments. Their hardware support will continue to lag. They will not be able to take advantage of the work that is being done to operate well on mobile systems. There will be fewer and fewer settings where BSD-based systems will operate in the way their users want.

That, needless to say, is a recipe for irrelevance and, eventually, disappearance.

It may be tempting to shrug one's shoulders and say that none of this matters anymore. Your editor, whose first kernel hacking experience was on a BSD-running VAX, would not be so sanguine. But, in truth, even the most determined Linux fanboy should be concerned about a development like this. BSD is more than a repository of a great deal of Unix history and the continued home of a great many talented developers. It is an important part of the free software ecosystem.

BSD is a place where developers can experiment with different approaches to kernel design, filesystems, packaging systems, and more. OpenBSD remains a center for security-related work that does not exist to the same degree in the Linux world. The existence of alternative systems gives us resilience in case Linux is undermined by legal issues, security problems, or corporate mismanagement. Monocultures are unhealthy in general; a Linux monoculture may be the ultimate vindication of our approach to development, but it still would not be a good thing for the world as a whole. As in natural ecosystems, diversity is a source of strength.

Even so, a monoculture may be where we are headed, sometime years into the future. Economies of scale and network effects push in that direction; the fact that Linux is the best system for so many purposes helps to ensure that it will continue to get better in the future while alternatives will languish. Few developers will be able to find the time to, in effect, subsidize alternative operating systems by holding back progress in Linux. It is an outcome to anticipate and, possibly, plan for, but it is not one to celebrate or to try to hasten. If other free operating systems start to vanish, we will eventually realize that we were better off when they were still around.

