The Future of Gutenprint (long and opinionated)

Solomon Peachy

This was originally posted to the Gutenprint development mailing list.

Now that the long-delayed 5.3.5 release is out, it's time to talk about Gutenprint's future.

"Everyone wants to create, but nobody wants to maintain. There is no glory in maintenance."

Gutenprint itself is stable and mature. While there are always areas for improvement, it generally does what it claims to do. In that sense Gutenprint doesn't need much ongoing maintenance; just fixing bugs as they show up and occasionally adding support for additional printers. This has effectively been the status quo for some time, but unfortunately, while Gutenprint itself is stable, the rest of the printing world is not.

For many years now, the greater printing ecosystem has been undergoing a foundational shift away from traditional OS/platform-specific printer drivers (such as Gutenprint) towards "driverless" IPP. Nearly all printers released within the past five to ten years JustWork(tm) out of the box, using driverless IPP, either over a network connection or tunneled over USB.

In other words, modern printers don't generally need something like Gutenprint. Meanwhile, older printers tend wear out so that over time, fewer and fewer remain in service. (There are some notable exceptions, and we will get to that later)

~ ~ ~

Currently, CUPS itself acts as an driverless IPP wrapper around traditional PPD-based CUPS drivers. This will go away in the very near future, but the folks over at OpenPrinting came up with so-called "retrofit printer applications" that provide similar functionality in a self-contained manner.

Additionally, last fall a GSoC project created a "native" Gutenprint printer application around PAPPL. This differs from the "retrofit" insofar as it directly interacts with libguenprint instead of its CUPS/PPD driver wrapper, but it is not in a usable state, and completing it may not actually make sense, for reasons to do with those aforementioned exceptions.

Basically, at this point, there are only two sets of "modern" printers that still need a traditional "driver" like Gutenprint:

Models that provide an additional low-level/native protocol that allows a much higher degree of control over what is exposed via IPP.

Currently this includes high-end Epson Injket printers used to create "fine art" prints, often involving bespoke ink and media. These printers expose numerous knobs to ensure the output can be carefully tuned to achieve the highest possible quality.
Models that do not provide driverless IPP functionality at all.

Specifically, high-speed dye-sublimation photo printers (such as those used in photo booths or drugstore kiosks) and other/similar models that are used in commercial/production-focused contexts.

Both of these tend to be expensive, have long product lifecycles (that routinely exceed a decade) and nearly always operated on a commercial basis; that is to say they are used to make money for their operators.

The current retrofit application will more than suffice for the folks that have an old printer and want to keep using it for typical home/office stuff. Similarly, it would not likely take too much effort to finish the incomplete native application to the point where it would be an effective replacement for the retrofit application for these tasks.

However, for those two sets of "modern" printers that we believe make up the primary user base of Gutenprint today, the incomplete application will require extensive additional work before it would be usable.

For the high-end inkjets, a way to usably expose the numerous control knobs is utterly necessary. As IPP (or more accurately, common IPP print clients) is not currently up for this task, this will likely need to be done from within the printer application itself, through some sort of (web-based) user interface; This needs to be planned, prototyped, developed, and maintained, and is likely to involve allowing the creation and management of selectable profiles that would potentially include adjustments to virtually every knob the printer supports. This is a huge undertaking.

For the dye-sublimation models, the current retrofit application is not even usable because it completely lacks the custom USB backend, which needs to be ported and integrated to work within PAPPL. There are additional UI/UX warts without easy solutions, and numerous other bits of functionality (eg extensive diagnostic information) that need to be exported, and architectural issues within Gutenprint itself that need addressing before we will be able to fully take advantage of the new functionality that IPP can enable.

This is on top of other work that Gutenprint desperately needs, including:

Finally migrate off of Sourceforge (likely to codeberg or sourcehut)
Rework the www site into something modern and relevant
Finish cleaning up the litany of build warnings with modern compilers
Port the GIMP plugin to GIMP3 (ie GEGL and GTK3)
Modernize build system (eg modernized autotools or cmake)
etc

Most of these are in of themselves significant undertakings, requiring planning, development, and ongoing maintenance across a broad swath of skillsets. The problem is... we don't have that.

At its peak, Gutenprint only ever had a handful of active contributors, but shortly after the 5.3.4 release that number fell to just one, where it has languished ever since.

Even putting aside this large pile of TODOs, this is not a sustainable position. What happens if that remaining person gets crushed by a tree?

~ ~ ~

The bottom line is that as things stand today, none of this work will happen. Or if it happens at all, it will be on an extremely glacial scale, driven primarily by the self-interest and time availability of that one contributor.

