I’m not a fan of Flatpak or Snap containerized packages. Flatpaks are huge and you’ll waste a lot of disk space with one over a native application, and they’re a bit slow to load. You’ll slow down your system if you ran a lot of them, or the GNU/Linux distribution moved to all containerized applications (some exist). The only advantage I see is for closed source software to be distributed in a way that will work on many distributions, and up to you if you want to run such programs. Consequently, these corporations are foisting them on GNU/Linux users to simplify their work and use of resources as the article below lays out. If users don’t use their platforms, they’ll be minimized and not gain undue traction (Ubuntu was phasing out Snap except for their new unmutable OS version they’re developing, having lost to Red Hat’s Flatpak). I do have a couple AppImage cryptocurrency containerized packages I run, but that’s an open platform I’m not opposed to and it won’t replace native applications managed by my distribution’s package manager other than for a couple niche packages. And this is GNU/Linux after all, you can always download and compile the source code yourself as well as make any changes you would like (or contract someone to do on your behalf).
https://www.theregister.com/2023/06/07/red_hat_drops_libreoffice/
By Liam Proven
Red Hat is to stop packaging a native version of the LibreOffice suite for its enterprise Linux distro.
According to a post on the Fedora Development mailing list, the official RPM packages for LibreOffice were orphaned. Existing RHEL releases 7, 8, and 9 will still be updated, however.
The official stated reason is that the company is switching manpower to fixing more critical issues, such as support for high dynamic range displays, and that uses of the RHEL workstation distro who need LibreOffice can install the Flatpak version instead.
This doesn’t seem to be a direct result of the well publicised Red Hat layoffs back in April, which resulted in calls to unionize. The proximate cause seems to be that the Hatter who was the product’s lead maintainer, Caolán McNamara, has quit and gone to work for Collabora, the primary company behind the ongoing development of the FOSS office suite.
But this did pose a problem for the Big Purple-backed free distro, Fedora, and as a result, a considerable thread grew from the post. A new maintainer, Gwyn Ciesla, has already volunteered to take over. The suite does have a formidable list of dependencies, but developers Mattia Verga and Michael J Gruber have offered to assist with them.
In the longer term though, Fedora may well switch to using a Flatpak-packaged version. LibreOffice itself already has an official Flatpak edition available on the Flathub app store. However, the Fedora Project can’t directly use that in its installation media, as developer Michael Catanzaro explains:
For Fedora Workstation, the mid-term plan is to ship all preinstalled apps as Fedora Flatpaks. We cannot ship anything from Flathub because FESCo will not allow it. I don’t like this FESCo requirement, but I also don’t expect that to change.
(Just for clarity, FESCo is the Fedora Engineering Steering Committee.)
LibreOffice is a formidably large and complicated piece of code, comparable in complexity to an entire Linux distro in its own right — one Hacker News commentator memorably described it as “one massive incomprehensible pile of ancient rotting C++ and Java code, dragged along over 38 years [since] StarOffice.” On top of this, the Document Foundation itself also publishes RPM packages of the suite, at least for x86-64.
Sadly, foisting off LibreOffice to be externally maintained not only reflect the trend towards cross-distro packaging formats, it also reflects the trend towards ever-increasing use of web-based apps inside large corporations… and that itself can be seen as a manifestation of the Pareto principle, more familiarly known as the “80:20 Rule”: 80 per cent of the users of RHEL or Fedora only want 20 per cent of the functionality of LibreOffice. (Of course, the eternal problem is that they don’t all want the same 20 per cent.)
Most users of RHEL Workstation are almost certainly members of staff at large corporations, and it’s already becoming clear that most such people only need a small subset of the vast range of functionality of a full, rich, locally installed office suite — instead, they are often content with the relatively limited functionality of a web based office suite, such as Google Apps or Microsoft 365, especially as such tools make collaboration with other workers very much more convenient. You don’t need to worry about what shared drive it’s saved on, or how you connect to it, or about having correctly configured font or template libraries, or file names or folders or any of that 20th century baggage.
If you do need such functionality, well you’re probably in a minority, but you will still be able to install a local office suite — you just won’t get the full enterprise support that Red Hat makes its living by selling.
SUSE made a comparable decision a decade ago, and offloaded its LibreOffice development team to Collabora, forming the core of that company’s Productivity division. That’s how one of the project leads at Collabora, Michael Meeks, ended up at Collabora in the first place.
Some commentators have welcomed the move, and they make a persuasive point in the humble opinion of the Reg FOSS desk.
The broader strategic thing happening here isn’t about office suites. It’s more to do with packaging formats, and web apps, and whether you can effectively use other companies’ existing efforts to reduce — or even eliminate — internal costs. For instance, compare with how Apple persuaded Oracle to take over maintaining the macOS JVM.
As we’ve pointed out before, a frequently overlooked advantage of things like Flatpak and Snap packages is not just that they run on different distributions: It’s that they run on different versions of the same distribution. So, for example, the Ubuntu releases page currently lists over 30 different versions of Ubuntu which are currently in active support.
In principle, a single Snap-packaged version of Firefox can run on all of them. (At least for a single processor architecture, anyway.) The savings for Canonical in having one package of this rapidly changing application which can run across dozens of different versions of its own distro are in principle so significant that if that package can run on other distributions too – well, that’s just a handy bonus that it gets for free.
Firefox is at heart a single binary: it’s the standalone web browser, formerly known as Phoenix, was carved out of Netscape’s Communicator suite 20 years ago. The official RPM packages for LibreOffice 7.5.3 on x86-64 number 374 different files. Integrating, and supporting, that is quite a significant burden. We wish the volunteer Fedora maintainers a lot of luck – they’ll need it.