Pacestar Software: Early History


During my first full time software job I found myself involved with a team tasked with introducing object-oriented programming (C++) to a company in order to modernize their successful core products that were then based on assembly language. Part for that project was to re-design a new core technology involving real-time embedded call control. It required countless hours working with colleagues white-boarding designs. And in the process I devoted a lot of thought to how technology might be used to improve that kind of collaborative design process. Our design team naturally used a lot of ad hoc block-and-flow diagrams (shapes and arrows) to communicate and model ideas. A tool to help could be valuable.

Another responsibility I had was to learn C++ and object-oriented programming and help to introduce that technology to the team. I had gained some proficiency with the language due to other side projects, but I needed a project to get some deeper hands-on experience with the subtleties. As an exercise, and on my own time, I started work on a diagramming tool that would solve some of the problems I was running into at work. I called it EDGE for Engineering Design Graphic Editor. It was initially a DOS VGA app using one of the very first PC-based C++ compilers (Zortech).

A helpful supporter and an award

One of the senior hardware designers got wind of my tool and asked to use it for his board design. He encouraged me to continue to refine it and suggested it was as good as anything available commercially. I was cautiously proceeding down that road, but I was committed to my full time job and aware that a retail software product was a difficult commitment and I didn’t have the resources to sell it on my own anyway.

Then to my surprise I learned that my product had won an award! It was barely even a product, but my engineer friend had submitted it to a small industry magazine that did reviews of new products. For his efforts, my friend won $1000 for the submission. And I had the encouragement I needed to develop it further.


Ironically, this was the first and maybe last time the product was envisioned (and valued) for what it was really intended. But that’s getting ahead of myself.

In search of a market and distribution channel

There were two problems with my product vision. First, it was a new concept, or at least novel enough that there was no established market. That was a devastating problem, but admittedly could have been a great opportunity in the hands of someone more capable of getting help (investment). Second, it was a bit ahead of the time when a small self-published program could be sold online and reach a large number of users without the help of a major publisher.

No one understood the vision. I found that odd because I could go to the library, open up books from any field, technical or non-technical, and they were all loaded with block-and-flow diagrams. It was clearly a natural way for people to share concepts, communicate, and document everything. I compiled a folder six inches thick of diagrams photocopied from library books. I even estimated that almost a third of all diagrams that did not require a professional illustrator were some form of block and flow diagram!

Most software at the time was being sold on shelves in specialized stores like Egg Head for example. And those stores did not have shelves for diagramming tools. There were games, computer tools, spreadsheets, various word processors, databases, and so on. And no one wanted something that didn’t fit easily into an existing “shelf”. I’m overstating that, but this is the feedback I got from everyone I pitched it to.

Flowcharts – king of methodologies

Technical people like engineers and programmers did of course understand and value certain formalized diagramming methodologies, and many wanted tools to implement them. Unfortunately, such formalisms were contrary to my vision for the product. Those billions of diagrams in every book in the library were almost all ad-hoc. Almost everyone used block and flow diagrams in a special way, unique to their situation. Only rarely did they resort to a defined methodology such as flow charting or data flow diagramming or entity-relation diagramming. And even with those methodologies, there were no universal agreements on details, or even symbol sets. Some people might remember those plastic shape-drawing templates made popular by IBM that included circles and rectangles and triangles labeled with their intended usage such as process, input, output, display, or punched tape. That was the extent of standardization. But the term “flow charting” was well-understood. So it was the only viable market. There were companies that seemed to be succeeding by selling flow charting tools direct to businesses. They were very weak products compared to what I could produce, and they were very expensive. I decided I could hold my nose and adapt EDGE to EDGEFLOW as a simplified flow charting tool as a way to get my foot in the door.

That was a difficult compromise. As a software engineer, and one who prided myself being on the cutting edge of tools and techniques, and moreover productivity, the very term flow charting still held very negative historical baggage from the early days of programming. But it was also useful and widely popular for presentations and documentation. I could fight it and fail, or embrace it and nudge it toward it’s proper usage, hopefully succeeding along the way and gradually generalizing it into my vision for block and flow diagramming. The decision was clearly correct and my tools instantly started selling and making money.


