|
|
The Working Paper was the document which resulted in the formation of Autodesk. I wrote it at a time when it was clear that Marinchip Systems, the company that I had started in 1977, and which Dan Drake and I had operated since 1980, did not have a bright future. In an attempt to find markets for Marinchip's software, we had been talking to the OEM division of Lifeboat Associates. It was on a trip with Lifeboat to computer companies in the Los Angeles area in December of 1981 that I first formed the idea of starting a software-only company to provide software for the coming tidal wave of small computers from large manufacturers. This working paper was written in 48 hours, after weeks of thinking about what to do. This paper served as the introduction of the concept and the invitation to the meeting to organise the company.
This document is a working paper which sets out the background,
general business plan, and strategy of Marin Software Partners
(MSP), a new company to be formed by some of those who read this
paper. The major goal of Marin Software Partners will be to
develop and market software packages, primarily application but
also system, for popular mass-market computer systems, including,
but not limited to, CP/M, IBM 8086 DOS, and Unix System III.
Marinchip Systems and many of those associated with it in various capacities have discovered that while it is possible to earn a reasonable living attempting to be a full-service computer company through the massive exertion of effort and consumption of physical capital, it is not possible to achieve the success that has accrued to those who let the mass market do their selling for them. The possessor of a unique software package such as Visi-Calc or Wordstar finds that much of the promotion of the package is done by the hardware vendor or systems house who wants to sell a system by providing the capability the package offers.
It is far too late in the game for a successful start-up of a full service computer company without massive venture capital and an organization which none of us knows how to manage. Furthermore, the chances of success against those with literally unlimited advertising budgets and marketing organizations (IBM, NEC, etc.) are very slim. However, the software business is very different. First of all, a software package can be produced out of pure effort, with only the capital needed to finance the machine and pay the programmer. Unlike hardware, the big vendors of mass market machines are mostly utterly ignorant regarding software, and software manufacturing is as easy as copying discs. In addition, independent software marketing channels such as Lifeboat Associates exist and are working in cooperation with major hardware vendors (Xerox, HP, Altos) to sell application software to purchasers of hardware systems.
I feel that at the present time it is possible to, albeit with high risk, start a software firm with the capital available from Marinchip Systems, and that this is the best possible deployment of that capital. No conceivable investment in the business of Marinchip has the probability of generating a comparable return. Unlike the hardware business, MSP will be in the middle tier of companies in its business, and will likely be in the front rank based on competence and professionalism.
The game has changed. In 1977 this business was fun—the sellers and buyers were hotshot techies like ourselves, everybody spoke the same language and knew what was going on, and technical excellence was recognised and rewarded. Today, the microcomputer industry is run by middle manager types who know far more about P/L statements than they do RAM organization. They are the people who determine whether you succeed or fail, and their evaluations are seldom based on technical qualities. Hence, the first thing any venture in this field has to be is businesslike.
What this means is that, first of all, any person who is unwilling to assign this venture a priority equal to or above his current employment does not belong in MSP. That doesn't mean you have to quit your job to join MSP. What it does mean is that if you say you agree to a certain share, then you will deliver that share week after week, month after month, year after year regardless of other commitments except in the case of total catastrophe which would cause you to equally neglect any other job you have. In working with people associated with Marinchip, the following conversation has occurred more than once:
“When will it be done?”
“Well, I don't know.”
“Why not?”
“Well, I know I told you it would be done by now, but a lot of
stuff came up at work and I…”
“Isn't this work? Don't you get paid for it?”
If you view your work with microcomputers as a hobby, if you look on the microcomputer business as a way to write off your home computer on your taxes or mollify your spouse about the money you spend on computers, if you're looking for a supplementary income to pay for a disc drive or outboard motor or whatever, you do not belong in MSP. MSP will be composed exclusively of people who intend to develop quality products, aggressively market them, and reap rewards far greater than those available from their current employment. We don't expect most people to start on a full-time basis; in fact, we're deliberately organizing the company to provide full time support services to moonlighting implementors, but if we're successful, we expect those involved to increase their commitment as the business grows.
If you feel, as I do, that a competent software person with the marketing connections to decide what to do and how to sell it is in the best possible position today to become very wealthy, then you belong in MSP.
Marinchip Systems has developed and is expanding a business relationship with Lifeboat Associates of New York City. Lifeboat is probably the largest independent software vendor in the world today, and is the primary source for application software for almost all the mass market computers sold currently. Through technical review of Marinchip products and presentations to Lifeboat customers, conversations with Lifeboat personnel, and negotiation of a very complex OEM agreement, Marinchip has come to be seen by Lifeboat as a competent organization in both the business and technical senses.
Lifeboat has expressed an interest in working with Marinchip to develop Marinchip products to be marketed through Lifeboat, particularly a QBASIC compiler for the 8086 (IBM) and Z-80 processors. Additionally, our contacts with Lifeboat give us the ability to sound out market demand for various packages, get tips on what people are asking for and not able to find, and also contacts with OEMs who want specialized work done.
Clearly then, one of the first tasks of MSP after formation will be to meet with Lifeboat and explain our business plan to them and get feedback and suggestions. I think that we already have the credibility to get work funneled our way by Lifeboat, and in any case the contacts are invaluable for market research.
MSP will concentrate on development of specific products with clearly defined functions. We will not attempt to implement grandiose systems and will not stray too far into the systems programming arena. Any program we develop must require little or no customization for installation, and little or no user consultation after sale. Otherwise, we can't afford to sell it. We're aiming for packages like Visi-Calc, Selector, Supersort, Wordstar, etc.
MSP must budget a substantial percentage of its capital for advertising and promotion. Undoubtedly, some packages will be largely marketed for us, but we cannot assume this and must realize that a market must first be created through advertising before it can be sold to.
MSP will be organized as a partnership. The general partner will be Marinchip Systems Ltd. (MSL), and the limited partners will be all the individuals associated with the company. Using this form of organization provides the limited partners the limited liability of a corporation without the disadvantages of double taxation of earnings, the risk of royalty income causing the corporation to be construed as a “Personal Holding Company” subject to 70% punitive tax, and the general hassles of operating a corporation.
MSL, as general partner, will be responsible for the day-to-day operation of the company. It will provide the following services:
Phone answering, order taking, shipping and receiving, copying.
Accounting, banking, billing, A/R maintenance, preparation of reports to partners.
Contact and negotiation with Lifeboat and other distribution channels, ad agency interface and copy preparation, ad placement, trade show exhibition. Market research and potential product evaluation.
Central message dispatching between partners. Monitoring of project schedules and reminders of delivery dates. Follow-up of customer complaints and suggestions.
Manual printing, disc copying, inventory maintenance.
Limited partners will be responsible for the following:
Design, implementation, and documentation of new products.
Correction of reported problems, adapting existing products to new hardware/software systems, installation of new features, revision of documentation.
Pre-sale evaluation of products developed by other partners, preparation of critiques and problem reports for those products, interface with other partners in correcting those problems. Evaluation of competitive products from other manufacturers, preparation of reports on those products and selection of features and capabilities for incorporation in our own products.
Review of new product announcements, news items, advertising, and product demonstrations with an eye to potential new markets, competition, and opportunities. Preparation of summaries of important items for distribution to other partners.
Preparation of new product announcements, skeleton ad copy, and product brochure copy. Attendance at shows and at meetings with customers. Telephone consultation with important customers and potential customers.
Participation in regular partnership meetings. Assistance in evaluation of partnership goals and new product selection. Technical assistance to other partners in areas of specialization.
MSP is intended to be a “tightly coupled” business venture. It is not a front for marketing individual products and funneling royalties back to implementors. It is a partnership where partnership profits are distributed to partners based on their percentage ownership regardless of their source. Why? First of all, one of the major reasons to form a partnership rather than just going off on your own is the potential synergy of the various partners and the work they develop. We hope to offer software components which can be used together in meaningful ways, and as we go, to accumulate a “bag of tricks” (e.g. screen formatting routines, database access utilities, etc.) which make development of new products by all partners easier. If each partner were essentially on his own, we could easily spend more time figuring out cross licensing and royalties for shared components than in actual development. It would force any partner to evaluate, for each potential component used, the tradeoff of paying for it or doing it over. This is silly and counterproductive.
Secondly, it enables us to cut the risk to each partner while remaining able to swing our resources behind those products which “take off”. Assume we develop five products and four are losers or barely break even but one becomes the “next Visi-Calc”. In the “royalty payback” company we would have four unhappy implementors and one fellow with a rapidly increasing bank balance but the inability to adequately follow up the initial product with follow-on enhancements and adaptations. With the true partnership, we can commit our resources to a successful product as its success requires so that we can not only make a splash with it, but aggressively follow up the initial success with the new versions, new machine implementations, and additional features needed to expand and preserve market share.
I view the difference between the lone wolf implementor and the software marketing partnership as the difference between gambling and business. The lone wolf has the possibility of a higher return, but far less probability of realizing it. What matters in business is to be able to fail a large percentage of the time and still come out ahead. Having had several blockbuster products and having watched them diddled away by insufficient promotion and inability to concentrate resources on them as they showed promise convinces me of the truth of this statement.
Once MSP commences operations, we will select a set of products to develop and formulate, in advance, a development schedule, marketing plan, marketing budget, and cash flow projection per product. MSP accounting will be structured so as to produce actual figures on a monthly basis which update the projection. We will have partnership meetings on a monthly basis (or more frequently) in which each active project is reviewed from a technical and marketing standpoint and a decision will be made to continue, drop, or increase commitment to the project. Each new product we choose to undertake will be formulated and managed this way, so we are constantly forced to target the very limited resources we have on the segments of our business which are developing well.
Partners in MSP will prosper as the company as a whole does. This may help them to better evaluate products and projects based on their actual prospects rather than an attachment to something based on the amount of work that has gone into it or an attraction to an idea because it seems good. Our goal is to be able to react rapidly when a product takes off and build other products around it.
It doesn't take a lengthy look at the computer industry to
conclude that the products that succeed are not always the best
ones. Arguing with the marketplace may make you feel good, but
it's about as productive as standing on the tracks and arguing
with the Twentieth Century Limited. One of our chief goals in
structuring the company is to promote rapid feedback of real-world
information into the decision making process. I know how
important this is—any reasonably dispassionate analysis of
Marinchip's business would have concluded as early as 1979 that
the 9900 was a dead end. Yet the seductive lure of the “previous
investment trap![[Footnote]](i/footnote.png){kind=small}
”
was such that two more years of effort were
poured down a hole whose prospects of return were very limited.
That's not to say that having long term goals isn't important or that you should have no time horizon beyond the next month. There's nothing wrong with a slowly developing business with a large prospect of deferred return as long as it doesn't bleed your resources and result in your going under just when the world realizes that it needs what you've been selling for the last five years. What we have to guard against is blindness to a competitive idea (for example, screen-oriented word processors) which is sewing up the market while we still try to push something time has left behind.
The business of MSP will be structured around products. Each product will be clearly defined and a written plan will exist for each product. At any given time, it will be possible to list all the active products and review their performance.
Each product will follow a well-defined life cycle. It begins when somebody decides that something looks like a good potential product. This is briefly written up and then discussed at the next planning meeting. If the product looks like it might be worth doing, one or more partners undertake the preparation of a development plan. The development plan spells out the specifications for the final product (at the level of detail a brochure might offer), lists potential competitive products and why ours would be better for the potential purchaser, and estimates the time and other resources which would be required for development. If after reviewing this plan the product still looks good, we sound out potential marketing channels and supplement the plan with projections for marketing cost and sales. The final plan is subject to approval by the partnership before development is started. Once development is authorized, the project goes into the implementation phase.
During the implementation phase, the partner or partners responsible for the project write and test the code and prepare the user manual. Those responsible should be left alone as much as possible during this phase. Only a devastating competitive announcement should be reason to reopen the project for consideration while implementation is underway. As long as it is on schedule, the project is of little concern to the other partners. Once an initial version is completed, including documentation, the project moves to the evaluation phase.
In the evaluation phase, a completed user copy of the package is given to a partner who has little knowledge of its internals and is in a good position to evaluate the package from a user standpoint. That partner's critique of the package as well as bug reports from the initial testing are used to refine the package so that the first release meets the highest professional standards. Remember, outfits like Lifeboat evaluate a package based on their customers' first impression of it. A rough first release can doom the package's prospects. While this evaluation is going on, the manual is edited into final camera ready form, advertising copy is prepared, and product brochures and other promotional material are prepared and printed. When the package has been shaken down to the extent that all are happy with it, it moves to the initial marketing phase.
In the initial marketing phase, manuals are printed so that orders can be filled immediately. New product announcements are sent to all trade publications and advertisements are placed as specified in the plan. Marketing channels (e.g. Lifeboat, etc.) are contacted and provided with sample copies, presentations, and/or demonstrations of the package. If trade journal articles have been prepared about the package, they should be timed to appear during this time. We want to have the maximum impact possible with the introduction of the package to prompt people to try it. After they try it, we hope the package will sell itself on its merits. This is the phase in which the largest negative cash flow will be experienced, and the project will be constantly reviewed against the plan to make sure it is within the budget. As orders begin to come in, the negative cash flow begins to turn positive and to pay back the initial marketing debt. As this happens, the project moves to the marketing follow-up phase.
In the marketing follow-up phase, we find out how well we've done. The project is reviewed based on:
and based on those considerations, we decide how to treat the package. We want to be as responsive to bug reports as possible, and to regularly release updates and enhancements. We want the user to feel that the package is “alive”, not a take it or leave it item. Also, we develop a profitable aftermarket in updates among those already committed to the package. As long as a project is still active, we budget funds for advertising and other marketing, and our goal is to pyramid the success of products which sell well. This means (and this is critical) that our first priority is support, enhancement, and promotion of those products which are doing well. We don't know in advance which of our products that (or those) will be—we have to let the market tell us, but we have to listen and respond to the market's message. Marinchip's greatest failure was to develop a product and then not follow it up because another attractive development project was dreamed up. We cannot let that happen here.
Optimally, the success of one or two of our products will lead to natural follow-on projects (as Wordstar led to Mailmerge, Spellstar, etc.), which build on the sales of the original product (to start with, users of our first product are very likely to buy the add-on). That way we can let the market lead us into the area of business we do best in. We should review new product proposals in the light of our existing products, to see whether they complement them. Not that we shouldn't enter new lines of business, but those companies that have succeeded have done so by concentration, not by breadth of product line.
If a product fails to meet its sales plan, then in the follow-up we will review its performance and the reasons for its failure. Based on this review, we may decide to terminate the project or to remedy the product based on market response or to modify the promotion campaign based on reactions received. However, we must avoid throwing good money after bad, and we should expect a majority of products to fail and their projects to be terminated. That's why we establish an advertising budget in advance and stick to it. Only exceptional and well documented changes in the marketing environment should cause us to decide to increase our potential loss on an unsuccessful project.
Obviously the time scale of all of this will depend on the magnitude of the product undertaken. It's conceivable that a little CP/M utility might go from concept to follow-up in 2 months (although advertising lead times would limit the impact of advertising until later). Given the resources we have, I don't think we should undertake any project where the follow-up comes any later than 9 months after the project is first defined. We just aren't rich enough to piss away our resources for longer than that on a potential loser. If we decide that we want to do a massive system with lots of parts, let's do it in pieces that are individually salable. Then we not only get user feedback to guide our future development, that development is paid for from sales revenues, not from our pockets.
Capital for the formation of MSP will be contributed by the general partner (MSL) and the limited partners. Partnership interests will be calculated based on the percentage of capital contributed to the initial capitalization of the venture. The law requires the following:
Limited partners cannot purchase their partnership interests through
contribution of services [Dible P. 180], but must
contribute tangible assets. Management and operation of the company
is solely the responsibility of the general partner (MSL).
Violation of these rules either invalidates a partner's ownership
share or exposes the limited partners to potentially unlimited risk in
case of failure of the business, lawsuit, etc.
We do not want to select potential partners in this venture based on their bank balances, but rather their competence, willingness to work, and entrepreneurial orientation. However, we don't want to give away partnership interests or make participation a no-risk venture for any partner. The owners of MSL are basically risking everything they've made for the last 5 years on this venture; the amount of money we intend to contribute would let us lie on the beach for a long time, and we intend to make a lot more than we contributed to compensate us for the risk, the work, and the hard times ahead. We want to know that our partners in this venture have a stake in its success at least proportional to their ownership of the company.
The following plan is suggested for initial capitalization of the company: we will calculate the desired capitalization and the partnership shares of all partners. As noted above, partnership shares will be in direct proportion to contributions. Partners may purchase their shares either in cash, by a no-interest loan from MSL secured by equipment, or by a regular market-rate callable loan from MSL.
Here's how it works. Suppose a partner wants to buy in for $5000. The simplest thing is just to pay the $5000 in cash. Alternatively, since many partners will want to purchase machines for software development or already own them, they may use the money to buy a machine (getting the tax credit and depreciation benefits, which are incredibly attractive today), then pledge that machine as security on a zero-interest loan from MSL. Or, MSL can loan the partner the money on a regular unsecured loan at market interest rates, and that money can be used to buy a partnership share in the normal way. At, say, 20% you can “rent” $5000 for $1000 per year.
The idea of all this is that we recognize that a substantial portion of the initial capitalization is going to be used to buy machines for software development. Those partners who already own machines should not be forced to subsidize those who haven't, nor should those partners who obtain machines for MSP work be forced to forgo the tax benefits of buying the machine themselves. By loaning at no interest against the machine, we're allowing machine investments to be applied to partnership share dollar for dollar.
On all of these loans, it will be part of the agreement that revenues from a partner will first be applied to retiring any debts to MSL, and only then will the partner be paid directly.
Note that none of the above has been reviewed in detail for possible adverse tax consequences (in particular “imputed interest”) and it's possible that there may be some more tax-attractive way to go at this involving leasing. Externally, this venture looks very much like a tax shelter, so the tax ground is very carefully covered and one must tread with caution in possibly questionable areas.
It should be clear that if MSL loans a partner the money to buy in, that loan should have an equal position in the recipient's mind with a home mortgage or auto loan. It is a real loan of real dollars which could have otherwise been spent by the principals of MSL on themselves. It is not “funny money” or a paper accounting transaction, and he who receives it should expect to pay it back, hopefully from revenues of the products MSP sells, but from other sources in the event MSP fails. Not only is this a realistic representation of what's really going on, it will hopefully inspire in all partners the kind of seriousness about this venture with which MSL approaches it.
If MSP fails, I will lose everything I've made for all the work I've done since 1977. I want partners who are willing to work as hard for success as I am.
Legally, limited partners have no say in the operation of the business. It is our intent that the business will be run as any other partnership based on partnership interests. Since I expect MSL to hold a controlling interest, this will probably make no practical difference. I believe that the people involved in this venture should be compatible enough that consensus will govern most actions taken by the partnership. This business can succeed only if all partners work to make it succeed. Since MSL has the most to lose, MSL has every reason to avoid contention and unhappiness among the rest of the partners.
Partners should join the venture based on their ability to participate in it. We are not looking for investor partners who will not be involved in the operation of the company and its projects (although if one should stumble in, we'd be glad to talk). The principals of MSL are devoting their full time to this venture, limited only by ongoing commitments to MSL customers and prior consulting arrangements. Potential partners must decide for themselves how much time they have to devote to MSP. The basic quantity you should try to calculate is hours per week. We need an ongoing, reliable commitment of time by all participants. Whether you work two hours per day or in one fourteen-hour mad gonzo session each Saturday does not matter. If you have a job, however, which may randomly require your full absorption for a week at a time and leave you with stretches of idle time at random, that employment is not compatible with MSP partnership. We must be able to quote schedules and meet them, and we must be able to coordinate work from several implementors into final products. I know from experience that this cannot be done unless reliable time commitments are made.
The basic time commitments that participation in MSP entails boil down to the following three categories. First, the basic time devoted to company work which can be scheduled as you see fit. The time you have available for this work is the factor that determines the extent of your participation in the company. Second, each partner should be available for telephone conversation at some time during business hours on a daily basis. This is required for coordination of projects, passing on bug reports, or response to customer questions. If you can be reached at work, say, in the afternoons, that's all that's required. At an absolute crisis maximum, this would represent 15 minutes per day. Normally, one call per week would suffice. This refers to calls between headquarters and partners only, of course. If you're collaborating with another partner on a project, that time would be counted in the first category. Third, each partner should budget the time to attend partnership review meetings. These meetings will initially be held monthly on a regular schedule so that you can plan around them. We will alternate meetings among the various geographic areas where partners reside. If MSP includes partners not in the San Francisco area, we will make cassette tapes of the meetings available to those partners and accept written project summaries from them. This is not an attractive option, and remote partners should plan to increase the time for telephone consultation as a result.
Remember, this industry is now at a point where virtually all our competitors are ongoing operations with full-time technical employees. We're going up against them with less capital, a distributed operation, and less personal and financial commitment from the majority of our participants. We may very well fail. If we succeed (and I wouldn't be getting into this unless the odds looked good to me) it will be because we know more about what we're doing than most of them technically (this I know for sure), because a partner always out-produces an employee, and because we have and will develop the contacts to aid us in product definition and marketing. But we're going to have to think lean and hungry for quite a while and target our products with precision. And most of all, we have to look, we have to be, a serious business venture, which we only marginally are. Most of the people who've succeeded in this game are those who sold their houses, quit their jobs, borrowed every penny they could scrape up, hired 5 or 10 people and hung their balls out over the abyss hoping their product would make it and bail them out. Making it while risking less is very very hard. I do not want to minimize this, but I want to point out that the risks in getting involved in MSP are probably less than any other serious business opportunity you're likely to find with anything like the potential return if it works.
I think we have a chance of making it with less than full-time commitments from partners only if their time commitments are utterly reliable. We're going to have to try to turn multiple part time people into the illusion of a full time staff so we can react to the market and bring out products as good as our competition and faster. That ain't easy. The people we're contacting as potential partners are the best computer people I know of in this country today, and are far better in both knowledge and productivity than the staff of most microcomputer software houses. That is what makes this possible at all.
I view the products that MSP will develop as falling into several distinct classes:
The first I call “guerrilla programming”. This consists of developing relatively small, quickly implemented products which fill an immediate need perceived by users of a heavily promoted product. For example, a 3270-type screen oriented data entry package which generates SELECTOR files would be such a product. Every existing SELECTOR customer would be a prospect for our package, and systems houses who implemented applications in SELECTOR would use our package and sell it for us to their customers. A systems programming example of guerrilla programming would be a super-reliable file recovery program for CP/M. Again, every CP/M user would be a prospect for this utility. These kinds of programs tend to be quickly developed, sell fast, but don't last long as often the vendor you're tagging along with brings out a new release with your feature in it. However, they do make money and you can afford to do a lot of them since they don't take long to write. You can hit it big with one of these if, say, the vendor picks up your package and starts promoting it. This is not likely, and no project should count on this.
The second is the closed system application. This is a stand-alone application package which performs a well defined function for a specific class of users. Visi-Calc is a superb example of such an application. If you hit on one that's widely needed and not currently in a tolerable form on a micro you can do very well with these. Market research is essential here, and looking at what people are paying to do on timesharing systems is a good place to start. The “card file” very simple database is something we might do in this arena.
The third is the software tool. This is a utility program which is applicable to a wide variety of users for different purposes. Examples are SELECTOR and other database systems, word processing programs, and sort packages. This is a highly competitive market where large advertising budgets predominate and thus hard to break into. However, the rewards are great. We should look at somewhat “kinky” tools that haven't penetrated the micro market far but which have been popular on other systems. SSG and a SCCS-type facility are two that pop into my mind.
Fourth is the “interface gadget”. We all do this well and they sell very well in the micro market. For example, a 3780 emulator, a CP/M to IBM disc convert utility, and so on. The problem is not being hardware dependent, and that's difficult in this game.
These categories overlap to some extent, but I think you get the drift of the kinds of things I'm thinking about. A good rule of thumb is that anything we do should fill a need the potential customer already knows he has, or should be demonstrated to a prospect in 5 minutes or less. We don't have the resources to educate the user base or to change the world. Products for which we can prepare a “demo disc” for computer stores are particularly attractive. We can give away a demo disc, then when a prospect walks into a store, they can run the disc which sells the package.
At this moment, the best established machine base for programs is the CP/M marketplace. There are about 500,000 machines installed which can run CP/M programs in one form or another, and the importance of this marketplace is underlined by the fact that most serious applications for the Apple now require the “softcard” with on-board Z-80 and CP/M.
However, the industry is changing rapidly and at this instant it appears that Unix or one of its look-alikes may become the “software bus” on 16 bit processors. We can't afford to bet on one system to the exclusion of all others. Fortunately, most of the potential products we're able to undertake don't require us to make a bet. We will be doing all of our programming in high level languages, and we must choose languages available on all of our potential target machines. At this date, C and Pascal meet this requirement.
We should seriously evaluate the option of going with CBASIC as our standard language and developing QBASIC implementations on the newer machines. The advantage of CBASIC (CB80 compiler) is that our work is file-compatible with a very large set of existing applications on CP/M, and with the acquisition of CBASIC by Digital Research (CP/M's developer), the connection is likely to strengthen.
On the other hand, the Microsoft-Unix/Xenix-IBM connection is a potent one, not to be ignored. I don't think we should be too bogged down by all of this, though. Whatever we program something in is going to generate object code that we distribute, and we're only going to program things which can be sold to a large number of customers without modification. If we do things reasonably, we'll be able to convert them to anything else that comes along and looks attractive. After all, conversions aren't fun, but if by converting something from CBASIC to Microsoft BASIC I can sell another 100,000 copies, I'll convert it. We shouldn't spend our time trying to figure out how many SIGPLAN Notices can dance on the head of a bit when we could be defining products, implementing them, selling them, and getting rich.
If the tone of this paper so far has been to scare you away from this venture and to repetitively drum all the potential risks involved in joining such an operation, that's exactly what I intended. I've tried to lay out the whole operation complete with all the potential problems as straight as I can. So why would anybody in his right mind get involved in such a nutty venture?
The reason is very simple: there's a reasonable chance of making money beyond the wildest dream of an employee in this industry. Products like Wordstar are selling in the $10–20 million per year range today. Bear in mind—this is a product that any of us could write in about two months. We should consider ourselves extremely lucky to be in this business at this time in history. It's a rare piece of luck to have the field you've chosen as your career explode into the hottest growing entrepreneurial arena just as you hit your prime, and we're now at the point that if we want a chance to get involved we have to act immediately. The game has changed and the pace is accelerating very rapidly. The venture capital that remade the micro hardware business 2 years ago is just now beginning to move into the software business: within the last 3 months, Digital Research, Microsoft, Micro-Pro, and Lifeboat have received infusions of venture capital in the $1–10 million range. This business is getting very big and very professional, and within one year the chances of success of a tiny, heavily technically oriented company will be nil. If we move now, if we move fast, and if we react extremely rapidly and work ourselves to the bone, we can grab a chunk of this business before it slips away. We have to pursue our contacts at Lifeboat because that's an open door far too priceless to ignore, and we have to have a credible organization to open that door to further work.
If we sit back and say, “Well, I'll see how well the IBM makes out”, or “Maybe after I pay off my car”, or whatever, we'll lose a chance that won't come by again in our lifetimes. I think that with what we've learned from Marinchip and from the industry, that with the marketing contacts we have, with the product ideas we're kicking around, and with the competence of the people we know, we have a real enough chance to make it that it's worth betting everything on. But we have to have real commitment, real performance, real responsibility, and real professionalism to make it. If you're interested in making that kind of commitment, I can't guarantee that we'll succeed, but I can guarantee that together we'll have a once in a lifetime experience as we try.
What it all comes down to is the following questions, which only you can answer for yourself.
Do I really want to be in business for myself?
Do I want to work with these people?
Will I enjoy it if I participate in this?
Am I likely to find a better opportunity elsewhere?
Am I likely to find a better opportunity later on?
Can I manage the risk, and does the potential reward justify it?
I think that this is it.
I have not discussed any of the specific details of the venture in this paper, such as the amount of money to capitalize the company, how much each limited partner would be expected to chip in, etc. Nor have I gone into specifics about the precise organization of the company or who does what. This just isn't possible yet; I have no idea who is really interested in it. You build an organization out of the people you have, you don't try to ram people into predefined slots.
We want to start a venture which in three years will be one of the top five names in the microcomputer software business. We're crazy to aim lower or limit our sights. We're at a point where substantial market segments haven't been addressed yet and by moving fast we can grab a market share and make our company grow from generated revenues (note that all the software houses who've brought in venture capital had basically saturated their initial market first). At the point where we have to make that decision, we can be consoled by the fact that we'll already be millionaires.
I can think of no business (well, legal business) where we can start-up with so little capital or downside risk. If this business looks too shaky to you, where do you expect to find a better deal? I cannot imagine any scenario other than total collapse of society in which the sales of microcomputer application software will not grow by a factor of 10 in the next five years. The big vendors of small machines have not only not entered the software business, they appear totally in awe of it and willing to grab any product and promote it to sell their machines.
The first thing to do is to show up at our organization meeting at MSL on January 30, 1982. You should give some thought to the points raised in this paper about commitment of time, and should also be able to give an idea of how much money you'd be willing to risk on this venture (whether you have it or not). Also, we'd like an idea of what kinds of work you'd like to concentrate on, and any ideas you have for products we might get into. In particular, if there are any items in this paper that are “show stoppers” for you or with which you take violent exception, that's the time to bring 'em up and hammer them out. At the end of that meeting, which will probably be very long and detailed, I hope that those who are interested in proceeding know who they are. Then we'll start putting numbers on paper and see what we're getting into.
We should shoot for having the company in operation by mid-March. We cannot dawdle, but we also are going to do it right this time. We're just going to do it fast!
Agenda for January 30, 1982 Meeting
This drawing, originally done on M9900 INTERACT, was the first architectural drawing ever used with AutoCAD. It was shown at the introduction of AutoCAD at COMDEX in 1982.
|
|