WorkSpot 1.0
June 6, 1999
Greg Bryant

Project: Virtualize GNU/Linux, make it 
available to consumers over the Internet.


The primary WorkSpot goal is to create a virtual desktop,
that resides on the Internet, which a user can access from
anywhere else on the web.

This is a client-server application. Most of the computation
takes place on the server-end. But what should the user-end,
that is the client-end, look like? 

Our initial try was to create an HTML-level user interface, 
and to allow developers to create HTML-level applications 
to plug into the user's data. This is also the approach of
our competitors.

But how about creating a direct connection to the desktop of a
virtual computer? The hardest first part of this, we knew,
was the screen connection to a browser. Later, we found
this work was already done and available under GNU GPL
or General Public License (i.e. FreeSource). That project is
called Virtual Network Computing (VNC).

With VNC available, it's fairly easy to imagine what the 
WorkSpot technology should look like.


1. The top layer is a VNC connection, over the Internet. VNC
uses a Java applet that can run securely within a user's browser.

2. The VNC connection is made to a user desktop. This desktop has
to be a "web-enabled" desktop, through which you can browse,
and onto which you can drag URL's. After all, people will be 
using it in a browser. It has to integrate with the verb and 
noun that have made the WWW so influential: "to browse" and 
"the hyperlink". But it also needs traditional desktop 
functionality, icons for launching applications, filenames,
going to other desktops etc.

Incidentally, this gives us the opportunity to actually merge
a decent browser into a desktop. And to organize the creation
of a decent desktop [with, for example, integrated history, 
and multiple 'saved' desktops, in which you can leave applications 
open, and come back to them later...]

3. Under the desktop is a stripped-down version of Debian GNU/
Linux. Ultimately, the consumer-level web-desktop needs to 
protect normal people from the UNIX programming environment,
and to run applications in separate virtual machines etc.
But it's still Debian GNU/Linux underneath.

4. The GNU/Linux is stripped-down because it's running on
virtual machines. These virtual machines are isolated
slices of the real machines they are running on. This is the
typical approach to virtual machine technology, as opposed to
the Java approach of defining a brand new artificial machine,
simulated or emulated, as a standard.

5. The virtual machines will have access to virtualized disk
space, acting as close to the machine as possible. Virtual IP
addresses, video devices, graphics and numerical acceleration,
etc., will also be available.

6, The Virtual Machine Monitors, which actually spawn the virtual
machines, will link together an indefinate number of machines.
This is so that the actual applications may run on any available 
real machine.

7. The reason this has never been done is because of worries
over bandwidth (internet connections don't deliver much
data) and latency (internet signals are too slow for the
user to feel real-time control). The broadband problem
is being dealt with as we speak. The latency issue can
be dealt with by distributing WorkSpot 1.0 to ISP's around
the world that are physically close to the user [this also
implies that we will be distributing WorkSpot 1.0, and
not trying to host everyone ourselves].


Linux, for all the publicity and steep investment (both 
corporate and community-minded) is available to almost no one. 
Only programmers and corporations buy boxes and put Linux on
them. A very constrained market, by Internet standards.

But, if we make a virtual Linux machine available to EVERYONE,
this changes everything. Linux will no longer be just a back-end
system. It'll be a consumer system, and every computer user will
have access to it.

This creates a new kind of channel for distribution
and payment of services -- users will pay ISP's, developers,
and us, for their computing experience. And this will obviously
improve GNU/Linux and its offerings.

The new channel will be open to all those people and 
corporations (and there are lots of them) who are, and have, 
invested lots of money porting consumer products to Linux. 
Some biggies here are IBM and Corel. These companies, and many 
others in the worlds of hardware, networking, and telecommunications, 
can probably be convinced to invest in making WorkSpot successful
and omnipresent.

Why us? Why wouldn't they make their own equivalent system?
Well, we ARE community-minded, we want everyone to make money,
and WorkSpot 1.0 will be distributed under the GNU GPL. It's
freeware. That gets a lot of attention, and gives us a special
place (as long as we are technologically strong). Why would a
large company compete against us when they can just make money 
through us? And invest in us.

But how about OUR making money? Investors want to know not just
what we're going to do for them, but how we're going to make 
money in the future. [So we're IPO-able.]

Our primary ways of making money are:

1) Maintain the monetary channel between users and providers,
and taking a cut.

