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?
|
|
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?
