Microsoft is clearly keen to avoid this becoming a thing. If governments can shift successfully then so can businesses
https://mspoweruser.com/microsoft-germany-moves-into-a-new-h...
(MS had tried to pressure against the move from the start, but wasn't really successful in the first years)
The entire design of "LiMux" was doomed from the start: it was a highly customized version of Ubuntu that was only used in Munich (not even throughout the entire state). That made everything ridiculously expensive since the actual advantages of building on an open source solution was never realized. That is combined with the fact that "open source" and "cost savings" were used interchangeably when in reality the budget for Windows should have been pre-allocated into development, rather than cut.
The entire project was half-assed to begin with, which basically meant that Windows and Linux had to coexist since many crucial tools were never ported to Linux.
The "Microsoft killed it" story sounds realistic, but the truth is the much more boring incompetence in execution.
Equally I'm sure it was never going to be a cost saving exercise since firstly the cost of Windows is negligible, and second the conversion costs, in-house skill requirements, re-training of users, and porting existing software are all significant.
So you go from cheap software to free software, but from cheap IT staff to expensive, perhaps-incompetant, hard-to-replace IT staff.
If the savings aren't real then the fallback argument is privacy etc. But Libre Office runs fine on Windows. So by all means start there.
The main point was that Munich saw an opportunity to leave a monopoly for an option with competition. When the LiMux decision was made Munich had to change their whole IT landscape anyway (They ran on NT4 and even extended support was running out / getting extremely costly), so they thought: If we have to change anyway, why not change for something where we have more options?
Firstly, the number of options argument. Choosing between lots of options, over choosing the best option, isn't some intrinsic good. I don't support say football over Formula 1 because there are more teams. I choose one over the other based on which sport I prefer to watch.
Going the Linux route "because there are more distributions to choose from" is a dumb argument if Windows is the best OS for your organisation. [1].
Equally, you may decide that you'd prefer to foster competition. You might decide that it's worth subsidising competition just to have competition. You acknowledge you're making an inferior choice, but the are unaccounted upsides to others having that choice.
But govt adoption of Linux (especially creating your own distribution) does little to nurture competition. Munich didn't spend its budget improving Linux. They spent the budget implementing it.
There are reasons Windows and Office dominate the desktop, especially in large scale environments. You may not like MS, but that doesn't negate those reasons. If you make a choice to forge a different road because you don't like MS then you'd better be very clear on what those reasons are, and what challenges and costs you are likely to face. Because if you aren't, then earn those challenges and costs come up it's hard to wave them away.
I'm not saying all this to rag on Linux or OSS, or to say its impossible to run Linux etc. As per the GP, there are companies that have made a choice, that hire people with the right skills, that make it work.
But thinking that rolling out Linux at enterprise level is easy, or cheaper, or has better desktop options, or runs more bespoke software, or is easier to get good desktop software for , or is easier (cheaper) to buy hardware for, is wrong. And that wrongness will lead to project failure. And those failures don't help Linux, arguably they hurt it.
Nope. They moved from Unterschleißheim (administrative district of Munich in Upper Bavaria) to Schwabing (district of Munich town), which tax-paying wise makes the difference.
Fuck, it seems (from Google Maps) to be about half as far from the center of Munich as the Munich Airport. If schitt that far out is called "Munich", then so is Unterschleissheim.
The other harsh truth is that those using more advanced features are typically creating spreadsheets full of errors and bugs, which should be better rewritten in dedicated apps.
The world is using MS Office but the world really doesn't need that turd.
I ve both ported an Excel spreadsheet to dedicated app and helped SMEs move everything to Google workspace.
Fuck MS Office.
My experience has been the mirror opposite. I’m doing finance/accounting day to day but can also code. The attempts to replace excel with custom apps were consistently absolute horror shows full of consultants, endless meetings, coders not understanding finance nuances, endless parallel running, budget overruns. And then months and a couple of 100k spent later all to duplicate a spreadsheet someone had originally slapped together in a day or two.
Not wildly attached to excel but now actively steer clear from custom app projects due to career risk of being in proximity of these.
It’s the same as big SAP projects once the “customizations” start. The implementing teams incentives are the precise opposite of the business. Bill as much as possible, extend project timeline, add more features and widgets, make things seem more complicated than they need to be, pull users away from their work to test, cater to the execs with dashboard instead of the team in trenches, endless CYA processes camouflaged as “end user acceptance”, office politics shenanigans to promote the solution etc. I’d much rather debug & streamline a spreadsheet than deal with all that.
I do agree that spreadsheets tend towards chaos as complexity increases though…
"Modern Web Apps", based on "The Modern Data Stack", and so on...?
Give the spreadsheets (and access to two or three of the people who made and use them!) to one or two guy[s] with Delphi, and you'll have an old-fashioned client-server app -- which isn't a bad thing; it's what you want in contexts like this -- in a week or less. For the first one; the following ones are faster.