As in compatibility with MS Office breaks or as in it can't be done in libreoffice?
For example, if I understand it correctly libreoffice supports javascript, python, beanshell and libreoffice basic for scripting and additionally offers non-complete support for VBA.
Does MS Office "break" when you try to import "complex macros/calculations" done in python?
Out of interest, is there any non-MS office suite with better VBA compatibility than libreoffice? For instance in view to the whole Adobe Venezuela story.
Excel macros are code, and they are very often production-critical code. The people who wrote them don't see themselves as coders, sure, and management often doesn't give the code the respect it deserves (e.g. Excel is often exempt from basic things like version control and code reviews), but it's still code that the business still depends on.
When someone proposes replacing MS Office with LibreOffice, what they're really proposing is to replace the runtime that a significant amount of production code runs on with something that's only compatible with part of your codebase.
"If we switch, we are going to have to rewrite a decent chunk of our production-critical code" is a non-starter, especially when coupled with the fact that the developers have no experience with the new runtime and are going to have to learn it as they port the code. And because they don't see themselves as coders, they don't have the theoretical background that makes it easier for experienced software engineers to pick up new languages.
If they don't work in libre then that's an automatic no-go for most managers/whoever makes that decision.
https://excel.uservoice.com/forums/304921-excel-for-windows-...
It breaks down because you need some serious backup in your organization (for example from the owner) to switch to something like LibreOffice. People got enough on their plate and changing their tools for (from their perspective) no apparent reason will get a lot of push back. I think technically LibreOffice is perfectly up to the task. Sure if your a statistician then maybe Spreadsheet won't work as well for you as an Excel replacement. But other then that...
That said, while they do use some complex formulas, they don’t use any VBScript or other such madness.
Complaining that your custom MSFT/VBScript stuff doesn’t work, so you can’t migrate — it sounds to me a bit like “We’re stuck on Oracle and can’t move to PostgreSQL because we decided to use a lot of Oracle magic stuff that doesn’t work anywhere else”.
This is classic vendor lock-in, which I tend to view as a business risk best avoided. There really is no option except to recognize it as technical debt and find time to dig yourself out from it.
When your only option for “Business Function X” limits you to a single vendor, fix that first.
Good business is about managing and understanding risks, and not about eliminating them at all costs.
But when the only thing holding you back and locking you in is your own company's internal vendor-specific tooling/infrastructure, the argument doesn't hold as much weight.
fwiw, I have never received an Excel spreadsheet from a vendor/partner/customer that I could not open and work with in LibreOffice, re-export to Excel and send back to them.
And since Excel is the de facto standard, shouldn't Libre Office offer a 100% compatibility to whatever Excel has if it wants a piece of that market share? Also $150/year for something that does it all and just works it's really not much. The same reason why we don't ask how much Visual Studio Enterprise costs or IntelliJ products even if you have free alternatives.
Oracle and Microsoft Office are global standards. The world uses them. Our civilization relies on them. If alternatives such as PostgreSQL and LibreOffice are not 100% compatible with these standards, they are lacking in functionality.
Oracle's definitely a standard in companies of a certain size and pedigree, but it's not even remotely as ubiquitous as Office, which is both a business and consumer product.
Anyway, it’s a risk like any other, and it may often be worth it. The alternative of switching to libreoffice is not free, and can truly be more costly than some office licenses and the risk that Microsoft will drop or fuck up excel (which most consider low)...
Personally having earnestly tried to do some complex work in libreoffice calc and running into just bugs and poor polish (error handling anyone?), it is not an experience I elect to relive... I still feel locked in to Excel as my life is too short to waste on the inferior product.
IT people really need to stop declaring this about FOSS products when it is regarding workflows they have no experience in.
We had a client send us a questionnaire in an Excel document with macros to compute various things based on our answers. You underestimate just how many things are done in Excel across companies (ie: you can't even force both side to switch to Libreoffice) that you would, probably, write a quick webpage for.
It also becomes tricky when you need to interoperate or integrate with companies that have chosen to use either GSuite or LibreOffice rather than O365.
With that said, I'm glad these alternatives exist even though they're never going to work for me.
Example: create four rows of four cells each, like this:
1 2 3 4
2 4 6 8
3 6 9 12
4 8 12 16
In Excel, that pastes a copy of row 1 at row 5, and a copy of row 2 at row 6.
In Numbers, row 1 is copied to 5, and row 3 is copied to 7.
In LibreOffice, row 1 is copied to 5, and row 3 is not copied.
So we have three ways to handle copy/paste of a non-contiguous selection: make it contiguous on paste (Excel), past non-contiguously (Numbers), and just copy the topmost row (it's topmost, not first row selected--if you select row 3, then non-contiguously add row 1, it is row 1 that copy grabs) (LibreOffice).
I'm not sure which of these is actually the most right from a theoretical perspective, but I bet Excel is the one most likely to be based on data about which method best matches what users actually do with the spreadsheets.
Joel Spolsky has an article [1] where he talks about what they found when he was on the Excel team at Microsoft and they actually started visiting customers to see how they used Excel. A couple quotes:
> Over the next two weeks we visited dozens of Excel customers, and did not see anyone using Excel to actually perform what you would call “calculations.” Almost all of them were using Excel because it was a convenient way to create a table.
and
> What was I talking about? Oh yeah… most people just used Excel to make lists. Suddenly we understood why Lotus Improv, which was this fancy futuristic spreadsheet that was going to make Excel obsolete, had failed completely: because it was great at calculations, but terrible at creating tables, and everyone was using Excel for tables, not calculations.
Looking at my own spreadsheets...I find that most of them are indeed really just lists or tables with maybe a little calculation. The few that I would say are actually heavily calculation oriented would probably do just as well in LibreOffice or Numbers.
[1] https://www.joelonsoftware.com/2012/01/06/how-trello-is-diff...
I selected the rows by clicking the row numbers (while holding Ctrl for the second one), and the version is 6.3.3.2.0, FWIW (I'm on Arch Linux so I suppose this is right up to date).
I was selecting by just selecting the four columns in row 1 by clicking and holding on 1 while dragging to 4 and releasing, then doing the same thing with row 3 while holding the command key down which is how you do non-contiguous selection on Mac, then clicking on column 1 of row 5, and doing paste.
I just tried it with clicking the row number, to do whole row selection. So click the number for row 1, then command-click the number for row 3. Then I clicked the first cell in row 5 and hit paste. Same result as I got before...just row 1 copies.
I also tried it where I clicked the row number for 5, to select the whole row, before pasting, and no difference.
Good to see that it is working better on Linux. That probably suggests this is just a bug in their Mac port rather than intentional behavior.
Tangentially, and perhaps weirdly, if the ranges I select don't span the same columns - eg. if I select A1:B1 and C3:D3, a dialog box pops up upon Copy which says "This function cannot be used with multiple selections". Even though the ranges are still the same size. That seems undesirable, to me.
It breaks down when you are using something like Excel with complex macros/calculations. This is why most companies continue to use Microsoft products.