Debian: contempt for "end user" values has to stop!

Short URL:


Three recent problems with packages in the last stable release of Debian GNU/Linux ("Lenny"), brought me face-to-face with what is still a major obstacle for acceptance of free software on the desktop: contempt for the values of the people who use it. Despite all the accusations of unfair trade practices or other excuses, this remains as one solid reason why free software is still perceived as "geeks only" territory. If we want to progress further, we've got to improve our attitudes.

Even in a room of hardcore hackers, it's safe to say that we are all "end users" of software more often than we are developers of it -- just as we are all more often readers than writers of prose. Likewise, just as it saves more time in the end to write clearly and proof-read your work, it serves us all better to put "end user needs" ahead of developer values.

Yet, there is no question that adversarial attitudes arise between users and developers of software: they are in a sense, working against each other, tugging the product into two nearly opposite directions.

This is understandable. It's just human nature. But we must overcome it if we hope to be truly competitive with the folks who call the end users "customers." Because while proprietary companies may have started to sell out customers to other stake-holders (one of the main reasons people abandon proprietary software), they got those customers in the first place by treating them right and placing their values first.

So, if we want to make the world a better place by getting the free software system to displace the proprietary software system, we've got to find a way to serve those customers better, not just wait for the proprietary system to get even more intolerable.

Commitment to customer dissatisfaction

So what exactly happened to make me frustrated enough to write this? Well, this year I upgraded my main Debian system from "Etch" to "Lenny". Of course, I did this to take advantage of new and improved packages (and they are there -- much of this experience was positive). Sadly, this upgrade also broke a lot of stuff.

