If your publisher requires word documents (or _any_ word processor format), you need to find a better publisher. I can understand if they prefer word for the text-copy, which is then pulled into a typesetting app. But to use that as the pre-press format is a terrible workflow. This isn't a limitation of LibreOffice, it's a limitation of not being competent in pre-press typesetting and publishing software.
There are really two, almost entirely separate, points there - one is about missing interpretability of LibreOffice, and the other is about the author's inability to install Microsoft Office on Linux.
I'd like to articulate a case why supporting the the author's use cases is likely uneconomical.
With respect to the LibreOffice interoperability with Microsoft Office: the author works in publishing, which requires almost pixel-perfect equivalence between how a document is displayed between them and their collaborators. Faithfully reproducing almost 40 years of evolution in the layout engine (some of which co-evolution with the Windows OS and the font system) necessitates a development program of mind-boggling proportions. It is absolutely no surprise to me that no entity, either commercial or open source can finance such an endeavor. (Even Microsoft does not exhibit 100% interop between the native Office and the cloud Office 365)
A similar argument applies to being able to install Office on Linux, with the added nuance that the major driving force behind Wine etc are game distributors, whereas Office compatibility is not a major priority, especially given the VM and Office 365 alternatives.
I agree with your point about interop on the level of file formats. We are talking decades of undocumented cruft at this point in the Office file formats - the MS implementations are so complex in a random and haphazard way that it's questionable whether they could ever be fully reverse engineered.
Running Office on Linux, on the other hand: I think the issue here is simply a lack of vision. Getting to where we are with Proton and Linux gaming today required Gabe Newell as an exceptionally gutsy and ambitious lunatic billionaire to just say, ok, we could spend what it takes and go the last mile here, and it happened. I'm quite certain that a similarly dedicated effort (actually a much smaller one) could get Office running perfectly on Linux, and that would be a huge win for anyone who was ambitious enough to try and claw the lucrative enterprise desktop market away from Microsoft. There's just no one out there yet who's been wealthy and crazy enough to go for this one.
The average person thinks all kinds of stuff is impossible when it's not, another great example is how everyone thought Gabe Weinberg had no chance of competing with Google, fast forward to today and DuckDuckGo makes $100M/yr and is probably going to benefit immensely when the govt's anti-trust remedies against Google kick in, no matter what they end up being. The world is Gabe's oyster and he's just a guy who had balls bigger than everyone else's, found a good angle and stuck with it.
> With a free price tag, it could easily do that. But, it first needs to provide the required functionality, and today, it stubbornly refused to that, for ideological reasons.
Very confused by the article, even after re-reading it. The author keeps bringing up ideology throughout the article, but is there any arguments or evidence given that this is a factor? The simplest explanation to me is that OOXML is a de-facto proprietary format, and implementing full compatibility with it is simply a large technical undertaking that LibreOffice doesn't have the resources to effectively achieve right now. They even hint at that themselves: "From what I've been able to decipher, no non-Microsoft Office program implements the full specification and follows it to the letter."
I agree with you. I disagree with the assertion from the author that LibreOffice refuses to implement the OOXML standard for ideological reasons; nothing was cited in the article supporting this assertion. If it were true that LibreOffice's developers only want to support open standards, then there wouldn't have been support for the pre-Office 2007 binary formats.
Yes, I believe that imperfect compatibility with Microsoft Office is holding LibreOffice back, but perfect compatibility isn't going to happen without massive resources. It's immense work being 100% compatible with a proprietary, under-documented standard. Without an army of developers, it's going to take a very long time. Think of how long it took Wine and ReactOS to get to today's usability, and those projects still have much work to do. Think of how long it took the HaikuOS people to release release-candidate issues of their project.
> I'm quite sure if it were easy to implement [feature A], LibreOffice would have done it
I've lost this optimism a long time ago when I realized how much denialism and how little actual factual, detailed knowledge there is among vocal proponents for Linux and free software. For example, the entire font handling stack on Linux is a hot seething mess of horrible dysfunctionality, wrongly implemented and starting out from the wrong principles (IMHO), yet nobody is working to improve it because everyone keeps telling you it's a solved problem.
More specifically, years ago ago I hacked together solutions to script LibreOffice from the 'outside' as it were because its macro system is such an utter painful failure in so many ways. Not only was a single website written in Japanese the only source for a reasonable rundown of LibreOffice's API, it also introduced me, indirectly, to the fact that the people who initially wrote OpenOffice were apparently not comfortable with Java being a strictly OOP language, so they did their best to write code that to a degree circumvents that, leading to a terrifyingly bad user experience and a hint of the convoluted horrors that might lurk in the source code.
The glacial pace of LibreOffice's development where the appearance of the tiniest of innovations leads, every few years, to great public announcements and a new version number, has convinced me that the community has painted themselves in a corner with an unmanageable code base and devs that are, likely, in complete denial that the only way out would be a complete rewrite of the software, something that is, understandably, too hard to stomach.
LibreOffice is not based on Java. Java was, IMO, bolted on when Sun took over. As for it circumventing the “strict OO” nature of Java, that makes no sense and I challenge you to back this up with a technical explanation.
LibreOffice does incremental development. It’s not in any way glacial. Every release has hundreds of feature updates and bug fixes. The quality and compatibility with Office is getting better over time, and though there is still a ways to go it’s hardly going slowly.
I’ve extensively looked at the LibreOffice source code, and I can tell you that a complete rewrite would be a major waste of time that would kill the project. The software has been around since the early 1980s. It has accreted layers, but even so those layers are pretty well defined. It’s why it can be ported to different architectures and desktop environments. It’s why it has so many language bindings.
I don’t think you have a very informed view of how LibreOffice is developed, or even how it works.
Lots of things that just don't smell right here. First of all, every experience I've had trying to get GDocs to play ball with DOCX has led to the same misery that comes with LibreOffice. It works fine until you use an unsupported font, or tables, or precise image layouts, etc etc etc.
DOCX is a proprietary format. Perfect support is categorically impossible. A best-effort attempt is the best we'll ever get, and IME LibreOffice tries a lot harder than other office suites do.
Also, for what it's worth... you know what GDocs and Word won't open? A document written in WordStar on a TRS-80 in 1983. You know what will open that document? LibreOffice. LibreOffice checks all the boxes for my spreadsheet/document writing needs, and it has also been an irreplacable tool in my data archival efforts.
> DOCX is a proprietary format. Perfect support is categorically impossible. A best-effort attempt is the best we'll ever get, and IME LibreOffice tries a lot harder than other office suites do.
Nah - well you’re correct that DOCX is under-defined - but the real the problem with LibreOffice is that it has 40 years of history supporting the wrong file format. Its internals are all built on models that later became ODF and any attempt to bolt-on the incompatible MS Office models is doomed to failure.
Both startups I've worked for used it exclusively - one of them being a med-tech with a boatload of documentation needs. A lot of schools have dropped MS Office as they've switched to Chromebooks.
None of this is to say GDocs isn't a miserable turd of a program. I'm convinced word processors have actually regressed in quality since the mid-2000s. GDocs somehow manages to be less featureful, slower, buggier, less user-friendly, and less compatible than Word XP. There isn't a single thing GDocs does better than an office suite that's pushing 25 years old, save for real-time collaborative editing which is hardly worth all the other compromises.
This sounds silly, but I encourage you to dredge up an old Windows XP system and a copy of Office XP. I was shocked to see how far we've strayed from the light.
In this modern age of .md and similar files why not try for "blue water sailing" and instead create an office suite which specifically plays to only open standards?
A word processor which supports the same style options as Google Docs and used pandoc to import/export would be as much as most users need.
That said, I'd really like to see an office suite put together out of the various opensource tools which try to approach documents/graphics in new and striking ways:
- LyX --- a "What You See Is What You Mean" document processor, it can offer quite professional capabilities (when I was doing STEM composition, the book which came in as LaTeX exported from LyX was the cleanest and most straight-forward manuscript I ever worked on)
- PySpread --- (or maybe Flexisheet if someone can get it to a usable state) Way more than most folks need, this Pythonic spreadsheet where every cell can be either a Python program or the output of a Python program could revolutionize what folks do w/ spreadsheets and data
- Jupyter Notebooks --- almost a de facto standard, getting wider adoption would be a good thing
- ipe --- https://ipe.otfried.org/ --- this, or TikzEdit or maybe xasy for Asymptote would be more drawing tool than most users would ever want, and able to make anything anyone really needs
I remember how promising AbiWord (https://en.wikipedia.org/wiki/AbiWord) and GNUmeric (http://www.gnumeric.org/) were 20 years ago when I first started using Linux and FreeBSD. Back in 2004, OpenOffice was slow on my hand-me-down PC running a 475MHz AMD K6-2 processor and with only 64MB RAM, but AbiWord ran well; it was a nice, lightweight word processor that was decently compatible with Microsoft Word for my needs as a high school student who needed to turn in essays and other reports. I've never tried GNUmeric, but I remember people singing its praises back in 2004.
I haven't heard anything about AbiWord and GNUmeric in recent years, though. I haven't kept up with them since my college days.
It is sad to see these projects disappear in obscurity. But what other outcome is even possible? It is incredibly expensive to build such complex software. these projects do not have an adequate amount of funding. There’s just no way random developers can devote years of their life to something like this and not earn a living. Even if they did, it would take at least 1000 of them for each of these products to rival commercial ones.
This is one of the reasons why I'm curious about Alan Kay's STEPS project, which attempted to build an entire desktop environment in just 20,000 lines of code via the use of bespoke domain-specific languages (https://tinlizzie.org/VPRIPapers/tr2012001_steps.pdf). Building feature-rich software applications using conventional technologies is very labor-intensive, but one of the things I'm curious about is whether the combination of DSLs to define subsystems and the promotion of component-based software (a la Apple's OpenDoc strategy from the mid-1990s before Steve Jobs' return; see https://www.youtube.com/watch?v=oFJdjk2rq4E for a very 1990s video) could reduce the cost of writing software that meets modern expectations regarding functionality.
> In this modern age of .md and similar files why not try for "blue water sailing" and instead create an office suite which specifically plays to only open standards?
Because your publisher, professor, employer, collaborators, and book club members all want an Office file. Full stop. They will not accept anything else, and they will refuse to work with you unless you have the clout to force them to use your new format. And then they will be unhappy.
That’s what this article is getting at. If you want to replace Office, you need to have full compatibility with Office files. There’s no way around it. Most people don’t want more open, faster, more features, or better. They want Office (or increasingly, Google Docs).
I used to work in publishing --- Word docs were hacked at (as noted elsethread often with track changes enabled) by editors since it was their standard tool, then they would get flowed into PageMaker, or Quark XPress, or Ventura Publisher, or Adobe InDesign --- except of course for the LaTeX docs.
For .docx, the converted file is fine, so long as it has all the text and bold/italics which the author wants.
Don't tell me a publisher is using the layout and font settings of my word document to have it printed. I can go as far that tracked changes, grammar and spelling are done while the doc is being written but once it gets serious into printing I still this a proper publishing software is used to fine tune kerning and all the other font stuff. So in saying that perfect layout by LO in MS formats is not the issue.
> A word processor which supports the same style options as Google Docs and used pandoc to import/export would be as much as most users need.
This kind of thinking in tech is why Office doesn't have any serious competitors. It's insufficient for what most business users need, and they're the reason the whole world runs on Office.
It's kind of crazy how half-assed and terrible the web app competitors to Office are.
It's been 30 years, and Office 95 was objectively better and more full featured than Google Docs in 2024. Even Microsoft Works would blow Google Docs out of the water in a feature-by-feature comparison.
To be fair, office 95 was an incredible release and it had a similar increase in sophistication that windows 95 did over earlier versions of windows. The Microsoft works of that era, which I think was version 4, was also a big step up. I assume that is because it must share some software components with the full office suite. the later versions of office have not really added much useful functionality. The ribbon was perhaps the big change since that era, but it was largely unnecessary.
But they should use it, stop wasting time formatting a word doc to have the letter address placed correctly or the custom property fields linked to in line text.
Because eventually you'll want to insert an image with text wrapped around it, or really anything more complicated than straight-down text and tables, and "just write HTML and CSS bro" is insanely unrealistic.
Sure, WYSWIYG editors for Markdown could exist, but building these editors gets crazy complicated fast, and why would you when Office exists?
There's RStudio with its WYSIWYG "visual"[1] editor for markdown(ahem, rMarkdown or quarto, which are pandoc's markdown + extensions). It is quite feature-rich albeit I am unsure whether it supports wrapping images. I bet you can write a little inline CSS in a fenced div[2][3] for it, but it is likely not an option for casual user.
What it does support is rendering all the goodies in plethora of output formats[4]: docx pdf, html for plain documents; revealjs(html), pptx, beamer(pdf) for presentations. You can even generate websites with it
As for spreadsheets, RStudio supports both R and python which are incredibly powerful for manipulating and visualizing table-like data
I won't argue that those are easy tools to learn, but if you do, you have much more power than with MS/{word,excel,powerpoint}
For that sort of thing, folks should import their Word (or other format) document into a tool such as Microsoft Publisher, or Scribus, or InDesign, or LaTeX.
Different apps render Markdown differently. The syntax may be standardized (though extended in different ways), but the layout will be wildly different if you open the same document in several different apps. This doesn’t resolve the author’s stated issue of not having a true wysiwyg document when shared with a third party.
.md is a terrible format for serious work. It only supports a few opinionated types of formatting. This is reasonable when you want to directly write one (the intended use of the format). For interchange you want at least RTF or XHTML.
Microsoft really doesn't want anyone to reliably copy their formats. Their standard is purposefully complicated and convoluted, it was almost rejected by ISO for this reason and it took heavy lobbying before it passed (I know of this personally as the ISO vote went through national ISO bodies).
I've worked with the Java implementation for writing Office files, the Apache POI. The internal package names for these classes are "hssf", "hwpf" and so on. It's not very obvious why until you Google it and, well, "hwpf" stands for "horrible word processor format", "hssf" is "horrible spreadsheet format" and so on. Implementing these things is often difficult for good reason, and sometimes for not so good reasons, but this is the first time I've encountered developers expressing such direct hostility towards what they were trying to implement.
One of the biggest blockers is the stubbornness of Apache Foundation that fails to admit that OpenOffice is effectively dead and simply redirect to the LibreOffice site, along with the announcement that OpenOffice is deprecated.
Them both being written in a memory unsafe language[1][2] isn't helping matters
Also, while digging up those links I noticed the last release of OO was in Dec 2023 which is a lot of time for all the components they bundle to acquire vulns. But at least they're consistent about it since the release before that was in Feb 2023
I agree a big blocker to LO adoption is LO, but not for the reasons mentioned here. It's true that for many purposes it's hard to get around MS Office simply because people specifically want it and will accept no alternatives.
But aside from that, LO is full of bugs and missing functionality. I use Impress regularly and I constantly encounter awkwardness and pain. There is no sure-fire way to set fonts for an entire document. Things are distributed across styles and master slides and those don't seem to cover all cases. Audio or video clips inserted into slides often don't play correctly, with various glitches or sound cutting out early.
I agree it would be nice to have better import/export with MS formats, but I'd settle for a LibreOffice that provided a bug-free core of functionality, even if that was somewhat smaller than the big proprietary tools.
The big point that the article is trying to make is bookended by these quotes: "... there's a standard, things ought to be simple. So you could, theoretically and perhaps even practically, use non-Microsoft software to get the job done!". "... it[LibreOffice] stubbornly refused to that, for ideological reasons."
This feels at odds with my experience of the LibreOffice community and maintainers in general, and also appears to misunderstand the detail of the OOXML standard. I think the blockers to full pixel-level replication of Office documents have more to do with the sheer complexity of the formats involved and the obscure way some of the features are described, which AFAIK often involves just saying "do this the way Word does it" instead of describing the behaviour in a completely implementation agnostic way. As a Mac user, I am very familiar with the minor differences in rendering between Mac and Windows version of Office 365. Most people will know there are differences in rendering between the web versions and the desktop versions, too. And these implementations were written by the same organisation with people who presumably had access not only to the specification but also the actual source code and libraries that were used for the "primary" Windows implementation.
For me to agree with this article's premise, I'd need to see an example of even one implementation of OOXML support that meets the author's standards.
I'm very sympathetic to the article although I dont know that it's correct in every technical respect. One would hope that LO on a standard, popular distro like Ubuntu or Mint should just work, and look polished and professional, but it doesn't, at all: the fonts are janky, the UI has weird artifacts, etc. I suppose this is what you get when the renderer and the font engine and the OS and the app arent all from the same place.
Then when you layer on the problems with Office file compatibility, it becomes unwise to use it. As for the n=1 anecdotes that LO is fine for them, great, but years in corporate has left me with great awe and respect for the myriad ways people use Word. It really is insanely powerful. I think only LaTeX beats it. As for Excel, nothing comes remotely close.
I dont mind being the only LO/Linux user in the office. I do mind, very much, that I might risk my job because LO decided to chew up a colleague's Office format file when I opened it. You never want to be that kind of outlier.
I will say that it's maybe not entirely LO's fault. I have a Macbook and a PC, and 365 on Mac is also strangely janky and ugly, whereas 365 on Windows is a joy. (Mac 365 has very odd layout and rendering standards, which are glaring for apps like Outlook, for example.)
Yep, even skipping that world is monopolised by World/Excel, LibreOffice is self-blocking it's own adoption.
I just use it to print long long ago prepared documents so I mainly use "print dialog". And in last ~2 years they degraded that dialog usage at least two times:
- by moving count of pages to print below dialog window so you need to scroll it
- by forcing user to click on document to focus before ^P shortcut starts to work
And how many other things stopped to working in user-friendly way in last years ? Maybe none, maybe it's a lot.
So, to me, LO is sabotaging this software package. LO is fundation just like Mozilla and I suspect they work same agenda: keep collecting money and keep product second or 3rd class. IMO.
MS is happy. Google is happy. LO.Mozilla fund employee are happy. Spy agencies are happy.
LO follows a grand Linux tradition of jack-of-all-trades-master-of-none tools. GNUCash, Nouveaux, its all the same. An application that sucks the air out of the room so it becomes a defacto Linux standard, and that "works" only in some minimal way such that proprietary tools remain indispensable. One could be forgiven for inferring they exist in this way because proprietary software providers prefer things this way.
I like LibreOffice and have used it exclusively for personal projects for more than a decade. But it's definitely useless for professional - grade work, and getting further off the pace with the advent of M365.
My 2¢:
I agree formats (in)compatibility is by far the major showstopper in adopting LO. MS Office formats indeed rule, like it or not
• Starting with v7.4, back in August 2022, LO is giving formats compatibility the attention they deserve (https://blog.documentfoundation.org/blog/2022/08/18/libreoff...)
Maybe it's too little, too late, and it doesn't look aligned with the state of 'Microsoft Office compatibility' wiki page (https://wiki.documentfoundation.org/Faq/General/012#Microsof...
• I am no expert, but how formats with ISO are so hard to implement is beyond me
I consider OO and its other remaining forks a waste of effort. Aligning their combined forces with LO, however, could make a huge difference in the formats compatibility effort. Then again, this is the plague (and beauty) of open source projects…
I read posts like this and thank Buddha that I, for the last couple of decades of my working life, didn't work in an environment that necessitated using MS products.
If people want to use it then they can use it. If they don't want to then leave them alone. This is what's great about FLOSS. You use what you want to.
I’m not sure what this guys point is. He first says that he can’t stand on ideology, he Needs to Het Things Done. Then he says LO needs to implement OOXML fully.
Which is cute, because not even Microsoft implement OOXML fully.
LO is an incremental development model. Every point release increases compatibility. Case in point: EMF+ files had massive gaps. A guy called Bartovs has now implemented a huge chunk of functionality now.
Now we have implemented Smart Art. Floating tables. You name it, it gets improved every point release.
But what I don’t see is him writing quality bug reports. Fit to start somewhere.
The biggest blocker to LibreOffice adoption is that the general purpose office suite is dying a slow death.
When you think about it, unless you’re working at a very small business or on home stuff, most things you do with it should live elsewhere.
If you’re writing up some documentation for a business process, that should live in a system designed for that purpose where documents can be linked together and integrate with other systems. Examples include Confluence or Notion.
If you’re using Calc/Excel to handle some accounting or some other kind of quantitative organization, there’s probably a specialized system that you should be using, or just using a CRUD application.
If you’re doing HR stuff like performance reviews you need a system that can enforce tight read permissions and enforce a workflow.
The list goes on and on. The general business office suite only exists to catch general purpose processes that fall through the cracks where a better solution doesn’t exist, and every day that goes by eliminates another one of those use cases.
The second biggest blocker is that LibreOffice isn’t in your browser. It’s a slow-installing slow-loading clunky old desktop application.
The third biggest blocker to LibreOffice adoption is the dogshit ancient-looking UI. It looks nothing like a native application on any platform which constantly reminds you you’re using the knockoff of the Real McCoy.
I don’t think that LibreOffice not being in the browser is necessarily a blocker in itself. For something like an advanced office suite, where you don’t want to have browser toolbars/tabs/etc eating up valuable screen space that could be going to app palettes and such instead, not being chained to a browser is a boon.
Besides that, when software serves a purpose well, people do not hesitate to download and install it. If need to install an app causes significant user dropoff, I’d say that’s an indictment of the app’s functionality/UX/etc. It basically means that the value the app provides isn’t worth an extremely minor one-time inconvenience, which is a pretty low bar to clear.
By installing the corresponding mobile apps. If access without a dedicated app is important, export a PDF.
I really don’t like treating web access as a requirement if only because it adds enormous complexity to an already-complex project and brings much higher recurring expenses to keep the hosted service online. Neither are conducive to a free product that’s so highly reliant on volunteered time and donations.
Web apps work best as closed, paid SaaSes funded by VCs, where complexity and overhead can be papered over by money.
> If you’re using Calc/Excel to handle some accounting or some other kind of quantitative organization, there’s probably a specialized system that you should be using, or just using a CRUD application.
This greatly underestimates the importance of Excel for anything to do with physical goods, which is all of the world outside of the tiny SV/HN SaaS bubble. Excel files are the API that glues every factory, supplier, vendor and system together. Good luck replacing that and forcing all of the involved parties to switch to this replacement.
Yep. I’m currently working for a client who build software for the insurance industry, and we have a whole pipeline to parse and generate Excel files. The industry mostly runs on Excel and email. Without support for parsing those spreadsheets, my client would never have been able to convince their customers to use the rest of their software.
Personally I see NO CASE for WYSIWYG suite, so well... For the the case is why wasting time and energy to learn and use such software instead of invest time, in time, at school, to learn LaTeX, R/Python etc and then profit for life.
Commercial IT evolution is really damaging the society but well, those who want to know if something else exists could find answers easily enough...
I don’t really care about it being compatible with Microsoft’s convoluted formats. Maybe it needs to be able to export into those formats, but I also think the world is ready to move on from Office. Most of its features are unnecessary in practice.
I don't use the desktop Office stuff at work and the cloud stuff only begrudgingly.
But you and I are effectively rare cases. The vast majority of the business world isn't going to drop Office products, just like they aren't going to drop Windows.
If your publisher requires word documents (or _any_ word processor format), you need to find a better publisher. I can understand if they prefer word for the text-copy, which is then pulled into a typesetting app. But to use that as the pre-press format is a terrible workflow. This isn't a limitation of LibreOffice, it's a limitation of not being competent in pre-press typesetting and publishing software.
There are really two, almost entirely separate, points there - one is about missing interpretability of LibreOffice, and the other is about the author's inability to install Microsoft Office on Linux.
I'd like to articulate a case why supporting the the author's use cases is likely uneconomical.
With respect to the LibreOffice interoperability with Microsoft Office: the author works in publishing, which requires almost pixel-perfect equivalence between how a document is displayed between them and their collaborators. Faithfully reproducing almost 40 years of evolution in the layout engine (some of which co-evolution with the Windows OS and the font system) necessitates a development program of mind-boggling proportions. It is absolutely no surprise to me that no entity, either commercial or open source can finance such an endeavor. (Even Microsoft does not exhibit 100% interop between the native Office and the cloud Office 365)
A similar argument applies to being able to install Office on Linux, with the added nuance that the major driving force behind Wine etc are game distributors, whereas Office compatibility is not a major priority, especially given the VM and Office 365 alternatives.
I agree with your point about interop on the level of file formats. We are talking decades of undocumented cruft at this point in the Office file formats - the MS implementations are so complex in a random and haphazard way that it's questionable whether they could ever be fully reverse engineered.
Running Office on Linux, on the other hand: I think the issue here is simply a lack of vision. Getting to where we are with Proton and Linux gaming today required Gabe Newell as an exceptionally gutsy and ambitious lunatic billionaire to just say, ok, we could spend what it takes and go the last mile here, and it happened. I'm quite certain that a similarly dedicated effort (actually a much smaller one) could get Office running perfectly on Linux, and that would be a huge win for anyone who was ambitious enough to try and claw the lucrative enterprise desktop market away from Microsoft. There's just no one out there yet who's been wealthy and crazy enough to go for this one.
The average person thinks all kinds of stuff is impossible when it's not, another great example is how everyone thought Gabe Weinberg had no chance of competing with Google, fast forward to today and DuckDuckGo makes $100M/yr and is probably going to benefit immensely when the govt's anti-trust remedies against Google kick in, no matter what they end up being. The world is Gabe's oyster and he's just a guy who had balls bigger than everyone else's, found a good angle and stuck with it.
> I'd like to articulate a case why supporting the the author's use cases is likely uneconomical
Does that apply to desktop linux too?
> I'd like to articulate a case why supporting the the author's use cases is likely uneconomical.
You describe the use case as publishing, but really it’s interacting with others in a professional capacity. It’s much broader than just publishing.
> With a free price tag, it could easily do that. But, it first needs to provide the required functionality, and today, it stubbornly refused to that, for ideological reasons.
Very confused by the article, even after re-reading it. The author keeps bringing up ideology throughout the article, but is there any arguments or evidence given that this is a factor? The simplest explanation to me is that OOXML is a de-facto proprietary format, and implementing full compatibility with it is simply a large technical undertaking that LibreOffice doesn't have the resources to effectively achieve right now. They even hint at that themselves: "From what I've been able to decipher, no non-Microsoft Office program implements the full specification and follows it to the letter."
I agree with you. I disagree with the assertion from the author that LibreOffice refuses to implement the OOXML standard for ideological reasons; nothing was cited in the article supporting this assertion. If it were true that LibreOffice's developers only want to support open standards, then there wouldn't have been support for the pre-Office 2007 binary formats.
Yes, I believe that imperfect compatibility with Microsoft Office is holding LibreOffice back, but perfect compatibility isn't going to happen without massive resources. It's immense work being 100% compatible with a proprietary, under-documented standard. Without an army of developers, it's going to take a very long time. Think of how long it took Wine and ReactOS to get to today's usability, and those projects still have much work to do. Think of how long it took the HaikuOS people to release release-candidate issues of their project.
It’s absolutely not true that LO devs only want to support open standards. They are still supporting .doc compatibility!
It’s difficult to be conpatible with a software product that claims to follow an open standard but that does not.
The article's reasoning is ridiculous. I'm quite sure if it were easy to implement OOXML, LibreOffice would have done it.
The first part of OOXML alone has more than 5,000 pages. Ideology or not, I highly doubt anyone would try to implement OOXML to the letter.
> I'm quite sure if it were easy to implement [feature A], LibreOffice would have done it
I've lost this optimism a long time ago when I realized how much denialism and how little actual factual, detailed knowledge there is among vocal proponents for Linux and free software. For example, the entire font handling stack on Linux is a hot seething mess of horrible dysfunctionality, wrongly implemented and starting out from the wrong principles (IMHO), yet nobody is working to improve it because everyone keeps telling you it's a solved problem.
More specifically, years ago ago I hacked together solutions to script LibreOffice from the 'outside' as it were because its macro system is such an utter painful failure in so many ways. Not only was a single website written in Japanese the only source for a reasonable rundown of LibreOffice's API, it also introduced me, indirectly, to the fact that the people who initially wrote OpenOffice were apparently not comfortable with Java being a strictly OOP language, so they did their best to write code that to a degree circumvents that, leading to a terrifyingly bad user experience and a hint of the convoluted horrors that might lurk in the source code.
The glacial pace of LibreOffice's development where the appearance of the tiniest of innovations leads, every few years, to great public announcements and a new version number, has convinced me that the community has painted themselves in a corner with an unmanageable code base and devs that are, likely, in complete denial that the only way out would be a complete rewrite of the software, something that is, understandably, too hard to stomach.
I challenge you on each of these points:
You make a big claim that font handling is a “hot seething mess”, but you do t explain why. Harfbuzz and ICU are hardly what you describe.
LibreOffice’s API is extensively documented:
* https://api.libreoffice.org/
* the Developers Guide has been around for literally over a decade and is now located at https://wiki.documentfoundation.org/Documentation/DevGuide
LibreOffice is not based on Java. Java was, IMO, bolted on when Sun took over. As for it circumventing the “strict OO” nature of Java, that makes no sense and I challenge you to back this up with a technical explanation.
LibreOffice does incremental development. It’s not in any way glacial. Every release has hundreds of feature updates and bug fixes. The quality and compatibility with Office is getting better over time, and though there is still a ways to go it’s hardly going slowly.
I’ve extensively looked at the LibreOffice source code, and I can tell you that a complete rewrite would be a major waste of time that would kill the project. The software has been around since the early 1980s. It has accreted layers, but even so those layers are pretty well defined. It’s why it can be ported to different architectures and desktop environments. It’s why it has so many language bindings.
I don’t think you have a very informed view of how LibreOffice is developed, or even how it works.
Lots of things that just don't smell right here. First of all, every experience I've had trying to get GDocs to play ball with DOCX has led to the same misery that comes with LibreOffice. It works fine until you use an unsupported font, or tables, or precise image layouts, etc etc etc.
DOCX is a proprietary format. Perfect support is categorically impossible. A best-effort attempt is the best we'll ever get, and IME LibreOffice tries a lot harder than other office suites do.
Also, for what it's worth... you know what GDocs and Word won't open? A document written in WordStar on a TRS-80 in 1983. You know what will open that document? LibreOffice. LibreOffice checks all the boxes for my spreadsheet/document writing needs, and it has also been an irreplacable tool in my data archival efforts.
> DOCX is a proprietary format. Perfect support is categorically impossible. A best-effort attempt is the best we'll ever get, and IME LibreOffice tries a lot harder than other office suites do.
Nah - well you’re correct that DOCX is under-defined - but the real the problem with LibreOffice is that it has 40 years of history supporting the wrong file format. Its internals are all built on models that later became ODF and any attempt to bolt-on the incompatible MS Office models is doomed to failure.
I only rarely encounter people who use Google Docs, but when I do it’s a huge pain if you care about preserving the formatting at all.
Both startups I've worked for used it exclusively - one of them being a med-tech with a boatload of documentation needs. A lot of schools have dropped MS Office as they've switched to Chromebooks.
None of this is to say GDocs isn't a miserable turd of a program. I'm convinced word processors have actually regressed in quality since the mid-2000s. GDocs somehow manages to be less featureful, slower, buggier, less user-friendly, and less compatible than Word XP. There isn't a single thing GDocs does better than an office suite that's pushing 25 years old, save for real-time collaborative editing which is hardly worth all the other compromises.
This sounds silly, but I encourage you to dredge up an old Windows XP system and a copy of Office XP. I was shocked to see how far we've strayed from the light.
In this modern age of .md and similar files why not try for "blue water sailing" and instead create an office suite which specifically plays to only open standards?
A word processor which supports the same style options as Google Docs and used pandoc to import/export would be as much as most users need.
That said, I'd really like to see an office suite put together out of the various opensource tools which try to approach documents/graphics in new and striking ways:
- LyX --- a "What You See Is What You Mean" document processor, it can offer quite professional capabilities (when I was doing STEM composition, the book which came in as LaTeX exported from LyX was the cleanest and most straight-forward manuscript I ever worked on)
- PySpread --- (or maybe Flexisheet if someone can get it to a usable state) Way more than most folks need, this Pythonic spreadsheet where every cell can be either a Python program or the output of a Python program could revolutionize what folks do w/ spreadsheets and data
- Jupyter Notebooks --- almost a de facto standard, getting wider adoption would be a good thing
- ipe --- https://ipe.otfried.org/ --- this, or TikzEdit or maybe xasy for Asymptote would be more drawing tool than most users would ever want, and able to make anything anyone really needs
I remember how promising AbiWord (https://en.wikipedia.org/wiki/AbiWord) and GNUmeric (http://www.gnumeric.org/) were 20 years ago when I first started using Linux and FreeBSD. Back in 2004, OpenOffice was slow on my hand-me-down PC running a 475MHz AMD K6-2 processor and with only 64MB RAM, but AbiWord ran well; it was a nice, lightweight word processor that was decently compatible with Microsoft Word for my needs as a high school student who needed to turn in essays and other reports. I've never tried GNUmeric, but I remember people singing its praises back in 2004.
I haven't heard anything about AbiWord and GNUmeric in recent years, though. I haven't kept up with them since my college days.
It is sad to see these projects disappear in obscurity. But what other outcome is even possible? It is incredibly expensive to build such complex software. these projects do not have an adequate amount of funding. There’s just no way random developers can devote years of their life to something like this and not earn a living. Even if they did, it would take at least 1000 of them for each of these products to rival commercial ones.
This is one of the reasons why I'm curious about Alan Kay's STEPS project, which attempted to build an entire desktop environment in just 20,000 lines of code via the use of bespoke domain-specific languages (https://tinlizzie.org/VPRIPapers/tr2012001_steps.pdf). Building feature-rich software applications using conventional technologies is very labor-intensive, but one of the things I'm curious about is whether the combination of DSLs to define subsystems and the promotion of component-based software (a la Apple's OpenDoc strategy from the mid-1990s before Steve Jobs' return; see https://www.youtube.com/watch?v=oFJdjk2rq4E for a very 1990s video) could reduce the cost of writing software that meets modern expectations regarding functionality.
> In this modern age of .md and similar files why not try for "blue water sailing" and instead create an office suite which specifically plays to only open standards?
Because your publisher, professor, employer, collaborators, and book club members all want an Office file. Full stop. They will not accept anything else, and they will refuse to work with you unless you have the clout to force them to use your new format. And then they will be unhappy.
That’s what this article is getting at. If you want to replace Office, you need to have full compatibility with Office files. There’s no way around it. Most people don’t want more open, faster, more features, or better. They want Office (or increasingly, Google Docs).
Send your publisher a .docx file made by converting a .md using Pandoc:
https://pandoc.org/
I used to work in publishing --- Word docs were hacked at (as noted elsethread often with track changes enabled) by editors since it was their standard tool, then they would get flowed into PageMaker, or Quark XPress, or Ventura Publisher, or Adobe InDesign --- except of course for the LaTeX docs.
For .docx, the converted file is fine, so long as it has all the text and bold/italics which the author wants.
Don't tell me a publisher is using the layout and font settings of my word document to have it printed. I can go as far that tracked changes, grammar and spelling are done while the doc is being written but once it gets serious into printing I still this a proper publishing software is used to fine tune kerning and all the other font stuff. So in saying that perfect layout by LO in MS formats is not the issue.
> A word processor which supports the same style options as Google Docs and used pandoc to import/export would be as much as most users need.
This kind of thinking in tech is why Office doesn't have any serious competitors. It's insufficient for what most business users need, and they're the reason the whole world runs on Office.
It's kind of crazy how half-assed and terrible the web app competitors to Office are.
It's been 30 years, and Office 95 was objectively better and more full featured than Google Docs in 2024. Even Microsoft Works would blow Google Docs out of the water in a feature-by-feature comparison.
To be fair, office 95 was an incredible release and it had a similar increase in sophistication that windows 95 did over earlier versions of windows. The Microsoft works of that era, which I think was version 4, was also a big step up. I assume that is because it must share some software components with the full office suite. the later versions of office have not really added much useful functionality. The ribbon was perhaps the big change since that era, but it was largely unnecessary.
Business users don't want .md files
But they should use it, stop wasting time formatting a word doc to have the letter address placed correctly or the custom property fields linked to in line text.
I agree office documents aren't the ideal format for business users' workflows. However, I disagree markdown is the solution.
Does MD format do footnotes, along with page headers and footers? Floating images?
Cool now how do I get a table in my markdown file? And a chart? Also some diagrams.
Which is why one can use Pandoc to convert a .md to a .docx
Because eventually you'll want to insert an image with text wrapped around it, or really anything more complicated than straight-down text and tables, and "just write HTML and CSS bro" is insanely unrealistic.
Sure, WYSWIYG editors for Markdown could exist, but building these editors gets crazy complicated fast, and why would you when Office exists?
There's RStudio with its WYSIWYG "visual"[1] editor for markdown(ahem, rMarkdown or quarto, which are pandoc's markdown + extensions). It is quite feature-rich albeit I am unsure whether it supports wrapping images. I bet you can write a little inline CSS in a fenced div[2][3] for it, but it is likely not an option for casual user. What it does support is rendering all the goodies in plethora of output formats[4]: docx pdf, html for plain documents; revealjs(html), pptx, beamer(pdf) for presentations. You can even generate websites with it As for spreadsheets, RStudio supports both R and python which are incredibly powerful for manipulating and visualizing table-like data
I won't argue that those are easy tools to learn, but if you do, you have much more power than with MS/{word,excel,powerpoint}
[1]: https://rstudio.github.io/visual-markdown-editing/
[2]: https://pandoc.org/MANUAL.html#extension-fenced_divs
[3]: https://stackoverflow.com/questions/76421783/text-and-image-...
[4]: https://quarto.org/docs/guide/
For that sort of thing, folks should import their Word (or other format) document into a tool such as Microsoft Publisher, or Scribus, or InDesign, or LaTeX.
Different apps render Markdown differently. The syntax may be standardized (though extended in different ways), but the layout will be wildly different if you open the same document in several different apps. This doesn’t resolve the author’s stated issue of not having a true wysiwyg document when shared with a third party.
But not one of the things you mention is an “open standard”.
.md is a terrible format for serious work. It only supports a few opinionated types of formatting. This is reasonable when you want to directly write one (the intended use of the format). For interchange you want at least RTF or XHTML.
Microsoft really doesn't want anyone to reliably copy their formats. Their standard is purposefully complicated and convoluted, it was almost rejected by ISO for this reason and it took heavy lobbying before it passed (I know of this personally as the ISO vote went through national ISO bodies).
I've worked with the Java implementation for writing Office files, the Apache POI. The internal package names for these classes are "hssf", "hwpf" and so on. It's not very obvious why until you Google it and, well, "hwpf" stands for "horrible word processor format", "hssf" is "horrible spreadsheet format" and so on. Implementing these things is often difficult for good reason, and sometimes for not so good reasons, but this is the first time I've encountered developers expressing such direct hostility towards what they were trying to implement.
One of the biggest blockers is the stubbornness of Apache Foundation that fails to admit that OpenOffice is effectively dead and simply redirect to the LibreOffice site, along with the announcement that OpenOffice is deprecated.
Please, it's not like LibreOffice was significantly better or more popular
It comes from the same code base, which limits a lot what can be done with it.
Better isn't just one dimension but I've repeatedly heard that OO is a damn dumpster fire for loading untrusted content: https://www.openoffice.org/security/bulletin.html vs https://www.libreoffice.org/about-us/security/advisories/
Them both being written in a memory unsafe language[1][2] isn't helping matters
Also, while digging up those links I noticed the last release of OO was in Dec 2023 which is a lot of time for all the components they bundle to acquire vulns. But at least they're consistent about it since the release before that was in Feb 2023
1: https://github.com/apache/openoffice/tree/AOO4115-GA/main/ba...
2: https://cgit.freedesktop.org/libreoffice/core/tree/basic/sou...
Yes, you are correct
Also OO was (in)famous for vendoring almost all dependencies (optionally - to make matters even worse), not sure how that works with LO
It has significantly diverged now.
> Dedoimedo writes his book in LibreOffice, but then must use Microsoft Office for when he wants to talk to the publishers.
Are these publishers using antiquated versions of MS Office from before it added ODF support?
Publishers use .docx and often rely on track changes and comments working _exactly_ like in Word.
I agree a big blocker to LO adoption is LO, but not for the reasons mentioned here. It's true that for many purposes it's hard to get around MS Office simply because people specifically want it and will accept no alternatives.
But aside from that, LO is full of bugs and missing functionality. I use Impress regularly and I constantly encounter awkwardness and pain. There is no sure-fire way to set fonts for an entire document. Things are distributed across styles and master slides and those don't seem to cover all cases. Audio or video clips inserted into slides often don't play correctly, with various glitches or sound cutting out early.
I agree it would be nice to have better import/export with MS formats, but I'd settle for a LibreOffice that provided a bug-free core of functionality, even if that was somewhat smaller than the big proprietary tools.
The big point that the article is trying to make is bookended by these quotes: "... there's a standard, things ought to be simple. So you could, theoretically and perhaps even practically, use non-Microsoft software to get the job done!". "... it[LibreOffice] stubbornly refused to that, for ideological reasons."
This feels at odds with my experience of the LibreOffice community and maintainers in general, and also appears to misunderstand the detail of the OOXML standard. I think the blockers to full pixel-level replication of Office documents have more to do with the sheer complexity of the formats involved and the obscure way some of the features are described, which AFAIK often involves just saying "do this the way Word does it" instead of describing the behaviour in a completely implementation agnostic way. As a Mac user, I am very familiar with the minor differences in rendering between Mac and Windows version of Office 365. Most people will know there are differences in rendering between the web versions and the desktop versions, too. And these implementations were written by the same organisation with people who presumably had access not only to the specification but also the actual source code and libraries that were used for the "primary" Windows implementation.
For me to agree with this article's premise, I'd need to see an example of even one implementation of OOXML support that meets the author's standards.
I'm very sympathetic to the article although I dont know that it's correct in every technical respect. One would hope that LO on a standard, popular distro like Ubuntu or Mint should just work, and look polished and professional, but it doesn't, at all: the fonts are janky, the UI has weird artifacts, etc. I suppose this is what you get when the renderer and the font engine and the OS and the app arent all from the same place.
Then when you layer on the problems with Office file compatibility, it becomes unwise to use it. As for the n=1 anecdotes that LO is fine for them, great, but years in corporate has left me with great awe and respect for the myriad ways people use Word. It really is insanely powerful. I think only LaTeX beats it. As for Excel, nothing comes remotely close.
I dont mind being the only LO/Linux user in the office. I do mind, very much, that I might risk my job because LO decided to chew up a colleague's Office format file when I opened it. You never want to be that kind of outlier.
I will say that it's maybe not entirely LO's fault. I have a Macbook and a PC, and 365 on Mac is also strangely janky and ugly, whereas 365 on Windows is a joy. (Mac 365 has very odd layout and rendering standards, which are glaring for apps like Outlook, for example.)
Yep, even skipping that world is monopolised by World/Excel, LibreOffice is self-blocking it's own adoption.
I just use it to print long long ago prepared documents so I mainly use "print dialog". And in last ~2 years they degraded that dialog usage at least two times:
- by moving count of pages to print below dialog window so you need to scroll it
- by forcing user to click on document to focus before ^P shortcut starts to work
And how many other things stopped to working in user-friendly way in last years ? Maybe none, maybe it's a lot.
So, to me, LO is sabotaging this software package. LO is fundation just like Mozilla and I suspect they work same agenda: keep collecting money and keep product second or 3rd class. IMO.
MS is happy. Google is happy. LO.Mozilla fund employee are happy. Spy agencies are happy.
Fake no-monopolies can do NOT improve a much.
LO follows a grand Linux tradition of jack-of-all-trades-master-of-none tools. GNUCash, Nouveaux, its all the same. An application that sucks the air out of the room so it becomes a defacto Linux standard, and that "works" only in some minimal way such that proprietary tools remain indispensable. One could be forgiven for inferring they exist in this way because proprietary software providers prefer things this way.
I like LibreOffice and have used it exclusively for personal projects for more than a decade. But it's definitely useless for professional - grade work, and getting further off the pace with the advent of M365.
My 2¢: I agree formats (in)compatibility is by far the major showstopper in adopting LO. MS Office formats indeed rule, like it or not • Starting with v7.4, back in August 2022, LO is giving formats compatibility the attention they deserve (https://blog.documentfoundation.org/blog/2022/08/18/libreoff...) Maybe it's too little, too late, and it doesn't look aligned with the state of 'Microsoft Office compatibility' wiki page (https://wiki.documentfoundation.org/Faq/General/012#Microsof... • I am no expert, but how formats with ISO are so hard to implement is beyond me I consider OO and its other remaining forks a waste of effort. Aligning their combined forces with LO, however, could make a huge difference in the formats compatibility effort. Then again, this is the plague (and beauty) of open source projects…
What's everyone's opinion on OnlyOffice? It seems to have a much more polished UI than LibreOffice.
https://github.com/ONLYOFFICE/DesktopEditors
I have first encountered it as the default office suite in Manjaro.
It can correctly open my company's Power Point templates and IMO the UI is much better in both aesthetics and discoverability compared to LibreOffice.
I read posts like this and thank Buddha that I, for the last couple of decades of my working life, didn't work in an environment that necessitated using MS products.
If people want to use it then they can use it. If they don't want to then leave them alone. This is what's great about FLOSS. You use what you want to.
I dont know.
I am a "heavy" calc and writer user. I use them daily in my office job.
I dont need much macros (the ones I created for excel do with for calc) so it works.
I do get formatting issues with files every often but with next release, its usually fixed.
I have been using of before it was libreoffice so I know.
Yes, it does crash sometimes but that is getting less and less obvious now.
I encourage you to give it a spin. Its not half as bad as it sounds
(2023)
I’m not sure what this guys point is. He first says that he can’t stand on ideology, he Needs to Het Things Done. Then he says LO needs to implement OOXML fully.
Which is cute, because not even Microsoft implement OOXML fully.
LO is an incremental development model. Every point release increases compatibility. Case in point: EMF+ files had massive gaps. A guy called Bartovs has now implemented a huge chunk of functionality now.
Now we have implemented Smart Art. Floating tables. You name it, it gets improved every point release.
But what I don’t see is him writing quality bug reports. Fit to start somewhere.
The biggest blocker to LibreOffice adoption is that the general purpose office suite is dying a slow death.
When you think about it, unless you’re working at a very small business or on home stuff, most things you do with it should live elsewhere.
If you’re writing up some documentation for a business process, that should live in a system designed for that purpose where documents can be linked together and integrate with other systems. Examples include Confluence or Notion.
If you’re using Calc/Excel to handle some accounting or some other kind of quantitative organization, there’s probably a specialized system that you should be using, or just using a CRUD application.
If you’re doing HR stuff like performance reviews you need a system that can enforce tight read permissions and enforce a workflow.
The list goes on and on. The general business office suite only exists to catch general purpose processes that fall through the cracks where a better solution doesn’t exist, and every day that goes by eliminates another one of those use cases.
The second biggest blocker is that LibreOffice isn’t in your browser. It’s a slow-installing slow-loading clunky old desktop application.
The third biggest blocker to LibreOffice adoption is the dogshit ancient-looking UI. It looks nothing like a native application on any platform which constantly reminds you you’re using the knockoff of the Real McCoy.
And the final hurdle is that it has a dorky name.
I don’t think that LibreOffice not being in the browser is necessarily a blocker in itself. For something like an advanced office suite, where you don’t want to have browser toolbars/tabs/etc eating up valuable screen space that could be going to app palettes and such instead, not being chained to a browser is a boon.
Besides that, when software serves a purpose well, people do not hesitate to download and install it. If need to install an app causes significant user dropoff, I’d say that’s an indictment of the app’s functionality/UX/etc. It basically means that the value the app provides isn’t worth an extremely minor one-time inconvenience, which is a pretty low bar to clear.
Collabora actually have made massive strides in getting LibreOffice onto the web.
Huge problem. How do I view a document on my phone with LibreOffice? How do I show my document to a client with an unknown different environment?
The web is universal.
I’m pretty sure half of all Internet traffic is on phones.
Just look at the kind of business Google Workspaces and Office 365 are doing.
Heck, LibreOffice has an OSS competitor on the web with OnlyOffice.
By installing the corresponding mobile apps. If access without a dedicated app is important, export a PDF.
I really don’t like treating web access as a requirement if only because it adds enormous complexity to an already-complex project and brings much higher recurring expenses to keep the hosted service online. Neither are conducive to a free product that’s so highly reliant on volunteered time and donations.
Web apps work best as closed, paid SaaSes funded by VCs, where complexity and overhead can be papered over by money.
> If you’re using Calc/Excel to handle some accounting or some other kind of quantitative organization, there’s probably a specialized system that you should be using, or just using a CRUD application.
This greatly underestimates the importance of Excel for anything to do with physical goods, which is all of the world outside of the tiny SV/HN SaaS bubble. Excel files are the API that glues every factory, supplier, vendor and system together. Good luck replacing that and forcing all of the involved parties to switch to this replacement.
Yep. I’m currently working for a client who build software for the insurance industry, and we have a whole pipeline to parse and generate Excel files. The industry mostly runs on Excel and email. Without support for parsing those spreadsheets, my client would never have been able to convince their customers to use the rest of their software.
It’s important today. Is Excel usage increasing or decreasing over time? That’s important.
If it even loses 5% usage per year that’s huge over time.
Important today. Is usage of Excel increasing over time? Or decreasing?
Personally I see NO CASE for WYSIWYG suite, so well... For the the case is why wasting time and energy to learn and use such software instead of invest time, in time, at school, to learn LaTeX, R/Python etc and then profit for life.
Commercial IT evolution is really damaging the society but well, those who want to know if something else exists could find answers easily enough...
Personally I am looking forward to an end to end encrypted office suite from Proton: https://proton.me/blog/docs-proton-drive
I don’t really care about it being compatible with Microsoft’s convoluted formats. Maybe it needs to be able to export into those formats, but I also think the world is ready to move on from Office. Most of its features are unnecessary in practice.
I don't use the desktop Office stuff at work and the cloud stuff only begrudgingly.
But you and I are effectively rare cases. The vast majority of the business world isn't going to drop Office products, just like they aren't going to drop Windows.
Macintosh apps have great compatibility as do Google.