by Asim Jalis
Here are some meditations on the original Basic interpreter that
Bill Gates and Paul Allen wrote.
1. They leveraged partnership. It's hard to sell software alone.
You have to not only create the software but also create the
infrastructure to deliver the software product. It's program
versus product. Bill and Paul got around this problem by
partnering with MITS. They created the Basic interpreter as an
add-on to the MITS Altair computer. It added value to Altair. And
then they leveraged the existing sales and operations channels
that MITS already had. They piggybacked on those channels. They
had to do nothing except deliver the software. MITS took care of
the rest. MITS was also nice enough to give them a check every
time they sold their computer with the interpreter.
2. The value proposition to MITS is obvious. Their machine was
viable without Basic, but the Basic made it accessible to ba much
wider market. Basic tweaked the underlying product to make it
more attractive.
3. There was another interesting thing about the interpreter. It
followed a standard: the Basic programming language. Also it
followed the standard of being implemented on MITS in MITS
assembly. It was hooked on both ends through standards. It was
hooked to the underlying operating system through the assembly
standard. It was hooked to its useres through the Basic
programming language standard. A standard means not having to
learn new things. Things are much more plug and play.
4. There was curious quality to the complementarity of Basic to
the underlying machine. It did not specialize the machine to a
particular group of users -- it didn't make MITS easier to use
for graphics designers or some other niche group. No. It
generalized the machine by increasing its user base. It did not
specialize the machine, it generalized it. Suddenly more people
could use MITS.
5. An add-on for Excel does not have the same kind of
complementary relationship. A neural network add-on specializes
Excel. These specializing add-ons leverage an existing
architecture -- such as Excel -- and so they save some time on
the programming -- but they don't really create a bundling value
proposition for the seller of the underlying software. The seller
has no interest in partnering with the add-on writer to grab a
tiny niche market.
6. The machine seller will have to revise his whole marketing
campaign to target this specialized new market. It makes no sense
for him to throw away his existing customers and to chase after a
tiny new customer base.
7. This is what happens with specializing add-ons. The case of
generalizing add-ons is completely different. When an add-on
generalizes it creates a great bundling value proposition for the
original seller (or the OEM). The add-on now really adds value to
the underlying product. Before this the machine was adding value
to the add-on but the add-on was changing the machine in such a
significant way that its presence was not adding value the
machine. However, in this new case, in the generalizing case, the
add-on in fact adds value to the machine.
8. The add-on does so without reducing the power of the machine
in any way. It provides a layer on top of the machine that makes
the machine more accessible. The add-on enhances the machine. It
is like a catalyst for the machine.
9. One simple way it can do this is by simplifying the use of the
machine, as Basic did for the MITS Altair.
10. While that opportunity is taken there are others like it. We
just need to think hard enough and look hard enough and we will
find it.
11. The machine has grown since those days. Now when we talk
about the machine we include the operating system on it and the
fat software stack that ships with it. Now we must take that as
our starting point and find ways of enhancing that software
stack, of adding value to it. But adding generalizing value to
it, not specializing value. The distinction is quite important.
12. Let us look at some more examples of generalizing add-ons to
see if a common pattern emerges.
13. Another example of a generalizing add-on was the socket
component by Tatum software. The Tatum Trumpet. Another was the
original web browser, Mosaic. In both of these cases the add-on
connects the machine -- now when we speak about the machine we
are talking about the machine with its operating system and
software stack -- in both these cases the add-on connected the
machine to the rest of the universe through the communication
channel. It made the machine more powerful. But it did not
restrict the previous functions of the machine in any way. The
machine could still be used for all its previous functions, but
now it could also do this new things, this communication.
14. Were these really add-ons or were these brand new operating
systems on the machine? Perhaps communication is a different
dimension, different from interpreters. Although it could be said
that the Basic interpreter also merely made communication easier
with the programmer.
15. Here is a thought: What about libraries that make it easier
to do things that are already possible. The Basic interpreter did
not really create any new functionality. In fact this is an
important point. While the web browser and also the socket
libraries, created new functionality, the neat thing about the
Basic interpreter was that it made no new thing possible. The
machine was capable of no more and no less with the interpreter
than it was without it. It just made the machine easier to use.
16. Let us focus on components that enhance the usability of
existing libraries rather than create new functionality. There is
something important here.
17. For example, consider a component that allows easy encryption
and decryption. Or consider a component that allows easy download
of internet pages. And so on. All of these components would
provide a layer of simplicity on top of the .NET architecture.
18. But now why not work at the lower level? What kinds of
components could be generalizing add-ons at the lowest levels? At
the levels of bytes perhaps?
19. Does the SMTP driver fulfill this definition?
20. The SMTP driver creates new functionality, in essense. It
does not really enhance existing functionality. It is an
innovation much like Trumpet was. We need something that is not
quite so innovative.
21. Why not just do the obvious thing? Design a language? Or
implement an easy to use language on a difficult to use
architecture?
22. Languages are quite powerful. In a manner of thinking, even
MS-DOS is just another language, pasted on top of the hardware.
23. Another key element of the original interpreter was that the
machine was made by a small company. MITS was tiny. It saw
nothing odd in striking a deal with a start-up made up of two
adolescents. If I build a component on top of the Microsoft
operating system now things will not be that simple. MS is a
giant of a company. It might not be eager to form partnerships
for components. Although, we should not rule out that
possibility.
24. But one fruitful way to go about this might be to find a
small machine. For example, Palm. Even Palm is not so small any
more. There might be some small machines out there though.
25. Here is yet another direction: Look for small software
companies. Think of their software platform as the small machine.
26. Java is an obvious example. Java is not small, however, it
does provide a kind of machine-like layer on top of the hardware.
Think more generally. For example, Tivoli is a kind of a machine.
It could be enhanced through a layer, an API of some kind. All
these large platforms are machines of some kind.
27. Look for machines of this kind that are provided by small
players. See if their machines can be extended in some way, and
then try to sell them the extension as a generalizing add-on.