I didn't contact these developers and I'm not going to name names (of course I can't avoid mentioning the package names), because there's really no point -- I know and you know that these attitudes are endemic throughout our whole community, so it'd be unfair to single-out these three people. I know there's not much point in trying to talk these particular packagers around to my way of thinking, because I've already read the transcripts of others on the same quixotic mission. No dice. Clearly these particular folks are committed to their decisions, no matter how bad I think they were.

Perhaps most frustrating of all, I cannot solve these problems by simply switching to an end-user focused distribution like Ubuntu, because two of these three problems are broken there too (unsurprisingly, since the problems are hard to find).

Fix By Deletion: ttf-thryomanes

I spend a lot of my time on graphical design and artwork. I've designed logos and website graphics for my own company and a number of small free software projects as well as flyers and other advertising materials. Most of this, I like to do in Inkscape or other vector graphics applications, because they really excel at this kind of work: you can scale the results, edit the text as needed, and so on.

However, vector graphic documents fundamentally follow "link semantics", which means that, like an HTML page, they depend on other files being there to interpret their appearance. Images are an obvious problem, and managing them is often a challenge. But the most common trouble spot is fonts.

Choosing a font is a personal artistic decision. It's very particular. You can't just substitute "FreeMono" for "Courier" and expect your layout to stay sane or balanced. These fonts have subtle differences in letterforms and spacing, and yet these are a very tame example. Pick any fancy "display font", and you can bet it's one of a kind.

I wanted to be sure to use standard, free software fonts in my artwork, because I felt this was the surest way to make certain I wouldn't lose them or have to switch at some point. Sadly, I made the wrong choice in picking "ttf-thryomanes." This font was apparently primarily intended to fill a gap in Unicode language support, but I used it because I liked the letterforms. They were just a little "off" from the standard forms (possibly an accident in retrospect), but this produced the effect I wanted in the drawings I was making.

Between "Etch" and "Lenny", however, this font package was dropped. Of course, I wanted to know why. My first assumption is that it must have been consolidated into another package, and I would just have to install that one.

But no. It turns out that Thryomanes had some kind of bug listed against it because some of the characters (evidently ones I never used) did not display properly. No one had gotten around to actually fixing this problem in the font itself, so the package maintainer decided to "fix" it by removing the package from Debian entirely. He excused this by noting that another font "Deja Vu" included the Unicode code points that Thryomanes had apparently been intended to cover.

Which (from my point of view anyway) is totally missing the point! "Deja Vu" is a different font! Even if they looked identical (which they don't), there's no mechanism in place to substitute the "Deja Vu" font for the "Thryomanes" font in existing documents.

It is now virtually impossible to find and there is certainly no easy way to install the package in the "Lenny" distribution that I can find.

Without the font, all of the previous drawings that I made using "Thryomanes" are basically "broken." I can't simply re-render them on my Debian "Lenny" distribution system. I might be able to re-design for another font, but I shouldn't have to do that!

To me as an end-user, this sounds like amputating an arm to cure a hangnail. Clearly, the package maintainer does not share my values in a good desktop system.

It occurred to me, of course, to check and see if the problem is in Ubuntu, which is supposed to be more user-focused, but sadly, yes it is.

Oh You Don't Need That: defoma

The best thing I could think of is to manually install the Thryomanes TTF font outside of the Debian package system. Trying to do that is how I discovered the second gaff.

As an unpackaged font, Thryomanes join about a hundred or so fonts that I had stored on my hard drive but hadn't gotten around to installing into the new distribution. So I decided it was time to tackle that.

I was a bit foggy on how to do it, since it's been a couple of years since I've had to do this, so I looked up the documentation. In order to use TTF fonts, you need to provide the Debian font manager (called "Defoma") with "hint" files which essentially just index metadata for the files.

There is a laborious process by which you could write these hint files by hand, and I suspect that the packaged fonts are handled that way. However, there is a simple way to do it which I had used before, which is to run a program (called "defoma-hints") on the original TTF files, which contain all of the really essential metadata in their headers. This program would simply read out the data and produce suitable font hinting files for Defoma.

Great! I love it when Debian has this stuff all figured out for me.

Except it's broken.

It turns out that the defoma-hints program relies on an older Perl module for interfacing with the FreeType library which the Debian maintainers in their infinite wisdom have decided is "obsolete." Never mind that a critical piece of Debian infrastructure relies on it.

So defoma-hints is still there, but the library it relies on isn't. Again, it's not possible to install this through the package system, as far as I can tell.

Reading the bug reports for this package is even more disturbing. This is bug #285653, reported in 2004 and unresolved as of this writing, although the maintainer is currently busy ignoring a recently submitted patch, see Bug #514635.

Of course there is no bug report for the missing libft-perl package, because it was removed, which seems to be the fastest way to quash criticism in the Debian bug-tracking system, which forgets all commentary on packages that are removed (including such things as why they shouldn't have been).

My fonts are still broken. I even tried to see if I could run the program on an older machine and then port the file, but so far this hasn't worked.

Eventually, I will get this fixed, even if I have to write the hints files by hand or install libft-perl from source code. But I think it's clear that I am already way beyond the limits of the "typical desktop end user."

Or "fonts=fail" as my teenage son would put it.

Utter Contempt for End Usability: wacom-tools

Moving along to another graphics-related problem, I recently acquired a Wacom graphics tablet. I bought a Wacom brand-name product because I understood that the Linux-Wacom driver is very solid and supports everything I would expect to be able to do with the tablet. It even has a GUI configuration wizard to help you get it installed as an X input device with the proper settings for your particular tablet.

This is probably true. However, I am fairly disgusted with the Debian package maintainer's attitude about this package.

It should be very, very simple. Just plug it in, start the configuration app, change the settings, and (possibly) copy them into the appropriate X configuration file.

The package maintainer however, recommends using a command line utility called "xsetwacom" instead. This can do most of what the graphical tool does, but not quite all, and it is not a terribly intuitive or simple program to use.

Now remember: Wacom tablet users are, by and large, artists. There are artists who are also programmers or system administrators, but not many. There aren't many user groups for whom a graphical interface is more important. Since this is an infrequently-used program, however, it's unlikely that they care what language it is implemented in.

Yet, the package maintainer is willing to deny their needs because of an aesthetic displeasure with the programming language being used to develop it!

He proposed (in 2005) that a better solution would be to write a new tool which didn't rely on TCL:

Work is underway on a couple of fronts for a gui interface that doesn't involve getting all covered in tcl.

Apparently he never got around to it, because it's still not there. When a later poster challenged this in 2009, the maintainer got very defensive and flamed him in the bug tracking system. He still did nothing about the problem, and the package is still incomplete.

In brief, what the maintainer sees as a trivial waste of his time is a critical matter for end users.

Luckily for Ubuntu users, this package seems to have been fixed in Ubuntu, by simply including the missing program.

Who is Debian For?

Of course some people will simply respond that Debian isn't really meant to be an end-user distribution. Does this justify such contempt for end-user needs?

I don't think so. Because even though Debian itself isn't really intended to support end-users, it is the base upon which distributions of different types are made. Problems in Debian get mirrored into end-user systems, and unless the maintainers of the end distribution are very careful, these sort of bugs will simply fall right through into their final product.

The defoma bug is at least listed as "important", and therefore might be noticed, though it's pretty shocking that it's been left unresolved for years.

The wacom-tools bug is much more insidious, since it is listed as merely a "wishlist" item, which means it isn't really considered a "bug" at all. Likewise, the ttf-thryomanes package is non-existent, gone with virtually no trace, so it's certainly not going to show up in a casual survey of bugs to fix.

Values mismatch

The real problem is that there is a fundamental mismatch between what the users and maintainers value. As in the wacom-tools case, the original developers have done their part by providing the necessary tool. But the packager has obstinately refused to include it. What can be done?

There are some formal complaint processes within Debian, but is this problem really severe enough to drive users to that point? More likely, the distribution is riddled with small holes like these which bother particular niches of users enough to irritate and even drive them away, but not enough to go through the process of getting the problem fixed.

Most users would rather just "vote with their feet" by moving to another distribution or operating-system. In fact, problems like this are often cited when people give up on free software entirely and switch back to a Macintosh or Windows system.

The problem is that for "end users", the whole point of the computer is to handle headaches like fonts and graphics and so on so that they can do their "real work" -- which is documents like word-processing or artistic graphics. They don't really care what happens "under the hood" as long as it works. For them, the penalty of losing access to those inner workings doesn't seem so important.

Meanwhile, for the developers and packagers who spend their professional lives tinkering with computers, such real world uses of computers are almost like an unintentional side-effect of their work. They create a beautiful and fun piece of software, and "oh, by the way" you can also get it to do real work. This is not an unnatural attitude for an amateur, but it is precisely unprofessional.

We could accept that label, of course. We could just concede that the community development model doesn't work and that software for real use in the real world should be handled by professionals who demand payment for each copy of software delivered.

If you're reading this magazine though, it's a pretty safe bet that you don't want to admit that kind of defeat.

How can we fix it?

I don't have a clear or coordinated answer for this, but I will suggest a few ideas. I think first of all, the problem has to be seen as a kind of "market failure." The market for free software binary packages is not free enough because there are points of friction and anti-competitive factors associated not with the writing of software, but with the packaging of software.

What we're facing here is "Deb Hell" -- the Debian counterpart to the more poetically-named "DLL Hell" of Windows. The reason the packager has so much power over us is that it is difficult to replace the package with a new one, maintained outside of the system. The official Debian package has the (unfair?) advantage that it is tested against the current Debian distribution.

It would be to the benefit of end users (and ultimately of the Debian distribution itself), if this friction could somehow be removed and fair competition be restored to the delivery of packages.

One thing that is not the solution is to start pointing the finger at packagers and demanding that they do as we please. Clearly, the packagers of the three packages I complained about above do have their own, possibly valid, reasons for doing things the way they have done. This is a disagreement of values, not some fundamental "ethical" issue. Demanding "better regulation" of people who are, after all, volunteers would be pointless and counter-productive. What I should be able to do is simply "take my business elsewhere" on an individual package basis, without having to dump the whole distribution.

The problem is that as things stand, there aren't enough "elsewheres" to take it.

The software store analogy

I've said before that a GNU/Linux distribution is not just an operating system -- instead it is more analogous to the complete inventory of a software retailer. It consists of thousands of packages, originally produced by different suppliers, placed under one roof for the customer to pick and choose what they want.

However, there is one important difference. In the software retailer, each package is published and marketed by an entity whose incentive is directly based on customer (read "end user") satisfaction.

In the Debian case, though, the publishing and marketing (read "packaging") of the packages is maintained "in house" by Debian developers who have little affiliation with the original developer and often are concerned only with a small subset of users (in the worst case, only with their own personal needs).

This is essentially because we aren't paying them.

With distributions like Ubuntu, there is the opportunity to fix some problems by simply paying packagers to do a better, more user-focused job. But the amount of money available is somewhat limited because of the generally lower profitability of free software production. Ubuntu has to save money by relying heavily on the mostly-volunteer work of the Debian base distribution.

As a result, most of the problems in Debian are also problems in Ubuntu. This situation is analogous to "shareware" marketers in retail stores -- they produce an essentially generic product which relies heavily on the original developers' work, with little investment in packaging and presentation, because they simply can't afford to invest more and maintain the low price that customers expect from shareware.

One solution might be to make the Debian package tools a little more like an online shopping experience: with customer ratings and reviews, not just bug reports. This might give some feedback, both to people selecting packages, and to packagers looking for packages to improve upon in Debian-derivative distributions.

Another approach might be to bring competition into the Debian distribution itself by allowing multiple teams to produce competing versions of packages for the same upstream product. Possibly some of the packaging distributions could be made available through switches incorporated into the package tools. This would be a much more radical design change, but it could improve a lot of design-tradeoff issues with a distribution that is trying to serve a lot of diverse users with diverse needs.

One way to reduce the combinatorial explosion of package dependencies would be to break Debian up into a set of coarse blocks, possibly based on language/programming-environment subsystems. For example, it might make sense to de-couple the release cycle for all Python or Java packages from the main release schedule. Then, rather than having to wait for all of Debian to catch up, the Python Sub-Distribution could be released, allowing for more up-to-date packages and fewer headaches for upstream developers. This might make the packaging problem simpler, and lead to more third-party packages (and thus competition).

There are already a number of "unofficial" Debian package repositories on the net. One approach would be to try to give these packages a more "first class citizen" status. Making another online retailer analogy, perhaps these could be presented in the Debian package system much like Amazon's "Marketplace" retailers are -- as choices beyond the one choice provided by the main retailer. This has been a big success for Amazon, and many improvements have been made to put such retailers on a more even footing. Something like this might have a positive impact on package competition in Debian, especially combined with some of the other ideas above.

At that point, I will leave off. I don't think I've suggested "the" solution to the problem, but I hope that I have made it clear that there is something to be solved and that there is (probably) a free, community-oriented way to solve it.



amarsh04's picture
Submitted by amarsh04 on

I agree with most of your article. The way that the Debian package management infrastructure is set up, it is easier to remove a package than fix a bug.

A deleted package should still have its bug reports available in the Debian bug tracker.

Also, adding a package [back] into Debian via the WNPP metapackage option of reportbug needs to be improved.

I tried to get ttf-thryomanes from - direct download links work but the /etc/apt/sources.list entries fails, so I've emailed the site administrator.

luvr's picture
Submitted by luvr on

Not that you should have to do so, but couldn't you grab the "ttf-thryomanes" package from an earlier Debian release (e.g., Etch), and install it in Lenny--just by double-clicking the file? That's certainly what I would try under Ubuntu; it may or may not work, but I would certainly consider it worth a try.

dsmithhfx's picture
Submitted by dsmithhfx on

So you're an 'artist'? Sorry, that doesn't let you off the hook. You still have the responsibility to choose your own tools. Wisely.

First of all, you are terribly uninformed about free software development, and linux distros in general. You'd be much better off with Ubuntu than Debian. I guess you sort of realize that. So quit whingeing about it, and install Ubuntu. But first, do a little online research and find out exactly what hardware is supported, before you go out and buy something that just isn't going to work. Because that would be your mistake, and your problem. Incidentally Debian is an excellent distro, and I find the sidux version to be even more excellent -- but not for ignorant n00bs. No offense, by the way.

What you experienced I have also experienced on non-free software. Specifically, very, very expensive products from Microsoft, Apple, Adobe, and dozens of others. Software I like got orphaned. Including fonts. So? Nobody is forcing upgrades on you. If you like an old tool, keep it (and if necessary, the supporting environment, including old hardware and OS versions) around. They'll (probably) keep going for years. If not, deal with it. You are creative, right? Move on. Incidentally, there are tools for converting ttf fonts to other formats. You do backup your fonts and other linked files, right... ?

You feel that Debian (and by extension, other FOSS developers) have "contempt for 'end user' values". But this is very, very wrong. FOSS developers are donating their time and energy to provide something for free, to the community. End of story. You have no claim on their time, or priorities. Accept their gift. Or not. Give back, if you can.

A lot of things in Gnu/Linux OS seem difficult at first. But ask yourself: how much time did it take you to get proficient at Windows and/or Mac OS? Me, it took years. Learning all the obscure little helper apps, what tool works best for what particular job, what breaks, what the work around might be. Gnu/Linux is like that, too. Some of the best Gnu/Linux tools are developer tools, not graphic design tools. Big surprise, eh?

Still, it's come a long way. I still rely on Photoshop for some stuff that the GIMP just doesn't cover. Ditto Illustrator/Inkscape. But I rarely boot into Windows or Mac anymore, maybe just once or twice a week (ok I sometimes cheat and run Windows in VirtualBox).

smoe's picture
Submitted by smoe on

When working with the stable release, you get to learn about changes when they are a fact. I presume that working with the testing release (Squeeze now) would help you a lot to shorten the feedback loop between yourself and the developers who upload new versions of packages all the time. You can always downgrade to earlier packages should something not work for a few days, but most is already caught in sid (unstable) before it reaches testing.

My hunch is that you would have much more enjoyed working with the maintainer of the package to prevent your experience. There are several ways to contribute.

a) Install the package popularity-contest
It will inform the maintainer that there are folks out there who are actually using the package he/she maintains. This is something uttermost instrumental in the decision process to possibly dump the package.

b) Join/start user-centric mailing lists
With you knowing so much about fonts, probably much more than the vast majority of Debian/Ubuntu developers, it would be just nice to have you listening on mailing lists on which such issues would then be discussed early

c) Co-maintain or maintain packages
From how I read your article, you may possibly need some technical assistance at first, but I don't see why you could not help with the packaging yourself. You won't become the Über-geek, but you don't need to be one to help with packaging. Debian wants you the way you are - but more integrated.

