Comment by bryanlarsen

I was just googling this and it appears many of his decisions which might be considered rude or "not getting it", are actually a result of his philosophy of free software development, as outlined here:

http://udrepper.livejournal.com/7326.html

Excerpt: "[Development and testing is slowed down by trying to support every permutation of minority-interest OS/Architecture/etc.] The solution must be to restrict support to only a handful of architectures which are supported in the project. All other support must happen outside the tree and therefore all the work has to be done by the special interest groups.

I don't want to say we follow all these points perfectly, but for a big project glibc certainly comes closest to this. The only OSes supported in the tree are Linux and to some extend Hurd. The latter is certainly not a preferred target and does not hold back the development by requesting that no patch breaks the Hurd configuration. The supported architectures in the tree has been cut and probably should be cut even more. Only the architectures which are regularly tested (since they are supported in the various enterprise Linux distributions) are maintained plus a few historically supported architectures. The latter group should be cut down to the minimum. No global edits for the tree are required, they are voluntarily. I.e., fixing configurations which are negatively impacted by a patch is the duty of the people with interest in the configuration. All other configurations are maintained (or not) outside the tree. People can decide to use this additional repository at compile time to get access to the additional configurations. Nobody is robbed of the freedom but the costs are distributed fairly.

For my new projects the razor is even sharper. Only Linux is supported and only the few interesting mainstream architecture with reasonable APIs are maintained. Support for architectures with deliberately different APIs (i.e., IA-64) can be contributed. No other configuration is supported, actively or not, and people would have to exercise their right to add patches or fork the entire code to add other support.

IMO this is the only viable development model to allow free software to succeed since the remaining projects are huge in size and need concentrated efforts not diluted by diverging interests caused by a myriad of configurations."

Can't say I agree, but I can see his point to a certain degree. It's kind of like the difference between an uncaring asshole and a libertarian, he's trying to work in the interests of the greater good by fighting against unneeded complexity and unaligned incentives.

In fact in the list of reasons here

http://blog.aurel32.net/?p=47

has a "More friendly upstream" list item which gives four "as opposed to" examples, all of which involve Drepper.

Ulrich Drepper thinks strlcopy and strlcat (http://www.gratisoft.us/todd/papers/strlcpy.html) are "horribly inefficient BSD crap" (http://sources.redhat.com/ml/libc-alpha/2000-08/msg00053.htm...). This IMO qualifies him as an idiot.

So how do we solve this problem in the OSS world?

I've had my share of problems when leading open-source projects, and I remember a few particularly troublesome contributors, who made many others run away and generally decreased the quality as a whole of software, but Drepper seems to be of a considerably greater magnitude.

Is there any proper way to deal with this?