Munich and Windows
In hindsight, how could the results have turned out differently?
Do not expect and do not demand that all vertical apps be migrated. That means running a mixed operating system environment.
Always first migrate apps. Remain on Windows and focus on the apps. Here be dragons and reality checks — a lot of the software cannot be migrated and cannot be run in WINE. Just not possible.
A contributing reason Windows remains popular, and for many people easier to use, is the Windows environment has supported something that many free/libre software developers loathe and detest — backwards compatibility. A lot of Windows software written 20 years ago remains fully functional in Windows 10. In the free/libre software world, backwards compatibility often breaks with simple minor point releases, let alone major revisions. Does backwards compatibility create “bloat”? Sure, but end-users don’t care. They use their computers as tools. Get the job done.
Possibly someday snaps and flatpacks will resolve the backwards compatibility hurdle.
Run vertical software in virtual machines? If the software is used daily in an office environment with human users, then why bother with a virtual machine?. Running two operating systems is clunky. If the software is run without common human intervention then virtualization can succeed. Yes the software remains in a native Windows operating system.
Could vertical apps be developed from scratch in a Linux friendly environment? Likely many can. A challenge with this approach is by and large, most free/libre developers are not interested in the business side of software. Most are interested only in scratching itches and geek needs. Most are not interested in providing hooks into “that other operating system.”
An example is GnuCash. The program satisfies the needs of many home users and small proprietorships but is futile for large business. Especially the lack of tax support. QuickBooks and Quicken remain king of the hill for a reason.
Another example is AutoCAD. There are no alternatives for professional use. Hobby use? Yes. Professional use? No.
There are many vertical apps that have limited and small target audiences. Without investment money from customers to pay for development, these types of apps are not going to be developed outside of Windows.
LibreOffice rather than Microsoft Office? For years my experience has been that LibreOffice does not transparently handle complicated MS Office documents. Even so-called simple documents sometimes required tweaking before saving in ODF. Round-trip saving of *.DOC(X), especially revision tracking, often fails. The LibreOffice developers have done an amazing job to reverse engineer the proprietary document formats, but the results remain spotty.
Rather than shove LibreOffice down users’ throats is to first allow users to choose one app or the other. Install LibreOffice and let users decide what to use. Then install a document management portal that supplies documents in PDF format. Most users need only to read a document. Only a few need to actually maintain the documents.
Developing and supporting an in-house distro likely was a poor choice. More efficient would have been out-sourcing a partnership with one of the big three distro maintainers: Canonical, Suse, or Red Hat. For the Munich people, contracting with Suse, home-based in Germany, would have been a sane choice.
There is a simple question I suspect many free/libre software advocates do not want to address. In what ways did free/libre software fall short in helping Munich workers achieve their work goals and productivity? Computers are tools. Get the job done.
I am guessing the world is a full generation (20 years) away from software apps that are truly operating system agnostic.