Please investigate if there is someone on a local Linux user group to help or say hello on the debian-mentors mailing list, see

d) Write
* rants like this one :)
* instructions to those still using commercial products
* instructions to developers about free software that is still needed

e) Help the eye candy of Free Software - which you said you'd already be doing.

Terry Hancock's picture

Those are all valid points. Responding to some of them (out of order):

In point of fact, I have created Debian packages before. I ran into problems with policy and the upstream package's archaic design and licensing, though, so none have so far been admissible to Debian's archive. At some point, I'm sure I will attempt it again with a less crotchety software package -- perhaps one of my own.

I also do run a number of testing or unstable packages at need. Sadly, I can tell you from experience that "You can always downgrade to earlier packages should something not work for a few days" is often untrue (there are quite a few ways to hose your system when packages are out of synch, and APT does not like downgrades). Running such a system on a work-critical desktop workstation is not a very good idea. I've had to do a complete re-install on more than one occasion because of such problems. Not something you want to do on a deadline.

Actually, I don't run popularity-contest. Call it paranoia, if you like, but even conceding that, it doesn't really measure the relevant metrics here. Satisfaction with the state of a given package is not highly correlated to how many people have it installed or even how frequently they use it.

"Working with the maintainer of the package" is unpromising in each of these cases, as the article describes. That is precisely the point of choosing these particular problems. This is not a matter of reporting a bug or of providing a patch. Each of these has a simple solution that the packager has rejected.