The next great concession was finding a way to sell self-published software. My attempts to communicate the value of my vision and pitch the future value of the product space failed. I could give up or move forward with real strategies that were already in place and working.

In those days Shareware was a newer thing. Programmers could self-publish their software and distribute it widely with the help of the shareware infrastructure which at the time was a network of bulletin board systems and bundled CDs. Web sites were just starting.

But shareware had strict conditions at first. It was essentially what is now known as freeware and it was still meant to be for games and simple tools and non-commercial products. You were not permitted to use the shareware network or resources unless you adhered to those principles. I definitely did not want to give anything away when inferior competing products were selling for $1000 or more. My vision was to use shareware as a distribution method for a free fully functional trial version that expired after 30 days (try-before-you-buy). It sounds obvious now, but it met a lot of resistance at the time. Timed trials were forbidden, as were diminished functionality versions (a.k.a. crippleware), and versions that begged for payment (a.k.a. nagware). Any attempt to solicit purchase was considered contrary to the shareware vision and the model had not evolved to make room for small businesses. The Association of Shareware Professionals initially rejected my product because it had time limits. It took over a year before they allowed this new monetized form of Shareware. I felt like a pioneer, but it was an idea whose time had come.

Attempts to penetrate existing sales channels

Shareware was an easy way to get my products to customers, but it was not the way to start a business.

There were similar products (very poor ones) made for flow charting and data flow diagramming. To re-iterate, flow charting was once long long ago and very briefly (IMO) considered part of the computer programming process, at least part of the learning process. So there was a market for tools to help do this. It was appalling to me that anyone thought of flow charting as anything more than a way to document a process. But it WAS an application for block-and-flow diagramming, and there was money to be made. I held my nose and adapted my product to the flow charting market. I would adapt it to flow charting with the idea of generalizing it to other design methodologies later.

Successful software products in those days were sold through publishers and established distribution channels. Business products were sold directly to businesses in person or by mail order. Consumer software was sold primarily in specialty brick-and-mortar stores, like Egghead stores in malls. It was before web-based sales and even before department stores carried software. As these limited software outlets began carrying small business products like spreadsheets, word processors, and desktop publishing apps, there was very little room for serious business productivity tools.

Flowchart products could be sold for $1000 or more per license, but I had no idea how to do it. I did know I had to have a big heavy shrink-wrapped box and an inch-thick user guide. Fortunately I had to ability to create those as well as a very high quality professional program.

I failed miserably at attracting any partners, investors, or even supporters… except for users, who all assumed I would be the next Microsoft based on their love for the product.

At one point I loaded the car up with 30 boxes and drove to Las Vegas. Somehow I had the idea that I would walk into Comdex, start handing out business cards and product samples and meeting people in the business. I’d get some partners, and talk to some salesmen, and they’d go back to their CEO’s and tell them about this great opportunity called Pacestar Software. OH BOY was that wrong! It was fun in hindsight, and I did have a great product. It was their loss.

Next I found a single local software store. I took five boxes into the store and met the owner. I explained truthfully that I had 5000 fanatic users who preferred my product over the product he carried on his shelf. He could sell mine for less AND keep 100% of the sale price ($199 if I recall). Then we could negotiate for more. They sold out in a month but I could never reach them again. Another naive dud of an attempt.

The future held hundreds of such attempts. They all should have worked! But almost all failed. There were a few successes as well that came in time (2000 copies sold to a textbook publisher, 100 sold to a prominent university, and some sales through mail-order houses). But basically nothing worked well other than shareware. Eventually, shareware faded out and a more robust and professional web-based try-before-you-buy model actually became viable. I’d failed at establishing a true commercial software company, but I have achieved sustainability and hundreds of thousands of satisfied users. A few small publishing deals and bundling agreements brought in some moderate but steady income, and I was getting occasional quality sales (site licenses in fortune 500 companies, major universities, government agencies, and so on).