Cloud Computing risks undoing the gains of the free software movement in ‘owning and controlling our own code”.
Thomas Lord examines the potential for achieving software and user freedom in the world of ‘cloud computing’ (a concept he rejects, preferring ‘utility computing’, see below).
Thomas is writing within the context of the ‘free network services’ movement, which gathers around the autonomo.us mailing list.
Thomas Lord:
“The term “cloud” is too vague.
The term “utility computing,” as used by Nicholas Carr, best captures the reality.
As the utility computing industry develops, we need to proactively stake out the case for software freedom on the utility service.
It is not hard to argue that strong demand for software freedom on the web can be constructed, but there is a chicken-and-egg problem: demand will follow the software, yet the money to pay for software isn’t obviously there ahead of the demand.
* Utility generators (data center operators) have incentive to invest in the R&D.
* Support-subscription sellers have incentive to invest in the R&D.
* An NPO in the support-subscription business might be a very good option.
The longer, conversational explanation of the same issue:
Sometimes people talk about “cloud computing” which, unfortunately, has become so vague a term as to be all but meaningless. It has something to do with people relying on lots of servers accessed over the net – that’s about it.
There’s a writer named Nicholas Carr that some may have heard of. He uses some more useful terms: “utility computing” or “commodity computing”. He writes about similarities (and differences) between the development of, for example, the electric grid and what is happening in computing.
I’d like to talk briefly about “utility computing” and explain why I think it is of central importance to the mission of autonomo.us. I’ll include some observations about the economics of utility computing as it relates to software freedom on the web.
You’ve all seen power generation plants (coal burning, nuclear, hyrdo, etc.). Picture one in your mind.
And now compare that to this. This is what a modern computing generation plant looks like:
* http://www.straightupsearch.com/archives/2008/04/google_builds_d.html
* http://www.youtube.com/watch?v=zRwPSFpLX8I
Racks of servers are assembled into bespoke trucking containers, shipped to the plant, installed in a bay, hooked up to power, cooling, and net and there you go. A large building, designed to hold these shipping containers, is basically a “backplane” for a super computer. The kind of super computer people used to imagine in the 50s only with chips instead of tubes.
Adjacent to that building there exist plants for chilling water, running back-up generators, transforming grid power to low voltage DC, and so forth. The whole assembly is really a breathtaking piece of work.
Such plants produce significantly less expensive server cycles, storage bytes, and so forth than other alternatives. That is (probably, hard numbers aren’t exactly public) some of the most cost effective server-side computing there is.
The data centers most of us see in real life probably look more like this:
* http://en.wikipedia.org/wiki/File:Floridaserversfront1.jpg
and those are dinosaurs. They aren’t going away soon but the rate at which new ones are built seems to be in steady decline and, behind that, there’s a non-0 (and probably climbing) attrition rate at which they are being disassembled.
The future in 20 years (maybe 10 or 5) looks even more interesting as the price of designing and fabricating chips falls further, along with the price of custom system design – and soon enough the racks in those shipping containers won’t contain general purpose CPUs but, rather, “map-reduce engines” and such: application-specific hardware, all the way down to the chip level.
One immediate consequence of that 20-year-view is: don’t count on servers that are even capable of running a complete GNU system. Simplify your plans for what runs server-side down to a few, general purpose programs.
The economic factors suggest that web services are increasingly, one way or another, going to migrate to large data centers like Google’s. Nothing can compete against their bang for buck except more like them.
That is the concept of “utility computing”: Just as in many circumstances it is far less expensive to buy electricity off of a grid, from massive scale generators that are remote so too with computing: it’s becoming cheaper to buy your server cycles from a massive plant rather than generate your own.
Google’s servers, these days, are managed in pure anti-freedom: users have no control at all over what programs are installed on those servers or even over who can access the data stored there.
Another utility computing generator is Amazon who give the users a larger degree of control:
* http://aws.amazon.com/ec2/
although even they won’t let you modify the kernel on your server unless you are a Special Friend and your data privacy is still not particularly assured.
So we can see the future of utility computing and, at this stage, the light of hope for software freedom on the web is fairly dim.
One of the tasks for autonomo.us, in my opinion, is to make the economic case that it is good business to sell utility computing direct to consumers, giving consumers complete software freedom and data security on the server side. Yes, we say to the utility companies, that’s a very nice facility you’ve got there — now let us rent it like we can rent bays at the local self-storage lot.
Making that case means demonstrating demand.
We can only guess but my guess is that finding demand will not be much of a problem IF – and it’s a big IF – we have compelling, easy to use, easy to administer, distributed, decentralized, P2P apps ready for use.
By analogy: I can tell my (non-tech-type) mom to go to such and such a site, download a program, and click to install it on her PC and that works. Or people tell their friends to go to the “app store” for their smart-phone so that the group can all play a particular game. The analogous way can work for “personal web servers,” too.
It is kind of a chicken and egg problem: if the apps exist, a few bucks per month for a personal server or small-business server, or community group server is not a high burden. It’s probably compelling to many users if, instead of “signing up” with this or that centralized service, they go to the free software “app store” and install their own instance. Yet, where are those apps supposed to come from to create that demand?
Well, “us”, obviously, but that doesn’t really answer the question. It’s going to take a lot of money to create this new generation of apps.
The technical work is not at all intractable. No huge new breakthroughs in computer science or software engineering are needed. Yet to put it all together is a very large undertaking (not unlike the original GNU project: doable, but huge).
So, the question arises: what are possible bootstrapping and sustainable economic models? What pays for the development of software that protects and promotes software freedom on the web?
Two observations come to mind:
One observation is that a world of software freedom on the web the software is non-rival but the servers remain scarce. The significance of this observation is that server providers are still in a position to charge a premium – to make a profit. To the extent that their goal is to grow, they are helped by the development of new free software apps for consumers to run on their servers. Thus, they are sensible when they reinvest some of their profit in free software R&D. One good goal for those of us on [email protected] might be to construct for those providers an investment vehicle.
Another observation, especially so long as libre servers are likely to run GNU/Linux, is to get into the business of selling subscriptions to complete, more-or-less-trustworthy distributions that can run on those servers. Red Hat is (at least) one example of a company *already in this business* (vis a vis Amazon EC2). Such providers also have incentive to reinvest profit in R&D and, indeed, I can’t think of any good reason (other than bootstrapping difficulties) why a software freedom NPO shouldn’t directly enter into the support subscription business.”