That's because they have a very different idea about what the "right" thing to do is. These are not failures of understanding, they are disagreements. I know that, because I've already read the bug reports.

The interesting problem is that with the way Debian is set up, that's the end of the story. Once the packager kills the idea, it just doesn't get done. Solving that problem is the focus of my post. Unfortunately I don't have a nice, canned, well-defined answer to how to do it. Just some brainstorming ideas.

Here's what I meant about "simple solutions":

  • ttf-thryomanes should've been kept despite the rendering bug. It's better to have the font with the bug than to lose it entirely.

  • libft-perl should not have been removed, because defoma, a critical infrastructure package needed it. Once the patch is applied to move defoma-hints to a new library, it can be removed, but not before.

  • wacom-tools should have included the configuration tool, despite the packager's objection to the TCL dependency. TCL could've been listed as a "recommended" or "suggested" package rather than a "required" package for those who don't want to get "all covered in TCL." Once a replacement tool is created, then the package can migrate to that, not before.

None of these decisions would've required any real patches, they're just configuration choices in creating the packages. This isn't a matter of insufficient labor. It's a matter of someone specifically blocking these actions because they disagree with them.

We're talking about subjective value judgments here, not objective "bugs."

The answer to that is not more bug reports (that's just repeating the same action expecting different results). The answer is a system that creates more responsiveness to user needs and/or more choice in what packages to install. That does involve a labor issue (how to make those competing packages), which would need to be solved by either decreasing the difficulty of making packages or increasing the incentives for doing it.

All challenging problems, but worth thinking about if we want a better, more usable system.

smoe's picture
Submitted by smoe on

I wished your experiences would have been more positive. Are you aware of and ? You should find some audience (and hopefully also answers) for your problems there.

Concerning the font that was kicked out of main, it could have been kept alive in the non-free section, for which packages don't need to adhere to the DFSG and -policy. Alternatively, if the missing functionality could be interpreted as "not yet finished", the experimental section may be handy.

When your own packages have not found acceptance by a DD for being sponsored, then you can still have your own repository - it is just a directory on some FTP or HTTP server. With that you can provide a reliable (you control it) set of packages and a homogeneous environment for all your five accounts/machines.

Once your problem is solved, you might not care, but you might also be interested to find more users of your own packages and your own repository, this way then possibly finding packages of yours to be adopted and further enhanced for maintenance for the main distribution. You would then present yourself as an end-user friendly, since run by end users, addition to Debian.

I know this to sound much like the typical DIY kind of reply to complaints to Open Source. And it does not necessarily make much of a difference to a general neglect of the user base that your thread is about. To run popularity-contest (which at least informs the maintainer about the number of installations effected by a removal of the package from the archive) and/or to join close-to-professional-interest Debian-specific mailing lists to exchange thoughts, experiences and expectations is something that should help preventing most of what you described - from what I experienced.'s picture

Defoma sounds like a real mess and I'm not a Debianite but have you tried just putting the thryomanes .ttf file(s) in your ~/.fonts/ directory? That's how easy fontconfig managed font (ttf,otf...) installation is supposed to be these days (and invariably is IME).

Terry Hancock's picture

On a Debian system, system-wide fonts are stored under /usr/share/fonts, which is what I've been working with. I have additional fonts under /usr/local/share/fonts, which is where I want to keep fonts that aren't maintained by the package system.

I don't particularly like to do per-user installations of anything, since we have five accounts and generally prefer them to all be able to use newly installed software.

Even if what you suggest works, though, it represents a significant design failing, since defoma is still the documented font manager in Debian. If there's a work-around or if font management itself has become obsolete, then that should be noted in the package descriptions, bug-listings, or in Debian policy documents. I have run into situations like that before (in fact, it's probably the most common failing in free software community projects -- to fail to note when a system has become obsolete).

