Home Business IT Open Source Upstream vendors can harm small projects: OpenBSD dev

A senior OpenBSD developer has complained on a mailing list that upstream vendors of free and open source software are adding in changes without any thought of whether downstream users could adapt to the change.

Marc Espie said this would hurt smaller players by not allowing them to keep up with the changes. Basically what is happening is that numerous changes are being made to Linux and smaller projects like OpenBSD cannot keep up with the changes. And, according to Espie, not all these changes are strictly necessary.

In a Q and A with iTWire, he explained in detail what he was trying to convey.

iTWire: When you talk of breaking compatibility, what exactly do you mean in layman's language?

Marc Espie: Historically, various Unices have been largely compatible with each other. This means that you could take source code from someone and compile it on your machine. On any given project, over 95% of the source code should be directly portable. There are some parts that require some adaptation, but it's fairly easy to keep that in a small part of the project. Then there's gratuitous incompatibility, of two sorts: either not knowing enough and writing code that will only work on some given machine/OS variant, because you don't know better or putting something that you know only exists on your OS at a central point in your project.

If you've been working on Open Source projects for some time, you know that the above tendency has been increasing over time, with a main focus on GNU FSF tools and some Linux stuff.

How does such an action (or actions) hurt the open source community?

Well, it can detract from some other goals. When you start porting some software to OpenBSD, you will often be stopped right at the configure stage. Because it wants bash, or gnu grep, or GNU sed, or PulseAudio. In many cases, none of these are actually necessary. They're just gratuitous incompatibility. But fixing these takes time from doing more interesting work.

Your average Linux people will then ask: what's the problem with bash or GNU grep ?

One first problem is that they're GPL. For BSD people, the GPL licence is not all that great. It takes some liberties from me, as a developer, that I still have with an MIT or BSD licence. I believe in freedom, as in, people should be able to do what they want with my source. And possibly the right thing (as in keep sharing), but not because they're forced to do so, just because they choose to do so. That's a fundamental freedom that the GPL takes away from them.

The second problem is somewhat ironic: back when the FSF was just starting up, RMS (Richard Stallman, founder of the organisation) did say "use different algorithms from existing things, so that we don't infringe on anyone's copyright". That was a good idea, from a technical standpoint as well. Complex systems require interoperability (see the basis for our current network, RFC work on that tenet), and having distinct implementations of basic tools is a great way to discover problems.

But recently, people just say "hey, I don't know the difference between GNU-sed and POSIX sed, so I'm just going to require gnu-sed, because it's easy to install, right?" without even checking whether it's actually needed. (and no, gsed -i is not a valid excuse. Come on, you need half a line of shell script to do the equivalent of gsed -i)

Actually, while working on OpenBSD, like on our implementation of m4, or of libtool, or of make, I routinely run into issues that exist in the GNU versions of these tools. Increasingly, developers have become complacent. They don't even try to be compatible. They don't even realize they are relying on weird behavior in those GNU tools that are not documented at all or even bugs, making it more difficult to run outside of a GNU universe.

We're often faced with one single issue: do we want to be more GNU compatible? Like I said, gsed -i is basically trivial to implement. But it's not POSIX (yet). It's a gratuitous problem when you're actually trying to write portable shell scripts. It's not even such a good option and particularly useful.

We'd prefer to implement options in our tools because they're a good idea, not because we have to emulate GNU stuff.

To make a more colorful comparison: imagine you're cooking a great hamburger, and some friend comes by and tries it and tells you "oh yeah, it's fine, but it does not taste like I'm used to when I go to McDonald's".

Are you going to change your recipe so that it tastes more like McDonald's?


VMware changed the rules about the server resources required to keep a database responding

It's now more difficult for DBAs to see interaction between the database and server resources

This whitepaper highlights the key differences between performance management between physical and virtual servers, and maps out the five most common trouble spots when moving production databases to VMware

1. Innacurate metrics
2. Dynamic resource allocation
3. No control over Host Resources
4. Limited DBA visibility
5. Mutual ignorance

Don't move your database to VMware before learning about these potential risks, download this FREE Whitepaper now!


Sam Varghese

website statistics

A professional journalist with decades of experience, Sam for nine years used DOS and then Windows, which led him to start experimenting with GNU/Linux in 1998. Since then he has written widely about the use of both free and open source software, and the people behind the code. His personal blog is titled Irregular Expression.