Logos History
Sections: Company Timeline | Video Interviews | A Personal History of Processing Power
Company Timeline
December 1986
Bob Pritchett releases a simple program for quickly searching the KJV Bible in plain-text. Notes and letters from users nurture thoughts of a more powerful program.
May 1991
Bob Pritchett and Kiernon Reiniger, Microsoft employees who met at church, begin writing a Bible software product. Their initial goal is to create a "shareware" product for distribution on BBS systems (the dial-up pre-cursors to the Internet era). Early on the decision is made to build the product for the Microsoft Windows, instead of the still-dominant MS-DOS operating system.
June/July 1991
An early version of Logos Bible Software is shown to an existing Bible software company. The other company declines to distribute Logos because the future for Microsoft Windows is unclear.
August 1991
As early versions of the software are shown to testers interest increases. It becomes clear that a shareware business model won't support the license fees required in order to get access to the most popular modern Bible translation. Dale Pritchett (Bob's father, and at the time president of his own company) begins working to develop a sales strategy and pursue text licenses -- things Bob and Kiernon can't do while working for Microsoft during business hours.
December 1991
Logos Bible Software for Microsoft Windows v1.0 ships. Physical production is done on the kitchen table at Dale and Jenni Pritchett's house. Shipment is made to the first customers, who responded to an ad in Christian Computing Magazine.
January 1992
Bob, Kiernon, and Dale decide to "quit their day jobs". After raising a small amount of capital from friends and family they incorporate Logos Research Systems, Inc. Dale opens a sales and marketing office in Marlton, New Jersey, and in February Bob and Kiernon open a research and development office in Kirkland, Washington.
...
August 1995
Logos Bible Software v2.0 ships after an incredibly long and painful development process. Built on a brand new technology, the Logos Library System, the new release introduces the "library" concept to Bible software. The LLS is the first Bible software platform designed to supports hundreds of electronic books delivered, or unlocked, as separate products.
February 1998
An ever-growing list of new books for the Logos Library System begins to push the limits of the technology. A new plan is developed to build a third-generation platform that can handle 10,000+ electronic books and which is based on research in library science, information retrieval, and the emerging field of digital libraries. A one-year target is set for the first release.
August 2001
The first release of the Libronix Digital Library System is completed. The completely new, user-friendly release of Logos Bible Software Series X is an enormous success.
July 2003
The Biblical Languages Supplement is released with the Libronix DLS v2.0 code. Logos Bible Software moves to the top level of support for study in Greek, Hebrew, and other Biblical languages with new reference books, improved primary-texts, and an even stronger search engine.
Interviews with Bob Pritchett
The Logos Blog contains a number of video interviews with Bob Pritchett discussing the history (and future) of Logos:
A Personal History of Processing Power
"System Error 2 - Out of Memory" by Bob Pritchett
When I was eight years old my dad brought home our first computer. It didn’t have any software that I recall, but it had the BASIC programming language built-in, and my dad explained that you could program it do whatever you wanted.
This was the coolest thing – a machine you could program to do anything you wanted. All you had to do was tell it!
I quickly learned that while you could theoretically write a program to do anything there were a lot of practical obstacles. Every idea I had ran into some limitation. The machine didn’t have a big enough screen, couldn’t show colors, was too slow, didn’t have enough memory, etc.
Every programming project was an exercise in scaling the vision down to the limits of the technology.
The first Bible software program I ever saw was for the Apple IIe. It delivered the entire King James Bible with a simple search program. The only problem was that everything was in upper-case – another limitation of the technology.
Limited as it was, I was fascinated with the idea of Bible software. A few years later I found a plain-text copy of the KJV text (one book per file) on a computer bulletin board system. (Back when the Internet was the exclusive domain of universities and the government, BBS’s were how computer hobbyists exchanged messages and files.) I downloaded a few books and the accompanying search program and quickly found myself facing yet another technological limitation. With the speed of my dial-up connection it would take days to download all the books of the Bible. And once I had them downloaded the program that came with them could only search them slowly, using a "brute-force" algorithm that compared every character of every file for matches to my query.
I determined to write my own Bible search program, applying the best technology I could to the vision of fast and friendly Bible software. I used a very efficient algorithm that I found in a programming magazine to increase the speed and a toolkit of user interface components I’d previously written to make a friendlier interface.
My new program was faster and looked nicer than the one I’d downloaded, but it was still a very simple tool. It didn’t live up to my vision of a great Bible software package.
In the following years I kept looking for technology that would allow me to write a better Bible software program. I collected algorithms and articles and thought about ways to squeeze the large text of the Bible into limited memory. I wrestled with "speed versus space" tradeoffs and discussed the problem with other programmers.
In 1991 I found a partner who was interested in writing Logos Bible Software with me. For months we wrote code every night and weekend, breaking only for our day-jobs and to take meals together where we dreamed about all the great things our software would do someday.
Frequently I would visit a large technical library and look for ways to implement the features we were dreaming of. We devoured programming books and magazines and talked with other programmers, always looking for ways to push the technology envelope so that we could implement more of our ideas.
This need for new technology to implement our vision continued for years. As our programming project turned into a business our vision for the software grew. And as the vision expanded so did the search for new technological solutions that would enable us to deliver it.
In some cases the search was for new algorithms, in other cases we were simply waiting for desktop systems to catch up in speed so that the features we designed would perform at an acceptable speed. In one discouraging case we disabled a powerful new feature before we ever shipped it because it was just too big for then-current systems.
Starting Over Again
In early 1998 we outlined the plans for the Libronix Digital Library System – the biggest and boldest vision in our corporate history and a completely new platform for Logos Bible Software. Keeping only the capability of reading our existing electronic books we otherwise started over, designing a system of abstract interfaces to modular components that could, theoretically, be expanded to do almost anything.
Of course experience had taught me that compromises would have to be made. As beautiful as our abstract system was, there was no way it would actually run on the technology available to us and our users. From the beginning I knew we would have to hack-up the actual implementation with optimizations and "special case" code to stay within our limitations.
As we implemented the system, though, we were surprised to find that our computationally-expensive, large, abstract system was actually fitting quite well within our technology limits. During the development cycle we also upgraded our computers and software tools and found that the things we expected would be difficult or even impossible to do were getting easier every day. The ugly hacks we’d resigned ourselves to needing weren’t necessary. We never took the shortcuts we thought we’d take.
As we neared completion we started giving demonstrations of the system to people inside and outside the company. In the past this necessary step was always very frustrating. No matter how much input you solicit at the beginning of a project, when you’re almost done and users can actually see and test it they come up with all kinds of feature requests and ideas that simply can’t be done. The architecture is set in place, the code is almost complete, and there’s no way a major new feature can be added.
This round of testing began just like all the others. The programmers showed the product, the users asked for little fixes and big new ideas, and the programmers agreed to the little fixes and said no to all the big new ideas.
And then something different happened. The programmers thought about the big new ideas and realized that some of them could be done quite easily within our modular framework. So they tried a few, including the ones they were sure would run just too slow. But they weren’t hard to fit in. They didn’t run too slowly. They all worked.
Crossing the Line
The development of the Libronix DLS crossed a very special line – a line that I believe is being crossed in many technology product lines today. The line divides product development into two different eras. Before crossing the line the most difficult part of product development is fitting your vision within the limits of your technology. After crossing the line the most difficult part is expanding your vision to take advantage of all your technology.
In the early days of Logos Bible Software no product shipped with every feature we dreamed. Many of those dreamed of features were technically infeasible if not impossile to implement.
Almost every "blue-sky" feature dreamed of in the planning of the Libronix DLS was implemented, often with capabilities beyond our hopes.
In the case of those that were not implemented we’re confident that they could be and that they would work well. They are held back by marketing limitations or, more often, by a lack of specific vision for them. The feature was dreamed up at a time when we didn’t really believe it could be done, and we haven’t yet thought through the details of the user interface, the marketing, and the interaction with the rest of the system.
This doesn’t mean that every feature that’s been requested has been implemented, or even that everything runs as quickly as we’d like. It means that features are now constrained by time, money, or market circumstances, not technology, and that any speed issues will be addressed sooner by the relentless march of Moore’s Law (computer power-for-price doubles every eighteen months) than by a new algorithm.
New Challenges
In the past few years I’ve found that my reading, research, and conversations have changed. Instead of searching for new algorithms and acquiring new technology I’m looking for new ideas and new designs. I’m talking to fewer programmers and more customers. I’m focusing less on "how to do it" and more on "what to do."
I’m no longer shoehorning a simple or obvious vision into a small technology "box". Today I’m looking for a vision big enough to push the edges of the box.
The old joke at the end of an impressive technology demo was "But can it make coffee?" Today the answer is yes. The technology required to have Logos Bible Software make you a cup of coffee is inexpensive and easily implemented. The hard part now is to decide if it should and if so what the interface looks like.
I’m excited about crossing the line. I’m looking forward to building products that are more focused on user needs than technology limitations. I enjoy saying "Yes, we can do that."
We’re going to need help, though, to grow the vision, and to break out of the mindset of simple steps and incremental improvements. We’re going to need users to stop waiting to see what tools the technologists can provide and to start asking for the impossible. Because we’ve crossed the line and right now the impossible is possible.
Last Updated: 6/7/2007