Do you have questions about the site? Write to bruce at perens.com .
List of all articles we've ever published.
Source Code
Developer's Documentation
RSS
XML Sitemap
XML News Sitemap
![[Valid RSS]](/images/valid-rss.png "Validate my RSS feed")
What's a hacker to do?
Guy Fawkes recently posted darkly about.... well, about many things. In part, though, he posted about this idea:
That's an engineering challenge, actually! Here's how I see it:
I hereby postulate the Principle of Cultural-Determination by Engineering:
For example, if we build many radios but just one transmitter tower, then a few of us will become broadcasters and many listeners. Another example: if we build widget that comes in a sealed case with no usefully serviceable parts, then some of us become authorized repair/exchange agents and others become potential cutomers for extended warranties and service agreements. The engineering decisions to build but one tower or to seal the case: those are co-commitment with downstream decisions about jobs, power, authority, and money flows.
The two examples (transmitter and sealed case) have something in common: asymmetry is a key feature of each. The engineered artifact presumes a separation of roles and so, then, the economy gives us that: broadcasters and authorized repair / exchange.
Turning to Google Mail and similar services: all contemporary web services have a particular asymmetry in common: every one of them presumes that there are regular users, and then there are other privileged users in the back office.
As a society and economy, we simply don't know how to build a web service like an email service other than by building Big Brother into the architecture. Perhaps we "know" in theory but, in practical terms, we seem to be stuck building more and more systems on web service platforms that have user surveillance built-in from the ground up. The first step of each new service is roughly: "design the database tables". So, someone has to be the Watchers behind the 2-way TVs. We become what we build.
What would an email web service look like if the software was built in such a way that "there is no back office -- no Big Brother built in"? No central "administrator role" with privileged access to other user's data?
It was contemplation of just that question that led me to build flower. There is my answer (a large part of it, anyway). And here is how it relates to problem "Big Brother Built In":
Flower is a very, very high level virtual machine and it is very "web centric". The primitive data types of Flower are identical with the types defined for XML. The primitive operations of Flower are (quite powerful) database queries (in XQuery). Primitive operations can trigger database updates, web transactions, and other forms of side effect. Data for which an XML representation is inappropriate (such as image or audio files) are handled at arms length: as named, persistable streams of octets that can be forwarded but not directly examined.
Remarkably, simple but effective implementations of Flower can be assembled from off-the-shelf free software with the addition of but a few lines of code. The resulting assemblage is, itself, remarkably simple with extremely few external dependencies. A server dedicated to running only instances of Flower could actually be quite minimalist.
Flower is a reflective, dynamic environment: programs can install and run other programs on the fly; programs can build other programs on the fly; programs can modify themselves on the fly.
Well so what? How do those technical bells and whistles relate in any way to the "Big Brother Built In" problem?
For one thing, part of the answer: I claim that Flower is amply powerful enough to build a "personal email server" (as one example). That is, any one of you could pick up a copy of Flower and, yes, you'll have to wrestle some of the "alpha quality" out of the code but... you can get from there to an email service with much of the friendly charms of, say, Google's -- except it would run on Flower. (And then you could extend this with calendering, etc.)
The other part of the answer: Applications written in Flower need no separate class of "administrator". The user operates the program for themselves.
You've written your email server -- how do you share it? In today's world, using Big Brother software, you better get some hosts and set up shop. Can't have your server without your back office. To pay for that you'll want ads....
In the Flower world: just email the source code to your friends. They can grab a generic Flower instance, securely hosted at the ISP down the street with cameras on the machines all the time and a monthly party around visiting the metal shredder. Flower is reflective, remember, so your friends just upload the code into their generic flower instance and, there you go. User in control. A much tamer facility with no "Back Office" to speak of.
-t
p.s.: The whole "stack" is due for pretty radical simplification. These guys make some sense. I like my vm better than theirs but mine isn't done yet so don't look at it :-)