Project Proposal: Reimplement CoActivate as a Peer-to-Peer Groupware System
Example: GNU SIPWitch is a free code SIP server designed to run on the user's computer. Development began on a desktop user client to be bundled with SIPWitch, and instead of needing a custom implementation of the GUI for every platform SIPWitch is ported to, the client could displays in the user's browser, but still run from the user's computer, rather than a remote server.
This discussion on StackOverflow talks about possible implementation for Java apps on the desktop.
"Web applications", and "Apps", where the main computing tasks are done on servers, are returning us to the mainframe model, where the power and control is at the server, and the user has only a dumb terminal, which can do nothing useful without the server. This is the problem Stallman describes as "Service as a Software Substitute".
Why has this model has proliferated over the last decade or so?
One reason is because of the challenge of supporting cross-platform desktop (incl. laptop) applications. Every OS has different requirements for software to run properly, and securely, even different GNU/Linux distributions have some different requirements. Mobile OS have different requirements from desktop/laptop OS. Only large, well-funded projects like Mozilla, with fulltime paid developers, can successfully maintain cross-platform applications. Only targeting one OS, or only libre OS, limits the number of potential users, and the network effect of users encouraging friends, colleagures, bosses etc to adopt.
Software which runs on a server, and conforms to web standards, whether libre (HTML5 etc) or proprietary (Flash etc), and is displayed to the user through a browser, does not have to deal with these issues. But this does not explain the proliferation of mobile "apps". Why is everyone and their dog now encouraging users to download their "apps"?
I think the answer to this could be, that once a developer group's main project is a server stack, a key question for them becomes how to get people to use it. Mobile "apps" have emerged as one solution to this problem. If a group can convince a user to install their "app", there is a constant reminder on the users machine to use that service, and because users tend to take mobile devices which them everywhere, that reminder is present everywhere they are, which is not true of desktops or even laptops. Another reason could be, initially there was was only one dominant mobile OS which need to be supported, iOS, and even now that Android has become more common, there are only two, so the problems of trying to support a desktop application are avoided. Another reason could be, by maintaining an "app", rather than relying on constantly changing browsers to display the services' interfaces correctly, gives the developer group much more quality control over user experience.
The proliferation of client/ servers models across the internet has undermined much of its levelling potential as a peer-to-peer architecture. So considering the valid reasons it has become dominant, what are the alternatives?
* Don't build or use SaaSS. Any application which doesn't need the internet to do its job should run on the user's device.
* Build back-ends as servers, designed to run on the user's personal computer, or a plug server like the Freedom Box.
* Build graphical interfaces using web standards, and run them in the browser. This way, the interface only needs to be built once, rather than refactored for the GUI particulars of each OS (and each desktop packages on libre OS).