I don't think that's actually the situation here, though. It appears that Defoma is still a needed system.

However, let me re-emphasize that I'm not asking for tech-support. I know I will solve my problem. What I find interesting about this is what it says about the state of the Debian distribution.

This is a particular kind of problem that we can't just "legislate away". You can't write a policy document that says "packagers will value end user concerns" and expect that to have any effect. The reality is that people ("honest people in good faith") will disagree on what a statement like that even means.

More management, better management, or regulation is not the answer. Nagging these particular packagers is not the answer either. They already know that their decisions are not satisfying to all users (the reports have already been filed by other people). They've been actively choosing to ignore that feedback -- presumably for reasons they think are valid. That's what's significant about these three problems -- they aren't "bugs" in the usual sense. They are disagreements.

The only thing that is going to be effective is to have a larger, more accessible pool of competing packages and to have meaningful metrics that will offer guidance to users and incentive to packagers (as a group, not necessarily individually) to make their packages stand up better to user expectations.

In other words, it needs to be more like a "free market".

This would take some serious engineering to change. Debian has already done a lot of engineering to make their package system good (IMHO, the best yet). But I think this exposes some ways in which it isn't yet all it could be.'s picture

Sorry - I should've said that /usr/local/share/fonts is also one of the directories a standard fontconfig system looks at (q.v. /etc/fonts/fonts.conf). What I said about just dropping font files into ~/.fonts applies just as well to it too.