2) Maintaining the "site" which acts as a software center: 
categorization of applications, feedback on them, catalyzing 
new applications, etc.

3) Coordinating the network of ISP's that makes WorkSpot 
inter-operable across the world.

4) Taking on contracts to:
a) add software to WorkSpot (Oracle, IBM etc), making 
it "automatically available" on the virtual 
machine (you wouldn't want people to have to 
configure oracle on a virtual machine -- you 
should just be able to connect to it), and take
a cut of THEIR residuals.
b) catalyze developers to use new technologies through 
c) create workspot connections through various 
technologies jini, wireless, voice
d) refer developers

5) Handling all advertising on the desktop -- there may be some, 
or their may be none, depending on  the user or the ISP. But we 
handle this transaction since we are the "authors" of the 
desktop technology.

6) Develop our own software, and get WorkSpot revenues
from that. But that's sometime later. We have hundreds
of ideas, but our main advantage will be that our company 
name will be known around the world because of this free 
platform we've created! The branding possibilities are endless
"The WorkSpot office suit" or whatever. WorkSpot will be the
platform name, so will carry a lot of weight when people
are choosing applications to use on it! and of course
our own software will get our highest ratings in the software
center (cause we won't charge for it until it's good ...)
Since we are using free source, we want to produce free 
source. In fact, I believe that bits of the revenue stream
should be fed back into those projects that are part of 
WorkSpot 1.0. The GNU, VNC, WINE and Linux projects, for 

But, if the source is free, how do we retain control of the
monetary stream between application developers and users?

First of all, the GNU GPL means that anyone using EVEN A LITTLE
of our code must also give away THEIR source. That means no one
can steal the code, run away, and hide it somewhere in a 
proprietary system.

Now, why won't someone somewhere take the code, set it up and 
CHANGE the monetary stream?

Part of the way the monetary stream works, and the way the 
software works, is that we will see all the transactions of 
the system. They can't hide any changes they make without 
breaking the license.

But say they just switch roles with us, and put their 
e-commerce connection in place of ours. What's to protect 

1. Consumers -- we hope to have heavy industry and non-corporate
goodwill, so that if some one does this they will become 
insignificant since application providers will not be providing 
their software to that pirated WorkSpot.

2. But in case some big corporation tries to do this (highly
unlikely) we have a patent on this business plan:

Create a FreeSource virtual machine and desktop,
give it away, make money off the resource, application
rental, and advertising revenue streams, and sue anyone 
who tries to make money in the same way, since we have
a patent on the business model.

Note that the actual relationship between us and developers will
be taken care of through standard encryption keys. Once they've
developed this relationship with us, they are unlikely to
have it with anyone else (rather like VeriSign's business
model, but taken several steps further). WorkSpot micropayments
will not work unless parties involved have these encrypted-
key relationships. So pirated copies of WorkSpot won't be able
to "charge" micropayments during application runs.

NB: security is taken care of through encryption keys for
monetary transactions -- therefore releasing WorkSpot source 
free, continually under "copyleft", is quite safe. Safer,
since many programmers will be thinking about our security


We want WorkSpot 1.0 to be free source because we want people to 
work on it. Those people will of course be paid residuals for
work on WorkSpot, the same way application developers get paid 
by users of WorkSpot.

[As an aside, I should note that web CONTENT providers will also
get paid through the WorkSpot mechanism -- they'll get residuals
for TV shows, movies, audio, financial information, databases,
etc. And we get a cut of all that money flowing for content...]

We take our cut. This is good for software, and good for 
developers and content providers. Free source, used for this
purpose, under our authorship, is for the community benefit. 
That's what the license says. You can do what you
want with the code, as long as you keep your changes public. 
But our patent says you can't do what WE're doing.

People could eliminate the micropayment channel, but then only
free software will run on the system, since developers who want
money will not provide their applications.

The question of how a developer who uses and developes free 
source can get residuals through the WorkSpot mechanism 
is very important. Users pay for RUN TIME and other resources. 
The run time charge for an application is the same whether 
the source is free or not. Identifying the owners, authors of 
code is important, and doesn't violate the spirit of free source. 
It's intended just to reward those who organize and contribute 
to a particular piece of code. 

If "A"'s code gets incorporated into "B"'s 'product', then 
everyone will know that B is a thief, and through an 
eBay-esque public humiliation (through WorkSpot's feedback forum) 
people will know that "B" stole from "A".