Sad story.

You had a fantastic opportunity, bigger than the opportunity
that got L. Ellison a 450 foot yacht.

From 90,000 feet, the “failure” was when the company failed to
take the opportunity. Somehow the company extracted defeat
from the jaws of victory.

For just those years, it was plenty clear — from the years of
struggle with the beginnings of ‘data base’, from the
struggles with both ‘hierarchical’ and ‘network’ data base
systems, from the IBM R* and DB2 (Blasgen, etc.) work, the
Berkeley (Wong, Stonebreaker, etc.) work, etc. — that RDBMS,
with good tools, was one of the most important steps forward
for business ‘information technology’. It wasn’t a secret.
E.g., there are plenty of details in

Jeffrey D. Ullman, ‘Principles of Database Systems,
Second Edition’, ISBN 0-914894-36-6, Computer Science
Press, Rockville, MD, 1982.

Notice the publication date.

For the details of just why your company failed, you have the
background. What was it? Some people at the top of the
company were already rich enough and didn’t want more? The
COB didn’t have a wife who was thrilled that the kids were old
enough to park in school and eager to rush off 12 time zones
away to the tropics and give away billions to help the women
not have babies? Too many people were just satisfied that the
software worked and was so far ahead of what was in the market
for ’super-mini’ computers and didn’t insist on also building
a valuable company? People didn’t see the brilliant future of
RDBMS, especially on computers other than ‘mainframes’ and
driven by Moore’s law? People in the company didn’t want to
get rich? The sales people told the customers, “Our software
is enormously powerful and valuable and way ahead in the
super-mini world. If you can’t see that and benefit from it,
then the loss is yours. If you want to be a customer, then
give us a call, but don’t call on a Wednesday because that
would ruin two weekends.”

Had ITT as a good account? TERRIFIC! But in 1980 or so,
tough to find a company in the Fortune 1000 that didn’t have
numerous applications for your software. Basically a team of
people with good skills with your software should have been
able to call a company, give credentials, request an
opportunity to give a presentation, ask for a sample
application, study the application for a week, write the
applications software for two weeks using your RDBMS and
related tools, deliver the application, collect a check, offer
to run a training program for their in-house software staff,
collect more checks, make a RDBMS sale, grow the account, and
do well.

E.g., in about 1986, with VAX, DEC was getting more revenue,
month by month, from DuPont than IBM was with their
mainframes. IBM dominated the mainframe business at DuPont;
still, DEC was getting more revenue. Some of the reason was
that people in the DuPont laboratories that had been doing
scientific computing on VAXes were growing those applications
to production ‘business’ applications. One of the serious
bottlenecks in this growth was lack of good software tools for
business applications. You had one of the best of the missing
tools. Last time I looked at a map, Princeton and DuPont are
not so far apart. In fact, when we visited DuPont, we drove
right by Princeton.

E.g., in the late 1970s, FedEx needed a transaction processing
application for the items in inventory at the FedEx Memphis
hub ‘PartsBank’. Your RDBMS software tools were a really good
fast start toward a good application.

By 1981, Prime computer had really a somewhat nicer system for
business applications than the DEC VAX, but Prime very much
needed some good RDBMS software; they, and their customers,
needed JUST what you had. Similarly for DG.

Those were days when Cullinet, etc. were doing well: Your
RDBMS with its good tools should have done MUCH better.

Just then, Moore’s law was racing ahead. The Motorola 68000,
e.g., in Apollo and Sun, was a powerful product. Porting to
Apollo and Sun, and Unix generally, should have been a good
strategy.

You might have built some ’strategic alliances’ with some
companies that wanted to write applications for accounts
payable, accounts receivable, cash application, general
ledger, inventory control, ‘business analytics’, etc. on top
of an ‘integrated’ data base built with your RDBMS and tools.