Anyway, I entirely agree with the general thrust of your article. I was a happy Debian user myself a long time ago and recently I'd been (warily) considering a migration back to a less flexible but more easily managed binary based distro (either Debian or Ubuntu). Then the Mono storm hit and some of the Debian and Ubuntu people managed to bring those distros into disrepute as far as I'm concerned (I took an interest because of the software patent angle but I was shocked at the Dunning-Krugeresque ignorance and arrogance I saw). As desktop GNU/Linux has become more popular in recent years it seems to me there has been something of a decline in *nixy technical quality and character and an undermining of FS values - at least in some quarters. Just gratefully let your distro's package manager “unzip“ the latest “freeware" into your “folders" folks and don't even think about criticising it. ;-)

Terry Hancock's picture

There's a hard balance to maintain between making things easy for newbies and making a political stand against proprietary closed-source software inclusions.

On the one hand, we'd like to maintain some kind of incentive to get drivers released under free licenses, but on the other, we don't want to force users to choose between a 100% open system that doesn't work for them and a 100% closed one that does (you already know what most of them are going to pick, given only those options).

Having a 90% free system around is a good thing, IMHO. On the other hand, you don't want to claim that that system is really 100% free, and you do want there to be some motivation to get that last 10% freed (or replaced).

Everything after that is a value judgment and therefore highly subjective.

