Post
@restorante @cvtsi2sd @wamwoowam.co.uk
The weirdest one of these I saw used Access for the GUI, but used the Excel ODBC connector and so the database app was just a GUI and the data was stored in a spreadsheet. This let people edit the data directly in the tables without knowing any SQL, or go through a workflow-based UI.
I am genuinely curious with your opinion on this trend.
@restorante @cvtsi2sd @wamwoowam.co.uk
A big organisation wanting to migrate can. It's not cheap, but it might be cheaper in the long term than sticking with the vendor that was exploiting them due to lock in.
I'm not really a fan of migrating from a proprietary product to a product that tries to mimic it. Proprietary office suites are designed to be platforms because the companies making them are incentivised to keep you on their product and lock you in. They want you (and other companies) to build things on top of their office suites, rather than as competing products or stand-alone tools.
Something like LibreOffice doesn't have those incentives (and therefore doesn't benefit from that design) but mirrors it because the developers don't really think about the social motivations that created the thing that they're copying.
NextCloud is building the same thing, I suspect, because the creators actually do want vendor lock in. Their choice of AGPL makes this much easier.
It's fine as an initial step, but I see a lot of it as the same problem as the European politicians who say 'We need an EU Microsoft / Google'. You absolutely do not. You need a competitive ecosystem of a thousand EU companies that can deliver anything Microsoft or Google can deliver, adapted for your use case, ideally from F/OSS components.
I have a lot more respect for the Mastodon folks than Nextcloud, because they're not trying to lock you into their platform, they're working on standards that make it easy to interoperate with their platform, whether you use it or not.
F/OSS developers could learn a lot by looking at things like OpenDoc / OLE, which failed in the market because they can't support a rent-extracting business models. Popular proprietary software survives because it's found a niche where the software architecture favours large companies as single sources. If you try to mirror their architecture, you'll always be playing at a disadvantage. If you adopt the designs that these companies abandoned because they can't make them profitable, things work the other way around.
Governments imposing upper bounds on complexity for individual components and minimum numbers of different vendors supporting a system assembled from interoperable components could help drive that.
Thanks for the detail answer to my question. I really appreciate it.
I do not really understand with this.
"Something like LibreOffice doesn't have those incentives (and therefore doesn't benefit from that design) but mirrors it because the developers don't really think about the social motivations that created the thing that they're copying."
LibreOffice uses Open Document Format. Thus, in a sense it is not really mirroring Microsoft Office. Why, since it is utmost impossible for locking people inside the open format.
@restorante @cvtsi2sd @wamwoowam.co.uk
It's not (mostly) about the document format, it's about the design of the application. LibreOffice is a huge monolith. It has some ability to run extensions, but the monolithic nature makes it very hard for other programs to interoperate with it.
The Open Document Format is a terrible spec. It omits a huge amount of detail (it's been years since I read it, but the first ratified version didn't even provide a grammar for spreadsheet formulae, it literally just had a place in the XML for formulae and implementers were just meant to know what a formula was, how to parse one, and what functions were exposed). But that's a largely unrelated issue. If it were a good spec, that only enables the kind of interoperability you get by saving a document in one program and importing it in another one, not the kind you get by having two programs communicate.
By being a single complex monolith, LibreOffice is very hard for anyone to modify. It's an enormous C++ codebase, where a lot of it is ancient C++ (and a load of the comments are German, unless they've finished translating them since I last looked). As a proficient C++ programmer (and member of the C++ standards committee), I am not confident of my ability to fix a bug or add a missing feature in LibreOffice. And, if I did, getting it upstreamed is a lot more work, so I'd probably end up carrying that patch for a long time.
In contrast, a lot more people can write Python scripts that coordinate between web APIs, or AppleScripts that combine features of desktop apps on macOS. For something like OLE, it was easy to create a custom object that I could embed in a '90s Word document (even in Visual Basic!) and have it make the document do something novel.
To give a concrete example: OPENSTEP's Text Services (also on OS X / macOS) make it easy to have a generic plugin that takes some highlighted text and replaces it with a PDF from typesetting it in LaTeX, so I can embed nicely rendered formulae in anything on macOS that uses NSTextView, whereas providing something that gives me a better equation editor in LibreOffice is orders of magnitude harder.
If you want to lock people into your platform, you build a big platform. If that isn't your goal (and it mostly isn't for F/OSS) then building something like that means that you're at a disadvantage. Your competitors will benefit from lock in and vertical integration in ways you can't. But if you build small modular composable software, your proprietary competitors can't do that.
If you have a system that's assembled from small tools where each tool could be written by a single person (or maybe a few people) then lock in is impossible. If someone produces something you want but you don't want to deal with them, reimplementing it is feasible in a way that reimplementing a Microsoft or Apple product rarely is. And if you're a government and want a thriving software market without lock in, that's the kind of thing that you should incentivise.
Would you please to give me two or three examples of highly modular modern software?
Unix toolbox philosophy and Emacs come to my mind. But these are probably not really 'modern'.
@restorante @cvtsi2sd @wamwoowam.co.uk
There isn't much, which makes me sad. My favourite recent example is SILE, which is not quite modular in the traditional sense, but it's designed so you can replace bits. For example, in typesetting my last book, I replaced a core bit of the page layout to add floating figures.
Imagine trying to change the way LibreOffice does line breaking.
By Word and Excel talking to Access, did you mean Access as a database and applications, and then Excel gets data on Access for analysis?
It is very interesting. I thought Access were almost die.
@restorante @cvtsi2sd @wamwoowam.co.uk
It mostly is. But a lot of companies built things on it that worked for the last 20 years and have had no incentive to change. Access was a pretty terrible database, but a surprisingly good RAD environment. I’ve seen a load of in-house programs running core bits of small businesses implemented on Access.
Ahhh I see. So Access is mostly legacy system. The modern version of COBOL.
I heavily use Excel daily. But almost never touch Access.
@restorante @cvtsi2sd @wamwoowam.co.uk
The weirdest one of these I saw used Access for the GUI, but used the Excel ODBC connector and so the database app was just a GUI and the data was stored in a spreadsheet. This let people edit the data directly in the tables without knowing any SQL, or go through a workflow-based UI.
I didn't know such thing can be done. If people only need to change data on tables, they can use the form in Excel to do just that. But a form per table.
Using Access as an Excel frontend is such a weird and interesting idea.
Will give it a try soon.
A space for Bonfire maintainers and contributors to communicate
