Apple has picked up on CUPS and Gimp-print in a big way. Mac OS X 10.2 is using CUPS as the core of its printing system, and Gimp-print is providing a lot of the drivers.
They aren't actually bundling Gimp-print with OS X, but when Phil Schiller (top marketing guy) does a keynote at Seybold, and mentions Gimp-print for more than a few seconds, they're not exactly ignoring it. It's being made available for download on all of the OS X sites, and on VersionTracker.com it's getting (with very few exceptions, mostly related to the fact that until extremely recently Ghostscript wasn't available to handle applications generating PostScript output) rave reviews. One person even said that Epson pointed him at Gimp-print for his 2200, because they don't know when they'll have their own driver.
It's absolutely astounding how all of this happens. I certainly never imagined it would go mainstream to this degree; I expected uptake by Linux distributions, but since it's a piece of infrastructure I expected it to remain largely invisible. Reality is very different.
My sister in law has told me several times that she thinks I'm crazy for not having patented it and made my fortune selling it. Aside from the fact that it's rather difficult to patent a printer driver, and I'm a free software fan in general, it's interesting to note that there are a few proprietary driver packages for Linux/UNIX: Xwtools and PrintPro. The developer of Xwtools is actually making pieces of it free/GPL (in particular the excellent Epson Stylus maintenance utility, which is far nicer than our own escputil), and PrintPro has steady, but not spectacular sales in the corporate arena. However, neither of these packages has really taken off. I'm convinced that the free part is a direct cause of the developer interest, which is what's needed to create end user interest.
It's interesting to note how many users are really unhappy with printer vendors. From my own discussions, I believe that the problem is with the OS vendors, who historically keep changing their driver architecture, and with the printer vendors, who don't spend much on sustaining for their older models. I can't entirely blame the printer vendors; sustaining is very expensive and unpleasant. However, it's very apparent that at least some printer vendors essentially write new drivers for every printer model; the Windows GUI for the Stylus Color 800 is very different (and clearly much older) from that of the C80. A data-driven approach would help here.
This whole thing's actually really wild, and very exciting.
The functionality/architecture tradeoff
One thing that's disappointed me is that we haven't really looked all that hard at our internal architecture over the past few years. We've certainly cleaned up a lot of interfaces, but we've never moved toward the much more data-driven architecture I envisioned. This is as much my fault as anyone's; I haven't had a lot of real moments of inspiration on this front.
Most of my effort has gone into nibbling around the edges: tweaking the Epson family metadata schema to support newer printers, improving color fidelity in minor ways, playing around with dithering, and the like. There have been a lot of other sub-projects, such as a user's manual, that also aren't architectural in nature; most of the architectural work has gone toward improving the build system for both the code and documentation.
I'm becoming more and more convinced that this is actually a reason why Gimp-print has succeeded. Most of the work has gone into things with visible end-user effect; documenting how to actually use it,supporting more printers and improving quality is something people notice; low-level architecture isn't. Also, the base is stable; there have been zero changes to the API (as determined by commits to the gimp-print.h header file) in the 4.2 series, and exactly one minor addition (which may have important ramificationns for color management on photo printers later) thus far in 4.3. Is the API perfect? No; there are certainly things I'd like to change. But it's good enough, and probably a lot better than existing printing facilities can really use.
The 4.2 releases really have been stable -- 4.2.1 came out fully five months after 4.2.0; it did contain a number of bug fixes, but they were mostly corner cases. It also contained some new functionality: the IJS driver. 4.2.2 was almost five months after 4.2.1. It contained some more bug fixes (some rather important ones), but none were regressions. Most of its new functionality was support for new Epson printers. Of course, there have been prereleases and release candidates, but I'm overjoyed how stable we've managed to keep 4.2. 4.0 had five releases in the first month -- fortunately, 4.0.4 was solid -- but it's evident that we've matured as a project.
Color management
I discovered not long ago that the API can actually support color management, thanks to the 16-bit CMYK input method (the 8-bit CMYK and RGB inputs could too, but it wouldn't be as effective). We've done some experimenting, and discussion on the development list has heated up recently, so somebody (maybe even I) will come up with a prototype. There has already been one prototype (it isn't very practical in its current form for various reasons) that has demonstrated really dramatic results for certain colors that Gimp-print currently has difficulty with.