When discussing distributions' choices, we do have to draw some kind of line between our own opinions about those values, and the wide range of valid choices that we might not agree with (which is a lot larger). That's where "tolerance" comes in, and without it, there's no "freedom" for us to be defending.

In the article, I've tried to express both my own (extreme) frustration with the choices of three package maintainers and also my tolerance for their point of view. What I want is to have easier ways of getting a better range of choices so that I (and other people with other values) can get what I (or they) want.

Oh and BTW, I do appreciate the suggestions on my fonts problem. I will remember what you've said when I start working on it. I just don't want to dilute the conversation with my own technical problems. :-)

Kerby's picture
Submitted by Kerby on

The problem isn't the developers, it's the users. See if you can find 3 examples of constructive criticism and debate about any mainstream FOSS package on the net that isn't a flamewar and the debate is between two (or more) knowledgeable individuals - rather than between someone with a point and a zealot (like dsmith who posted above). Out of all the people I've issued this challenge to, not one has succeeded.

Obviously the developers don't listen to the users - the community self-censors any criticism so they largely don't ever hear about anything that's wrong. It's really sad in that a 'community based development' project actively stifles any user feedback that isn't empty praise.

The users of most commercial software packages give more feedback than the users of FOSS. It's no longer 'community produced' but 'oligarchy produced'. It's just nobody's really noticed yet.

Terry Hancock's picture

The main feedback that developers receive is through the bug tracking system. If you only look at mailing lists or forums, you're not seeing that.

This system works pretty well as long as the "bugs" are fairly objective.

These three problems are interesting precisely because they are subjective and so there is much more opportunity for disagreement.

Free software users on mailing lists and forums are so used to trying to fix individual tech support questions that they try to turn the discussion that way when quality issues are brought up. It's probably not fair to be too hard on them for that habit, since in the original context it is often constructive.

dsmithhfx's picture
Submitted by dsmithhfx on

It disturbs me that you refuse to take responsibility for the consequences of your own, uninformed choices.

Why? Because I am a graphic designer. It just embarrasses me, I guess.

At the risk of repeating myself, you have wrongly framed the discussion around YOUR needs and YOUR expectations.

No FOSS developer will take you or your concerns seriously, until you lose the 'tude.

You say you don't want to "dilute the conversation with [your] own technical problems". But your column is all about your technial problems, specifically your lack of technical understanding. It won't take much to overcome this, but it will take work, and time. Your effort, your time.

Until you grasp this essential point, there is no way forward for you.

If you are unwilling to make this commitment, go back to proprietory software.

Terry Hancock's picture

If you are unwilling to make this commitment, go back to proprietory software.

The essence of this statement is that you don't think the community process can serve end-users. I mentioned this point of view, and it's certainly a valid perspective from the evidence available.

However, I'm not willing to concede such defeat so easily. I think it can be done, and that is the essence of the article.

It won't take much to overcome this, but it will take work, and time. Your effort, your time.

These are relative terms. I estimate three work days or 24 hrs total labor. If maintaining computers were my job that would be nothing, but if graphic arts were my job it would be excessive lost time. For me, of course, both are part of my job and I agree with you that as things stand this is "par for the course."

For a true end-user, however, it is not good enough. That is one solid technical reason why neither Debian nor distributions based on it are a credible market threat to proprietary systems. Many people believe that there are no such technical reasons, which is why I raised this point.

It's unclear to me whether you are aware of this debate or what your opinion might be on it.

But your column is all about your technical problems, specifically your lack of technical understanding.

Incorrect. There are technical problems, but I already know several possible ways to fix them. Each of them is fairly laborious and beyond the limits of a stereotypical "end user."

For me it's an irritation, but it's also an opportunity to observe and comment on a problem that interferes with end user adoption of free software (which is an important editorial focus for Free Software Magazine).