This is not just a matter of funding, except in the sense that a sufficient amount of guaranteed funding can be used to pay for suitably-skilled contributors.

As a poignant example of this, over the course of the past three summers, Google sponsored three GSoC attempts to create a Gutenprint printer application. The first two completely ghosted us, and the third looked to be heading in the same direction before they unexpectedly delivered delivered passable (if incomplete) code at the 11th hour.

Even at the lowest end of the GSoC compensation scale, these three students were collectively paid at least triple the amount of funding that Gutenprint itself received during the same time period. This is actually much worse than it sounds; if not for a generous no-strings-attached "thank you" donation from a commercial ISV, the total donations over that three year period would have totaled less than $160! This greatly-appreciated donation didn't fully cover Gutenprint's costs (eg acquiring hardware and media) over that same period.

It is clear these GSoC participants did so for the stipend rather than of any interest in Gutenprint or printing in of itself. There is nothing inherently wrong with that, but when one factors in the time and effort Gutenprint (and OpenPrinting) spent on mentoring, it was probably a net loss when one considers that none of the participants elected to continue contributing after they were no longer being paid to do so.

Frustratingly, if those same funds had been paid directly to Gutenprint instead, it would have all but guaranteed completion of the scoped work, and likely much more. But that window of opportunity/availability has long since closed.

~ ~ ~

There are two general rules in play. The first is the so-called golden rule -- "Whomever has the gold, makes the rules". If there is no gold involved, the second rule kicks in -- "Whomever does the actual work gets to decide what/how it is done"

Given that there is nobody waving around any gold, and there is only one person doing any work, where does that leave Gutenprint?

Will stay on Sourceforge for the time being
No feature development planned
No additional printer support planned
Gutenprint will continue receiving bugfixes as needed
Folks can use the retrofit printer application when CUPS finally drops the guillotine on PPD-based drivers
No plans to resume work on the WIP native printer application

In other words, other than critical bugfixes, this is effectively the end of Gutenprint development, at least until a sufficient infusion of money and/or manpower comes along. Or that one contributor gets taken out by some sort of Florida Man shenanigans.

~ ~ ~

What would be considered "sufficient"? We don't have a good answer for that, but it's going to be infinitely larger than the 'nothing' of today.

While we don't begrudge folks from making money using Free Software, when most of Gutenprint's userbase (or at least the portion that would benefit the most from this work) is actively using it to make money, one tends to get a grumpy when you realize everyone other than you is getting paid. This is not an exaggeration; entire industry verticals have been built on top of Gutenprint.

Logically, one would expect printer manufacturers to consider it in their best interest to ensure their printers are well supported under Linux -- even at the minimal level of providing documentation and loaner models would be beneficial, as opposed to sending legal nastygrams while their own salescritters are actively sending Gutenprint builds to their customers! (This has happened more than once)

Logically, one would expect systems integrators to treat Gutenprint as a critical supplier instead of an infinite free resource (and nearly inevitably violating Gutenprint's GPL license along the way..)

Instead, they have created an XKCD #2347 situation.

~ ~ ~

So, all that said, where would this contributor like to see things go, if sufficient time and/or money was made available?

(Ho-ray, no more speaking in the third person)

As one can probably surmise from the wall of text preceding this, I don't think it's worth continuing meaningful work on "classic" Gutenprint. The retrofit application will work fine for folks with ancient printers until they inevitably fall to prey to the vagaries of time.

The glaring exception to this are dye-sublimation (and other thermal) printers. Indeed, over at least the past five years these have represented the primary area of (expressed) user interest and actual deployments. (There's also the aforementioned Epson injkets, but that's not something I personally care about)

Consequently, I think it makes more sense to build out a new printer application that caters solely to these dyesub models. It would borrow some printer-specific code from Gutenprint (and re-use most of the backend) but will otherwise be a clean-sheet implementation. It still faces numerous hurdles but not having to uplift the rest of Gutenprint along the way will greatly reduce the overall project scope and complexity.

This also aligns with my personal interests, but unless other interested parties step up with funding or other resources, it will remain a (very) part-time effort, if it gets started at all -- My personal printing needs can be met by just keeping an old CUPS installation around, and I'd rather spend my evenings with my family and my weekends doing things outside -- really, anything other than staring at a computer screen performing unpaid commercial software development.

Comments and feedback welcome. Contributors even more so.

But any proposal that entails my undertaking more unpaid work for other folks' benefit will be mercilessly mocked. This goes double for suggestions on how to make Gutenprint "more attractive to potential contributors" unless that suggestion comes in the form of a bag of cash.