[Gimp-print-devel] The future of Gutenprint (warning: long and opinionated)

[Solomon P. <pi...@sh...>]

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 addtional 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 
tradtional 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:

 1) 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.

 2) 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 applicaiton 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 desparately 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 littany 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 commerciaal 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 shennanigans.

 ~ ~ ~

What would be considered "sufficent"?  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 Gutentprint 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?

(Horay, 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 vagracies of 
time.

The glaring exception to this are dye-sublimiation (and other thermal) 
printers. Indeed, over at least the past five years these have 
represented the primary area of (expressed) user interest and actual 
deploments.  (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 
suggesions on how to make Gutenprint "more attractive to potential 
contributors" unless that suggestion comes in the form of a bag of 
cash.

 - Solomon
-- 
Solomon Peachy			      pizza at shaftnet dot org (email&xmpp)
                                      @pizza:shaftnet dot org   (matrix)
Dowling Park, FL                      speachy (libera.chat)