Thought I might touch a chord with the Adobe font rant.
graydon: Yes, unifont is cool stuff. It's not at all fair for me to say that there's nothing going on in the world of free software fonts. Reaching into history a bit, you'd also have to give the Metafont project major props both for incredible technical innovation and a library of highly distinctive, useful fonts.
But my point still stands; if you try to point to any free font work that directly compares with Adobe's latest OpenType efforts, you will come up empty.
Regarding compilers and other bits of infrastructure: yeah, that stuff either needs to be free software or something very much like it. The idea of putting bits of this infrastructure into brightly colored shrinkwrap boxes distorts the whole endeavor incredibly destructively. Proprietary operating systems and tools tend to suck really hard because of this. However, the new Adobe fonts most emphatically do not suck.
Mulad: I'm not complaining that there's no money for free software development. In fact, I manage to get paid pretty well for the work I do. What I'm complaining about is the indirect nature of this funding. OctobrX, Raster, and others are in the position of being sponsored by a patron (in their case, a public corporation losing money at a dizzying pace). Further, I support my free software habit through consulting and other "day job"-like activities. It's a very different thing than simply being paid for the work I do, an option provided by the proprietary model, but denied me by free software.
Let me try to present my argument again. All software sucks, most of it pretty badly. When you try to analyze the causes of this suckage, two winning strategies to make software suck become immediately apparent.
First, you can fail to bring adequate resources and talent to the project, dooming it to being hopelessly amateur. For some projects, free software does manage to make these resources available, mostly for bits of widely-needed infrastructure. For many others, it simply doesn't.
Another good way to make software suck is the familiar story of decommoditization: basing it on complex, ambiguous, and ever-changing "standards" as a way to create lock-in and drive the upgrade treadmill. Microsoft Office is basically a canonical example of this, but certainly not the only one.
Note that neither proprietary nor free software have a lock on either kind of suckage. For example, I consider sendmail a really good example of a piece of software which has managed to lock in its market segment by being bad. And for demonstrations of lack of resources, just look at any segment of the market without an ultra-compelling economic argument, for example Be applications.
All I'm saying is that whenever somebody comes up with software that doesn't suck (or sucks less, anyway), we should sit up and take notice, and ask how it came into existence in spite of the powerful forces which always seem to subvert it.
Over the past few days, I've had the pleasure of speaking with the creators of both Inti and Gtk-- about techniques for wrapping C libraries with C++ API's (this is in the context of Libart). It's not hard to see how the split came about. These two projects have radically different approaches. Karl Nelson seems to be in love with every trick in the C++ book. He encouraged me to consider multiple inheritance, using streams for operations on images, String-like objects for paths with copy-on-write semantics, and more. Havoc, on the other hand, encouraged me to use refcounted pointers, with a link back from the C object to the C++ counterpart. Inti is basically very C-like (ie, pointers are still pointers), but with type-safety and some other nice features that C++ provides. Even though the relative simplicity of Inti appeals to me, I don't think it's what I want. A user of Libart will often create many short-lived objects. It makes a lot of sense to use stack (auto) allocation for those - you get static enforcement of constructor/destructor pairing, almost for free, and code is a lot cleaner if it doesn't have a lot of explicit memory management stuff hanging around.
Taking a step back from the Inti/Gtk-- split for a minute, though, I'm convinced that the real problem is simply C++'s overweening complexity. Providing a nice, high-level wrapper for Libart should be a relatively simple task. However, C++ makes my design space really, really big, especially when it comes to options for memory management. I'm becoming more attracted to C++ now that it's (sorta) becoming a standard, and that decent implementations are becoming available, but I also feel that constant vigilance is needed to fight back the complexity that the language introduces, to keep it from infecting the rest of the project.