Information Letter 2

Information Letter 2 was the first general communication after the initial organisation meeting.

This letter is to bring you up to date on what has happened with the formation of MSP since the January 30, 1982 meeting. I assume that everybody who intends to participate has already sent a letter to that effect, so we know who is involved and what they want to do. Since just about everybody at the meeting decided they wanted in, there is certainly no doubt that our software development capability is awesome—I can think of no product on the microcomputer market today which we could not develop if we decided to. Now we have to put together the organization to define the products, produce them with the desired quality, and market them.

Alternate forms of organisation

Keith Marcelius suggested an alternate way of organising the company which looks to me like a potential solution to some of the major concerns we all had about the original proposal. It allows us to accommodate people whose financial contribution cannot be commensurate with their time to devote to the venture and it gives a way to reward those who contribute more than their expected share.

Let's assume for the moment that the company is formed as a corporation (this might also work for a limited partnership, but we don't know yet). Suppose we authorize and issue 1 million shares of stock initially (the number is totally irrelevant, but should be large enough so that round-off can be ignored). 600,000 shares of stock are sold to the founders of the company based on their capital contributions; this establishes their initial share. The number of shares purchased would be:

(YourContribution / TotalInitialCapital) * 600000

The remaining 400,000 shares of stock would be held in the corporate treasury. The effect of these shares would be nil as long as they are retained in the treasury; if dividends are distributed they just loop out of the checking account back into the treasury.

Every year, based on people's contributions of work, a stock dividend can be declared to those stockholders who contributed in excess of their share. This means that we take those shares out of the treasury and give them to the person who contributed the extra time. This increases his share at the cost of diluting the shares of those who did not receive the stock dividends. All distribution of stock dividends would be subject to a majority vote of stockholders by shares, so participants' shares could not be watered without their consent. This may have adverse tax consequences and may become more complex to reduce the tax liability of this distribution.

All of this is a very complex way of implementing a simple idea—if one partner wants to work very hard for the company but has no cash at the moment, we can let him earn his share through “sweat equity”, subject to the approval of the other holders. On the other hand, if a partner does not contribute the work he promised, his share will be gradually reduced as the other participants won't be likely to approve a stock dividend for him. Also, if a participant wants to increase his share by buying additional stock, he may do so at a price agreed to by the shareholders who may agree to sell it to him.

I want to make it clear that this is primarily a way to accommodate cases of hardship where the initial capital contribution is absolutely impossible to obtain at the start, and also to create an incentive for producing work as promised. It is not a way for all partners to avoid contributing capital to the venture—after all, those who do not contribute initially have no guarantee that they will ever be voted a stock dividend—they're trusting those who hold the majority share to compensate them when the time comes.

At this point it looks like if we can do it without adverse tax consequences we will go ahead and incorporate the venture. To avoid the tax disasters, we will remain a “software manufacturer” selling discs rather than licensing our products for a per-copy fee. As soon as we begin to generate revenue we want to pay out, we will put all the shareholders on the payroll, thus avoiding a large part of the double taxation of dividends. At this point the final word isn't in on whether we can make a limited partnership do what we want to do, so this decision has not been reached. We will be consulting a lawyer who has formed numerous high-tech ventures and who can presumably tell us what we ought to be doing. I'll send out another letter once we find out. I'm sending out this information at this time so you know what we're thinking at the present moment so you can comment on it.

New participants

We have already received participation commitments from two of our overseas contacts. Rudolf Künzli of Basel, Switzerland has extensive systems and applications programming experience and will be helping with software development and testing as well as marketing our products in continental Europe. His expertise in languages will enable us to offer products that stand out by not speaking English exclusively. Peter Goldmann in England has extensive experience in systems programming and data communications as well as the all-around experience common to those present at the meeting. We expect our dealer in London, Richard Handyside to become involved also in some capacity; we're pursuing several options at this time.

From our experience in MSL, we've found that the export market is very important, and I feel that these participants will give us an important start in marketing our products overseas, as well as market research and product customisation for these markets. Remember, the computer market in the EEC alone is the same size as the US domestic market. Ignoring it can cut your sales in half before you even start. Also, since software is considered printed matter, it avoids almost all customs hassles, so it doesn't really matter where your customers are.

Resumes

As was discussed at the meeting, we'd like all the participants to send resumes to us. These will be kept as part of the MSP business plan, and are essential if we need to secure venture capital. Also, we'll copy all of them and send copies to everybody so we all know what skills we have in the company. What we want is more a statement of qualifications rather than all the job summary garbage. What matters is what you know, what you can do, and what you've done.

“Edges”

I'd like everybody to be thinking of things we can do to distinguish our products as a whole from other peoples', and give dealers and distributors reasons to try our products in the first place. Two have been suggested so far:

Rudolf Künzli suggested that we make all of our software obtain all its messages, menus, and prompts from a direct file. We would develop a common routine which returns message text from the file by number, and a subroutine which inserts text in the message. This gives us two important advantages. First of all, the most common customisation request for all packages is to change certain messages. We can tell the dealer, “Buy a MSP package, and you can change the messages with this little utility—no programmer is needed”. Second, we can make our packages speak any language we want just by translating the message file—one object code version will suffice. The advantages in the overseas market are obvious. Note that a pure PRINT USING type expansion isn't quite enough—you'd like to be able to change the order things are inserted in the message. Thus, you might read a message like:

    "Put the #1 in the #2, #3!"

and print it with something like (assuming QBASIC):

    a%=fn.print.msg(187,"disc","slot","idiot")

The #n in the message would match with the order of parameters in the call (yes, I know the problems with this example—but you understood the point, right?).

Second, we can make our packages work on any terminal with no special generation required. Thanks to Greg Lutz, we've obtained a copy of the UC Berkeley terminal capability database, and Mike Riddle has written a program to decode it into easily accessed parameters. By writing a universal terminal module that is driven by these parameters, a program can adapt to a terminal simply by taking the name of the terminal, looking it up the database, and plugging the parameters into the driver. As the UC database is constantly updated, most of the maintenance work is done by our tax dollars, not our flying fingers. If somebody shows up with a terminal not in the database, we still only have to make an entry in the file, not program a new driver. Thus, a dealer selling our products need only set up a configuration file when selling the package with a statement like:

    TERM ZORCHTERM-100

and our package will be ready to go. I think this is a powerful selling point and we should do it for sure.

Now, what are your ideas? I don't want to jump into thinking of products just yet, but what are the company-wide concepts we should be putting into everything we do? Or, putting it another way, what things do you find most annoying on the system you use now, and how would you solve them if you were starting over?

Nightmare

On March 19, 1982, the West Coast Computer Faire will open at the San Francisco convention center. MSL has forked over $1200 for a booth at the show, and at the moment our only plans are to have an Interact system there. It would be very nice to show some MSP products at the show, complete with glossy brochures. Any ideas? At this point, I'm perfectly willing to cobble up things that look like products, which we'll clearly indicate are not ready for release. Remember that this is one of the major contacts between sellers and buyers and the only one in the Bay area. If you have any ideas, give me a call and we'll get cracking on it. There's only about 30 days left.

What's going on

At the moment, we're in the process of consulting with various people with experience in start-ups of this nature, and trying to line up marketing people. In a week or so we should know a lot more about what we can and can't do from the legal standpoint, and we'll try to put together a tentative charter which we'll send to you as soon as it's ready.

We're doing some market research, talking to people involved with Selector and other products to find out what their experience has been in this market. We're studying various desktop machines and thinking about how we can get the maximum development capability for our hardware dollar.

I think that progress is being made on all fronts, and at this point things look very good indeed.