I’m pretty sure not to say something wrong when I say that the majority of the readers of this blog would agree that Open Source and Free Software development can produce better software by many different measures. Better overall quality is just theoretical; you have more portable code, more standard code, faster coder, less memory-hungry code and so on so forth. One of the measures you can figure out is code cleanliness, but even that is very subjective. So this is why I’m talking about taste.
So what’s the problem here? Well, while I think the end result of GNU software is generally very good, I find the general code very messed up and pretty much unreadable and unusable. I have criticised gnulib’s approach before regarding the way they duplicate the same code over and over, rather than provide a “portability” library to use where glibc is not used, and the system libraries don’t provide enough functionalities. Lately, I also noticed that they add tons of redundant autoconf checks to project running them, some of which have been broken from time to time, in different ways (I had to fix diffutils and m4 the other day because they had an automagic dependency over libsigsegv (and that changed its ABI on the tinderbox recently).
A couple of days ago I also had a bad face-to-face encounter with GNU coreutils code. The reason for that is that I’m working on an utility for a customer of mine, and I wanted to re-use the code from the fold command to split a text file into equally-sized lines (of course I could always use fold as a filter, but since the amount of work that I needed to do to get the proper parameters passed to that would be more than the generic work I needed to do my side, I simply wanted to integrate the code). License, here, wasn’t much of an issue to me, the utility I’m writing is not part of the business logic, so I have powers to make it available if the license of parts of the code asked for me to.
Unfortunately, a different problem came up: the code in fold.c is too messy to work with. The source file is not standalone, it depends on a huge tree of header files, each of which then depend on a pile of other sources; and this does not limit itself to the gnulib dependency. Nothing is clear in that code. There is a system.h header, that defines a very wide range of different functions: filesystem handling, integer types, allocation functions and so on so forth. This header in turn depends on over ten other different headers that provide different definitions and so on.
Just to make it worse, the headers define inline functions, that depend on other external functions from other source files; and all of those end up requiring a truckload of autoconf checks that sound, to a minimum, silly for something as basic as fold. I actually tried cleaning up the code, but, well, the work was tougher than reimplementing the folding code altogether.
At the end, I didn’t have to reimplement the algorithm though; the whole multibyte coding would have annoyed the hell out of me. I “folded back” (sorry for the pun) to using FreeBSD’s code. The fold.c file from FreeBSD’s source repository is self-contained, clean, straight through (although, to be honest, I find it lacks a couple of “static” keywords that could have slightly reduced its overhead). The license is also more permissive, as we know.
At the end, I’ll probably try to make the utility open-source anyway, using a similarly permissive license, given that’s what I took part of the code from.
I don’t doubt that GNU’s code might be better in some regards; for instance it’s almost certain that the GNU code builds on more platforms and with more variations than FreeBSD’s, but to do so, it really has to overcomplicate the code to a point that readability is gone for good. Similarly, the GNU utilities tend to have more user-friendly features, with further parameters, but these GNU extensions cause “lock-ins” that mean that standard support in their programs is lacking. This reflects down to many aspects of GNU software, their complexity, their over-engineering, their non-standard extensions. And this is probably one of the reasons why GNU is sometimes frowned upon by other (pragmatic) Free Software developers… and why some people would very much like to stop talking about GNU/Linux.
GNU guys, I understand your projects’ aim, but please, could you refocus? Could you reduce your complexity? Give us a libgnucompat… make it GPL if you don’t want to have it LGPL; but move away the code duplication; move away the complexity in build systems; the complexity of webs of source and header files. Make your code readable again, linear again, make your utilities the best people may come ask for. Please; pretty please.