"...The current generation of network services or Software as a Service can provide advantages over traditional, locally installed software in ease of deployment, collaboration, and data aggregation. Many users have begun to rely on such services in preference to software provisioned by themselves or their organizations. This move toward centralization has powerful effects on software freedom and user autonomy [...] We consider network services that are Free Software and which share Free Data as a good starting-point for ensuring users’ freedom. Although we have not yet formally defined what might constitute a ‘Free Service’, we do have suggestions that developers, service providers, and users should consider: ..."
Full story »
can.axis
16 years 4 weeks 5 days 7 hours ago
A Response to Franklin Street, by Thomas Lord
A Response to Franklin Street, by Thomas Lord:
« ...
The Franklin Street Statement begins:
The current generation of network services or Software as a Service can provide advantages over traditional, locally installed software in ease of deployment, collaboration, and data aggregation. Many users have begun to rely on such services in preference to software provisioned by themselves or their organizations. This move toward centralization has powerful effects on software freedom and user autonomy.
On March 16, 2008, a workgroup convened at the Free Software Foundation to discuss issues of freedom for users given the rise of network services.
The working group published some recommendations that begin trying to frame the political issues around web services.
Below the fold I've appended a response I wrote to the statement, offered here for consideration and comment.
One of the statement's recommendations to developers says:
Develop software that can replace centralized services and data storage with distributed software and data deployment, giving control back to users.
That is where the real essence of the problem lies. It's the most important area in which to work.
Currently, web services are built out of conventional operating systems (often a LAMP stack or similar) and, at scale, web services are built out of custom-designed networks.
Consequently, currently, web services are a game for the rich and technologically savvy. Only the rich and savvy can afford to and can figure out how to set up a typical web service. Typical users, therefore, have no control (other than "take it or leave it") over what server-side code they run.
Contrast that with the *personal computer*. Nearly any fool can buy a PC at the local CheapStuffMart and nearly any fool can figure out how to install that new poker-playing software or photo album organizer or whatever.
Notice how that contrast relates to software freedom. The concept of software freedom is *meaningful* in the context of personal computing because any fool can learn to study, modify, and share software -- it's an economically viable option for users to actually *exercise* software freedom, and so it is worth fighting for the right to do so. In contrast, almost nobody can, as a practical matter, operate a web service: it takes too much money to set up and too much expertise to duct tape together a network for it. So EVEN IF all of the server-side code is openly shared free software, there is no practical way for the average fool to actually exercise software freedom over that code -- no meaningful way to use that freedom. EVEN IF the code is free, users are still under the power of service operators.
The political cause of freedom for web service users is first and foremost an *engineering problem*: we need a new server-side OS.
We need a server-side OS that allows each user to fully control the servers they use, including (and especially) allowing each user to change what programs are installed server-side. Once we have that new OS, the question of software freedom for server-side code becomes meaningful and the question of user control over data becomes actionable.
One way to work on such an OS is to work on the problem of how to sell user-controlled services. Amazon EC2 is an example of a project working on that one.
Another way to work on such an OS is to work on the problem of operations: keeping an application network functioning and scaling. The RAD lab at Berkeley is an example of a project working on system administration monitoring and control systems in that area.
A third way to work on such an OS is to work on the platform specification -- the "API" to the OS. Should it be some extension of Posix? Should it be something else entirely? What form will free software programs for this new OS take? My own work (http://basiscraft.com) is an example of working on that problem.
Franklin Street seems like a nice enough document but it lacks teeth and there's no urgency or sense of inevitability behind it. Compare that to the early days of the free software movement:
The free software movement began with statements of principle, sure, but that is not what propelled it to the success it has had since. Rather, it was the early days of the GNU project -- the engineering effort -- that gave the free software movement credibility and the problem of software freedom urgency.
The original releases (Emacs, GCC, and GDB -- all released in a short-time frame, followed fairly quickly by the shell utils, text utils, make, and autoconf) WERE, in essence, an OS. They comprised a parasitic OS, unable to run on its own -- only on a host system. Yet they were clearly a minimalist OS ready to grow into a complete system in fairly short order (as they did).
Those early releases -- that "hacktivism" or "engineering activism" -- is what gave teeth to the free software movement. They made the question of software freedom a *practical* question, faced by real users, rather than just a theoretical principle.
Perhaps Franklin Street needs its own version of a GNU project: a vision for the new OS and an engineering plan for how to achieve it.
-t
...»