The future of Gutenprint (warning: long and opinionated)

--===============2990426569881631347==
Content-Type: multipart/signed; micalg=pgp-sha512;
	protocol="application/pgp-signature"; boundary="IJkVut3ZKYbY4KKl"
Content-Disposition: inline


--IJkVut3ZKYbY4KKl
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Now that the long-delayed 5.3.5 release is out, it's time to talk about=20
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=20
for improvement, it generally does what it claims to do.  In that sense=20
Gutenprint doesn't need much ongoing maintenance; just fixing bugs as=20
they show up and occasionally adding support for addtional printers. =20
This has effectively been the status quo for some time, but=20
unfortunately, while Gutenprint itself is stable, the rest of the=20
printing world is not.

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

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

 ~ ~ ~

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

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

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

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

    Currently this includes high-end Epson Injket printers used to create=
=20
    "fine art" prints, often involving bespoke ink and media.  These=20
    printers expose numerous knobs to ensure the output can be carefully tu=
ned
    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=20
    those used in photo booths or drugstore kiosks) and other/similar=20
    models that are used in commercial/production-focused contexts.

Both of these tend to be expensive, have long product lifecycles (that=20
routinely exceed a decade) and nearly always operated on a commercial=20
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=20
that have an old printer and want to keep using it for typical=20
home/office stuff. Similarly, it would not likely take too much effort=20
to finish the incomplete native application to the point where it would=20
be an effective replacement for the retrofit applicaiton for these=20
tasks.

However, for those two sets of "modern" printers that we believe make up=20
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=20
knobs is utterly necessary.  As IPP (or more accurately, common IPP=20
print clients) is not currently up for this task, this will likely need=20
to be done from within the printer application itself, through some sort=20
of (web-based) user interface; This needs to be planned, prototyped,=20
developed, and maintained, and is likely to involve allowing the=20
creation and management of selectable profiles that would potentially=20
include adjustments to virtually every knob the printer supports. This=20
is a _huge_ undertaking.

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

This is on top of other work that Gutenprint desparately needs,=20
including:

 * Finally migrate off of Sourceforge (likely to codeberg or sourcehut)=20
 * 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=20
planning, development, and ongoing maintenance across a broad swath of=20
skillsets.  The problem is... we don't have that.

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

Even putting aside this large pile of TODOs, this is not a sustainable=20
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=20
happen.  Or if it happens at all, it will be on an extremely glacial=20
scale, driven primarily by the self-interest and time availability of=20
that one contributor.

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

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

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

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

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

 ~ ~ ~

There are two general rules in play.  The first is the so-called golden=20
rule -- "Whomever has the gold, makes the rules". If there is no gold=20
involved, the second rule kicks in -- "Whomever does the actual work=20
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=20
   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=20
end of Gutenprint development, at least until a sufficient infusion of=20
money and/or manpower comes along.  Or that one contributor gets taken=20
out by some sort of Florida Man shennanigans.

 ~ ~ ~

What would be considered "sufficent"?  We don't have a good answer for=20
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,=20
when most of Gutenprint's userbase (or at least the portion that would=20
benefit the most from this work) is actively using it to make money, one=20
tends to get a grumpy when you realize everyone other than you is=20
getting paid.  This is not an exaggeration; entire industry verticals=20
have been built on top of Gutenprint.

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

Logically, one would expect systems integrators to treat Gutenprint as a=20
critical supplier instead of an infinite free resource (and nearly=20
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,=20
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=20
don't think it's worth continuing meaningful work on "classic"=20
Gutenprint.  The retrofit application will work fine for folks with=20
ancient printers until they inevitably fall to prey to the vagracies of=20
time.

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

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

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

Comments and feedback welcome.  Contributors even more so.

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

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

--IJkVut3ZKYbY4KKl
Content-Type: application/pgp-signature; name=signature.asc

-----BEGIN PGP SIGNATURE-----

iQIzBAABCgAdFiEE3H5Sx9DyiyB5hnENrGLLO/XVulEFAmfW98oACgkQrGLLO/XV
ulE+Eg//Tsullad2Gntd+PQHbbs5grtonzARmrwgL8IILRLNVH4cPsrqlmJ0rOsH
QQctX4ToKXfiOuBzcdUpe7aakNzMIgLxjIyzv9+RWqIiuVxqclWXDloLxHu4wPcT
rM4Xub7oN1FCM9rAZ6oX6m4/JwMvfmKyEc2GIwcPDa4iWUrBNha4Pz+ADOhhS+pW
+Ss2XJR7tBQePET6HBbn6SChN2EogQRHDnp9jJ68uEwjHzB9tci0Kg1hNB0V1tEQ
DsXB3xBqg4a/yX52cAklB/AGTvceRB0rUKAWrsKgcDJwOUVmYXmszPyctODAa8JN
L5Bkww291uARzUUhHqX4XUeHnaULFukOGey4vJ0bWM//uHirdKXxP7l39dHsO+JO
qpkMWPeCUpZgHIeybh2MLxk2awn64bGVN1zZYYdlLhgbQiOAm0DauTS+IdiZpfbp
wivksXxtQmJUcZmBEtmsynXUZz+dp0OAu9jCD85J3hnGYfEYIqv42xyHcRP4pCx3
yKggz2D4WPJGWEbFM/tiIaiOfbkXh2yypb9t21SALhYjzGnJBgGNERGOlGQkRMzl
xwHLE07n4uPCEyFI/FEsmtM3x7haStAR/ZkbPhfULAD1JBzpiDYT9BvtpUoeamvg
g4DH+O+dLi89a3d7DEm7MRrAQU037J2Uhrs+Wp5No2c6MVX4U7E=
=ry6Y
-----END PGP SIGNATURE-----

--IJkVut3ZKYbY4KKl--


--===============2990426569881631347==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline


--===============2990426569881631347==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Gimp-print-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/gimp-print-devel

--===============2990426569881631347==--