CUPS: To Fork or Not?

Latest response

We have more than a few challenges in the technology area of RHEL printing. Among them is the direction that printing is going on other Linux distros, the ability to print to and from the cloud, clustered print high availability, and printing between virtual instances. The ability to provide easy-to-use printer-system output in an enterprise environment that has pools of high-end printers and other output (read plotter, etc.) devices remains a barrier to adoption that has already cost us growth overseas.

 

My net message is that in the enterprise, the promised paperless office has not only not yet materialized, but my fear is that it will not appear any time soon. Business systems today still require output that one can touch in many different forms.

 

Background:
There are a few issues and challenges with having our vision for RHEL printing implemented upstream. Under discussion is whether or not to fork.

 

Who:
This decision would affect both Fedora and RHEL, as well as related products. As such, our subscriber base would be impacted.

 

What:
The end users should see no change in use or operation of their printing services: the software interface should still allow for drivers written for CUPS.

 

Why:
If the ability to have desired printing features implemented upstream is disrupted, this could lead to enterprise-level subscribers having hard-copy and ease-of-adoption issues.

 

When:
I feel we have an open timeline to discuss and decide our direction on this issue. Since CUPS works now, we just need to expand the driver base and ease of use in GNOME 3 when it is available.

Responses