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.
