Monday, October 13, 2003

Lessons from Microsoft

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.