You say you don't want to "dilute the conversation with [your] own technical problems".

Precisely, since I already know solutions for my own problems. The interesting question is what this means for end users who lack my technical expertise (or willingness).

No FOSS developer will take you or your concerns seriously, until you lose the 'tude.

This is essentially in agreement with my statement that contempt for end user values is endemic to our community.

However, I think you might be overstating the case -- I've met plenty of developers and packagers who think end usability is important.

At the risk of repeating myself, you have wrongly framed the discussion around YOUR needs and YOUR expectations.

Being focused on your own needs and expectations is essentially the definition of an "end user." That doesn't define me, but it is the (hypothetical) perspective I have focused on in this article.

Your statement implies that you think that contempt for end users is the correct response. With respect, I disagree.

Why? Because I am a graphic designer. It just embarrasses me, I guess.

Perhaps I shouldn't touch this emotional point, but it seems clear to me that you are reacting to a stereotype you've projected onto me rather than what I actually wrote.

It disturbs me that you refuse to take responsibility for the consequences of your own, uninformed choices.

What exactly do you think I was "uninformed" about? Not only do I take responsibility for my own troubles, I have the community mindset to try to apply what I have learned to solving (or at least understanding) the systemic problems that precipitated those troubles.

Unlike you, I do not simply give up and take it as read that the way things are is the best they will ever be. I believe that a constantly improving community process will eventually produce a system that is better for end users than any proprietary system.

But it won't happen if we stick our head in the sand, complain about "n00bs," and try to defend against all critical commentary.

notmebug's picture
Submitted by notmebug on

There are several problems here:

Users expecting free software distros to be perfect. This is not the case and never will be.

Almost all free software projects having a lack of developer/translator/artist/etc resources.

Developer priority changes coming together with bus factor issues to cause loss of features.

Some users not even considering the possibility of empowering themselves with the technical skills needed to control their computing experience to their satisfaction, and then complaining when volunteers have not done the work for them.

The challenge here is to create a culture where users care about the projects they use, regularly check for possible future issues upstream and with their distribution and do what is needed to keep those projects alive.

Also, I think there is also a lack of communication channels between developers for specific packages and the users of those packages. Basically the only communication with users of my packages I know of is to mail upstream fora or contact folks who have reported bugs.

Also, I'm hoping to get rid of defoma for squeeze:

David Sugar's picture

I do not think the answer would be found in having competitive packages with potentially different configurations in the same distribution. The process of creating and vetting a package through Debian is hard enough just for one instance or variant :). Also, packages relate.

This in fact is something that can (and already DOES) happen through the existence of different and alternate distributions, that are to various levels Debian "based", but with different or alternate or some may feel better choices of packages offered. If a specific distro makes what are perceived as "poor" choices for users, there are others that can and do have the opportunity to make better choices. That forms a market.

Nor are all cases one where there is a choice of including or substituting X for Y. Instead, often there are complex inter-relationships that derive choices of what packages to include and with which options they should be built with. One example is where you have completely alternate desktop design decisions represented effectively as split and variant distributions, such as for example Ubuntu and Kubuntu.

Terry Hancock's picture

I think you're probably right that competing at the Debian package level is too difficult. Essentially, the packages are too fine -- with dependencies, there are just too many different possible combinations.

On the other hand, I think competing at the distribution level is simply too coarse. On the one hand, you get "general purpose" distributions like Ubuntu, and on the other, you get specialized ones like "Puppy" (small footprint) or "64 Studio" (audio production).

But what if I have a combination of specific needs? Do I have to install a multi-boot system just so I can switch between being (say) an artist (multimedia distribution) and a machinist (a CNC configuration). Or do I have to settle for an inferior general purpose distribution that can't do either one well?

Maybe it would be better if there were some intermediate level of complexity -- incomplete distributions or collections of packages that serve specific niche users.

As for the conflicts that might occur, it might be desirable to include some kind of virtualization that would allow packages to run in different library dependency environments (perhaps by manipulating paths or even using "fake root" environments). Alternatively, greater use of static-linking might be made as needed to resolve conflicts.

Author information

Terry Hancock's picture


Terry Hancock is co-owner and technical officer of Anansi Spaceworks. Currently he is working on a free-culture animated series project about space development, called Lunatics as well helping out with the Morevna Project.