FileGardens

Project Proposal: Reimplement CoActivate as a Peer-to-Peer Groupware System

For groupware tools, or other kinds of applications in which communicating across the internet is inherently necessary, one solution could be to build user applications as cross-platform back-ends, which display their GUI in a browser. This way, the developers will need to develop a version of the back-end for every OS they want to support, but as long as the GUI is fully compliant with cross-browser web standards, they don't need to worry about any of the GUI layers, or making sure things display properly in the local graphical toolkit of each OS/ desktop. This is actually quite similar to the way SaaSS systems work, where a lot of the client code runs on the user's machine using Javascript and other scripts, alllowing it to connect with the back-end on the remote server.

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.

Background

"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 sometimes 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 with 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).