Red Hat to stop packaging LibreOffice for RHEL
- Reference: 1686136506
- News link: https://www.theregister.co.uk/2023/06/07/red_hat_drops_libreoffice/
- Source link:
According to a [1]post on the Fedora Development mailing list, the official RPM packages for LibreOffice in RHEL have been orphaned — in other words, they no longer have an official maintainer. 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 [2]Red Hat layoffs back in April , which [3]resulted in calls to unionize . The proximate cause seems to be that the Hatter who was the product's lead maintainer, [4]Caolán McNamara , has quit and gone to [5]work for Collabora, the primary company behind the ongoing development of the FOSS office suite.
[6]
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 [7]volunteered to take over. The suite does have a formidable [8]list of dependencies, but developers [9]Mattia Verga and [10]Michael J Gruber have offered to assist with them.
[11]
[12]
In the longer term though, Fedora may well switch to using a Flatpak-packaged version. LibreOffice itself already has an official Flatpak edition [13]available on the Flathub app store. However, the Fedora Project can't directly use that in its installation media, as developer Michael Catanzaro [14]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, [15]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 [16]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 [17]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.)
[18]
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 [19]offloaded its LibreOffice development team to Collabora, forming the core of that company's [20]Productivity division . That's how one of the project leads at Collabora, Michael Meeks, [21]ended up at Collabora in the first place.
[22]
Some commentators have [23]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 [24]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 [25]releases page currently lists over 30 different versions of Ubuntu which are currently in active support.
[26]Oh Snap... Desktop Ubuntu Core to arrive in 2024
[27]Red Hat promises AI trained on 'curated' and 'domain-specific' data
[28]Red Hat releases RHEL 9.2 to customers, with buffet of rebuilds for the rest of us
[29]Sonatype axes 14 percent of staff, reminds them not to talk to the press
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, [30]formerly known as Phoenix , was [31]carved out of Netscape's Communicator suite 20 years ago. The official [32]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. ®
Get our [33]Tech Resources
[1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/46ZZ6GZ2W3G4OJYX3BIWTAW75H37TVW6/
[2] https://www.theregister.com/2023/04/24/ibm_red_hat_layoffs/
[3] https://www.theregister.com/2023/04/28/red_hat_layoffs_union/
[4] http://caolanm.blogspot.com/
[5] https://meeksfamily.uk/~michael/blog/2023-05-15-caolan.html
[6] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/applications&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=2&c=2ZICpoQd3lpFsKUbE8b0bWgAAAMI&t=ct%3Dns%26unitnum%3D2%26raptor%3Dcondor%26pos%3Dtop%26test%3D0
[7] https://lwn.net/ml/fedora-devel/OX98HiWs2WoxY9jjRvEoko02vu9Dtdvcpv9x-K3TGs58-B_YLkbuoQPM9hw9kj1OOKzU6dGepT6NBRxxsnbjPezx9Wr7uF7GaNHfOyi29iU=@protonmail.com/
[8] https://lwn.net/ml/fedora-devel/u5b96q$3tk$1@ciao.gmane.io/
[9] https://lwn.net/ml/fedora-devel/8baff7ba-738a-7b4b-6f17-f8b3dff9410c@proton.me/
[10] https://lwn.net/ml/fedora-devel/20230605150035.10178.26164@mailman01.iad2.fedoraproject.org/
[11] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/applications&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZICpoQd3lpFsKUbE8b0bWgAAAMI&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[12] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/applications&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZICpoQd3lpFsKUbE8b0bWgAAAMI&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[13] https://flathub.org/apps/org.libreoffice.LibreOffice
[14] https://lwn.net/ml/fedora-devel/MNGOVR.8J0S7QLKZFDI2@redhat.com/
[15] https://docs.fedoraproject.org/en-US/fesco/
[16] https://news.ycombinator.com/item?id=36180888
[17] http://download.documentfoundation.org/libreoffice/stable/
[18] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/applications&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=4&c=44ZICpoQd3lpFsKUbE8b0bWgAAAMI&t=ct%3Dns%26unitnum%3D4%26raptor%3Dfalcon%26pos%3Dmid%26test%3D0
[19] https://www.suse.com/news/suse-partners-with-collabora-to-deliver-commercial-libreoffice-support/
[20] https://web.archive.org/web/20140221032500/http://www.collabora.com/press/2013/09/collabora-productivity-targets-a-marketplace-of-one-billion-desktops.html
[21] https://meeksfamily.uk/~michael/blog/2013-09-03-collabora.html
[22] https://pubads.g.doubleclick.net/gampad/jump?co=1&iu=/6978/reg_software/applications&sz=300x50%7C300x100%7C300x250%7C300x251%7C300x252%7C300x600%7C300x601&tile=3&c=33ZICpoQd3lpFsKUbE8b0bWgAAAMI&t=ct%3Dns%26unitnum%3D3%26raptor%3Deagle%26pos%3Dmid%26test%3D0
[23] https://www.ypsidanger.com/the-distribution-model-is-changing/
[24] https://www.theregister.com/2010/11/12/apple_oracle_openjdk_project/
[25] https://wiki.ubuntu.com/Releases
[26] https://www.theregister.com/2023/06/06/desktop_ubuntu_core_in_2024/
[27] https://www.theregister.com/2023/05/26/red_hat_ai/
[28] https://www.theregister.com/2023/05/19/rhel_92/
[29] https://www.theregister.com/2023/05/10/sonatype_job_cuts/
[30] https://www.theregister.com/2009/11/09/mozilla_on_google?page=2
[31] https://www.theregister.com/2003/04/03/cleaner_lighter_mozilla_vowed/
[32] https://download.documentfoundation.org/libreoffice/stable/7.5.3/rpm/x86_64/
[33] https://whitepapers.theregister.com/
Re: Original star office
StarOffice's 'Desktop' was more like what Windows 3.x once had included as a 'Program Manager' application, rather than a complete desktop environment. That said, the developers actually had implemented much of their windowing stuff themselves at that point, the intention was to make cross-platform development easier. The 'Desktop', though, was the first thing that was thrown overboard when StarOffice was mutilated to become OpenOffice after Star Division was sold to Sun, and contrary to several other components which were thrown away in the transition, like the calendar plus scheduler, the full-fledged e-mail and usenet client or the excellent MDI implementation that kept 'everything in one place' and interoperable (what had been Star Division's marketing slogan at one point), didn't clutter the screen with copies of the same menu and button bars on each separate document window—having to do without that 'Desktop' thing was no real loss. All in all, though, OpenOffice was just the sorry leftovers from what StarOffice 5.x had originally been, and the feature richness, and, in parts, even the usability that StarOffice offered has never been reached again, not even in the latest versions of LibreOffice.
Re: Original star office
I once read that early versions of OO & maybe LO had SeaMonkey tucked away inside but never exposed, mostly to get access to the address book database, which seems a bit excessive.
Mail/Usenet/RSS/Calendar functionality is the one thing that's really missing even if only to stop Office fans whining that it doesn't have them.
...[libreoffice]...number 374 different files.
Yes, a lot. But have you taken a look at the Fedora TeXLive, Perl or Python distributions? They are all monsters.
And that is the problem with big projects. They can grow to incredible complexity and then, at some probability, [1]Xkcd 2347 happens and we pull out our precious hair from our bald skulls.
[1] https://xkcd.com/2347/
a lot of files....
For LaTeX there is a separate file for each font (ok, three files), and there are files for each document style. This also means that you can carve that into different sets - you will probably not need fonts and document styles for any and all languages on the planet and every publisher / university / edge case. One file (or maybe one subdirectory) for each LaTeX package / class / font info. Modularity. Oh, and also human readable, easy to fork into your own package / class, easy to extend. Yes, the not-so-recent transition in handling fonts (a decade or so ago?) broke a lot of stuff, but those changes do not happen at a high rate. So in some cases it does make a lot of sense to have all those things separated out.
Oh, and an alternative would be to build one supermassive executable that contains all the stuff from those 374 files. Not sure if that makes more sense...
I agree that having all of those files in one flatsnappak is... suboptimal (or actually actively horrifying) - but then the "modern" way encourages you to bring in every dependency for every program separately. Remember what happened when computer games all came with their own DirectX (ActiveX?) library? *shudders*
Re: a lot of files....
I agree with all you say, but the beer is for your "flatsnappak".
What about requirements for secure documents?
I'm sure that many companies don't care if their employees are putting sensitive and mission-critical information in docs "in the cloud" through any of the many office tools available. What could possibly go wrong? I'm sure any hackers who get into their data won't do anything bad, such as sell their plans and data to their competitors.
But what about information that needs to not only be held securely, but must be *provably* held securely? Such as work by government agencies, law enforcement and legal work where an accusation of unauthorized information disclosure can have serious repercussions whether or the disclosures actually happened.
Dropping LibreOffice support and development means they are deprecating the desktop. Sad.
Re: What about requirements for secure documents?
I don't see the sky falling here for friends of local LibreOffice (like me).
Recall this was about RHEL, which ships pre-obsoleted versions of everything. If you want an up-to-date LibreOffice, installing it from RPMs is no big deal (or from Flatpacks I guess, a technology I have so far never tried). I used to run CentOS and always had to do this upgrade to get a sensible version. (Now I run more up-to-date to date distros on desktop).
I have to disagree with yet another cloud evangelist article
Yet another article waxing poetic about how people don't need any actually good programs and tools to do their work.
Oh some shoddy, slow, barely functional web based piece of garbage is all anyone needs.
Sorry but if you want to actually have good productivity you need good software and usually that means fully featured programs often running locally.
A good example is how much more productive you can be using a full version of Microsoft Outlook as opposed to relying on something like Gmail in a web browser.
These days and fairly counter intuitively you want to try to rely on projects with the *least* commercial backing possible. Less risk of arbitrary cost reductions and a better chance of lifespan.
I suspect that far less people actually need commercial support contracts than they think too.
The industry is completely upside down and broken.
Also, LibreOffice creeps me out. Their relationship with their partners is too close. They will try to move you to the Collabora Online cloud in any way possible. Perhaps RHEL was just sick of maintaining the "Community Edition" of LO (including that tacky banner) on their own.
This might be my tin foil hat speaking but you see some unreasonably passionate people in the LO vs OOo debate/argument and I just wonder if this is simply LO's maximum market penetration strategy at work in order to aid their monetization efforts.
Debian also packages LibreOffice but the current version there, as I assume is also the case with RHEL, is quite old. A quick trip to https://www.libreoffice.org/download/download-libreoffice/ brings a choice of the Business Edition and Community editions.
The Community edition comes in the advanced ("If you're a technology enthusiast, early adopter or power user, this version is for you!") and more conservative "This version is slightly older and does not have the latest features, but it has been tested for longer.") versions, currently 7.5.3 and 7.4.7. For each of those there's a choice of 64-bit Linux, DEB & RPM packaged as .tgz; Mac, Intel & Apple; and Windows, 32 & 64-bit. For each of these there's the language and help packs for your preferred language.
The DEBs install or update in /opt with any library files they need, with integration into the KDE or Gnome desktop and without fuss. It's an arrangement that Just Works. This is the established solution to the problem that Flatpak, Snap etc unnecessarily set out to solve.
It would be useful if DEBs could be kept in either Debian's contrib repository or in a Debian-style repository of LO's own so they can be updated by apt. I assume the RPMs could be dealt with similarly.
Perhaps this move by RH will prompt LO to set up suitable repositories.
Original star office
I remember using Star Office in the early days on Windows. It installed a completely new desktop environment. I dread to think of that still being in there somewhere.