Post #2437938

Something I realized recently when I found a phrase for it: protocols can only go so far, then they get stuck in the past. XMPP is very much like this, HTTP and email are, and even IP itself (cough cough IPv6). Central development gets around all of that -- and you can still use protocols. The best example of this model I can think of is DeltaChat's core library & app set. You can use that core library pretty much anywhere, and build an app off of it that's fully featured up and down. Better, since it has a better development concentration than a protocol-only model, the apps for each platform are native, or at least more native than they would be using something like Electron, Tauri, Flutter, or React Native. You can, of course, start with a core library and any of those (preferably Tauri or Flutter), and grow to support centrally-developed native apps over time. For cases where a core library approach won't work, you can always fall back to encouraging forking and contributions by not breaking things (maybe a modular or plugin/mod-based approach as well). This is basically the model of (good) modded video games, where you can edit the ever living hell out of it and it's largely compatible. Central development also means that some group is responsible for coordinating developments across participants in the protocol. Forks can then rebase. This cycle, well maintained, often means you get support for new features across the ecosystem a lot faster than a fully protocol-only model. Good central development, of course, must be FLOSS, to allow and encourage development by third parties. (Term list: central development, core library approach, modular approach, plugin-based approach, centrally-developed, protocol-only model)