You might have worked with ISVs to bridge from your products
to running powerful valuable specific applications for
specific customers. Around 1980, there were MANY such ISVs
racing to bring up basic on-line business applications, on
IBM, HP, DEC, DG, Prime, etc. ’super-mini’ hardware, and far
and away the one piece of ‘infrastructure’ or ‘middle-ware’
software those ISVs most needed was a good RDBMS with good
associated tools.

As I understand the start of Oracle, their first sales were
really just for some good ‘report writing’ and ‘business
analytics’. E.g., someone would have a reel of tape with
sales data in some simple format for the past six months and
want some ‘report’ tables and some ‘charts’. So, they could
read in the tape, and the Oracle software would help them get
the output. You had such tools and much, MUCH more. If you
needed a few more such tools, you could have written them,
too. If you needed some highly caffeinated hot shot highly
motivated sales people and a take no prisoners SVP Marketing,
so be it.

Heck, just writing solid software for disk-based balanced
multi-way branched trees is not so easy, not nearly as easy as
it looks in Knuth. Just that alone could be the basis for
some decent business success.

You had it all, on a platter in your lap. How’d you manage to
blow it? TELL US! What HAPPENED!

I was the 8th member of a Princeton based DBMS company. This is not the one that became CA. Our doors closed in 1992 after being founded in 1975 in the bowels of a defense research contractor.

We were the first DBMS to run on a mini-computer (which hads way less than a MIP at the time). We were the first to have “text” indices as a feature of the DBMS. We were the first with cross record B-tree indices except that our indices were T-Tree, based on a footnote in Knuth, where each index page split into threes not two’s. Do the math. We could index over a billion entries on less than one Mip machines, with expensive 32 or 54k core memories and washing machine size 260MB disk drives. We were the first to have an fully integrated (as distinct from a standalone attachment) report writer and full screen data input forms, a transaction processor protocol (on the mini) and have all of these features integrated fully into a data dictionary that used our own products DBMS as its base. In 1980, Stonebreaker of U Berkley and INGRES fame declared our product’s output tools “state of the art”.

Why do I crow so? Because, except for a short year in a half from 1980 to 1982, when we were the first and only product on the brand new DEC VAX and expanded to over 200 customers including some big banks, many government agencies and defense contractors, we were basically a blip on the DBMS screen.

We simply responded to our customers and researched the answers and always thought “easy”, “integrated” and “consistent”. But, in 1984, when Oracle was still struggling to create a non-integrated data input and report generator that had no “data discitonary” feature, we were already essentially a dead company, captive to ITT and a few other company who needed our most advanced features, and living on our laurels. I had long since departed to the Pharmaceutical industry and it was not until Google and the Web tools that anything like what we had was available to all.

Bottom Line: We make too much of cutting edge technology. I used to exchange stock tips with my Family Physician. I would exchange Info Tech plays for his Biotech plays. We both found after about 9 months, that if we bought Info Tech stock when he heard of them and Biotech stocks when I heard of them, we both made allot more money than buying in line with our expertise.

Cutting edge technology and responding to customers only goes so far! A bit of caution, judgement, financing, timing and luck is also required.

So, when I recently gave a presentation on entrepreneurship to a group of MBA students here in Central Florida at Rollins College, I made a point of devoting at least 60% of my presentation to discussing my failed attempts, rather than highlighting and sugar coating my successes – as most speakers do

Also, I’m reading a book right now featuring different stories by various entrepreneurs on their failures called Do As I Say, Not As I Did!: Gaining Wisdom In Business Through The Mistakes Of Highly Successful People by Carol Frank.

It�s a very powerful book and features many �star� entrepreneurs revealing their shortcomings.

You can learn a heck of a lot more from other entrepreneur�s failures than their successes.

I recollect that a lot of the initial excitement was about playing with Macintoshes, not just about starting a company.

The J. Doob decomposition says that every real valued
stochastic process is the sum of a martingale part and a
predictable part.

The J. Doob martingale convergence theorem says that every
martingale is either ‘$L^1$ bounded’ in which case it
converges to some point or is not in which case it has to run
off to infinity.

You had J. Doob in mind when you started your company?