The Story of Biblesoft (so far)

By Alan Conroy

I thought it important to write down a history of Biblesoft. I was employed there and am well acquainted with others who worked there before I started and after I left. My intent is not to write a "tell all" book in the style of Hollywood or Washington DC gossip columns. Rather than address personalities I want to provide a memoir that people will find interesting, informative, and perhaps educational. I started working at Biblesoft as a software developer in 1996, left to do a year of Y2K consulting, and then came back to Biblesoft as the Lead programmer. I left the company at the start of 2020. After 2000, the consulting company I was working for actually hired me back to Biblesoft for a time as a consultant. So I worked at Biblesoft for about 24 years. As a software engineer, I cannot comment too much on other aspects of the company. I could relate what other people told me, but I prefer to stick with what I am sure of from personal experience, or what has been confirmed to me from multiple sources.

At the center of the company was the founder, Jim Gilbertson. Jim retired from Boeing in 1988 to found Biblesoft using his retirement funds. Now Jim wasn't the best programmer I've ever encountered, but he was more than adequate for the task he undertook. He single handedly wrote PC Study Bible for MSDOS. He used Turbo Pascal, along with some package that allowed him to create a "windowed" application that ran on DOS. To the best of my knowledge, this was the first commercial Bible study app on the market. It was a hit and the company grew enough for Jim to hire additional programmers, sales people, support staff, and rent out office space in Des Moines, Washington.

Along the way, it was necessary to sign licensing agreements with some publishers for works not in the public domain. In these early days of electronic publishing, there were no standard license agreements, and often the publishers couldn't provide their works in electronic form. For these, and for public domain works, the company had to convert printed works into electronic form. For large works, this was labor-intensive, requiring scanning, proofing, and then processing for use in the program. The internal format of reference works used by PC Study Bible was customized for each work. Jim wrote a custom program to convert each reference work into the internal format, then updated the program to handle the unique characteristics of each work. This made Jim the bottleneck for adding new works to the program.

Some time later, Microsoft released Windows. Despite the urging of his programming staff, Jim refused to provide a Windows version of PC Study Bible. Apparently, he considered Windows to be "snake oil". This misjudgment left a door open for someone else to provide a Bible app that ran on Windows. The first company to do that was Logos Bible Software in 1992. Realizing that Windows wasn't a fad, Jim had the programming staff convert PC Study Bible to Windows. It is unclear as to when the first Windows version was released, but it was sometime between 1992 and 1995. The internal structure of the program remained unchanged, with the User Interface being converted, using Turbo Pascal for Windows. In a way, Logos owes its existence to Jim's misstep.

Interestingly, Roy Brown began working on Bible software also in 1988, but it wasn't released until 1994 as Accordance Bible Software. It wasn't a direct competitor to Biblesoft or Logos (at first) because it was oriented toward original language analysis tools, whereas PC Study Bible was oriented toward pastors, church teachers, and lay people - and Logos was competing against Biblesoft in that space. Some other companies also entered the marketplace in the 1990s, but Biblesoft and Logos were the two major players. Apparently at one point several of the Bible publishers (Zondervan, Thomas Nelson, etc) got it into their heads that they could create their own Bible apps. For a couple years, it was difficult to license material from some of these publishers because they didn't want competition to their planned software. It soon became clear to them that such plans were not workable for various reasons: not being able to license material from their competitors, the lack of public domain material, the lack of experience in the software market, and the problem competing against the "big two" Bible software companies.

One of Jim's strengths was making a program that was easy to use. Primarily this was a result of the fact that Jim, despite being a programmer, was not a terribly technical individual. As a consequence, what was easy for him was easy for non-technical people in the marketplace. That isn't to say that PC Study Bible was particularly easy to use, but it was far easier than all the other software on the market - thanks to Jim. As one employee once told me, "PC Study Bible is the easiest of all the hard-to-use software on the [Bible] market." One of the reasons that Logos was much harder for most people to use was because the Logos founders were ex-Microsoft developers. They approached software from a technical perspective, whereas Jim approached it from a neophyte perspective. For example, certain search operations in Logos software required regular expressions which, though powerful, is not something that non-technical people know (or care to learn). One of the biggest differences between PC Study Bible and Logos in the 1990s was that most everything in Logos was search-driven, whereas Jim rightly recognized the problems with making search the primary driver of functionality.

Jim astutely recognized that massive search results were not helpful and so he downplayed traditional search in the program. As an example of the truth of this recognition, consider how many pages of Google search results you typically go through. Five pages? Ten pages? No one is going to look at 10,000 results to a search. In fact, text searches were capped at 5,000 results in PC Study Bible and the user was notified that perhaps they ought to consider a more restrictive (ie useful) search. The cap was increased for Morphological searches because sometimes one simply wants to know how many matches there are for a given word morphology. Unfortunately, Jim de-emphasized searches so much that there were useful search abilities that weren't added until the 2000s.

To understand the marketplace at that time, Bible software was mostly sold through Christian bookstores. Relatively little was sold direct to the customer. We had commissioned sales people who sold into the various bookstore chains. Every year the sales and management staff would travel to the CBA (Christian Bookseller Association) event where stores and publishers (both of books and of software) would meet. Everyone had a booth at the event and the sales people would typically make their biggest sales at these events. As a consequence, there wasn't a need for much in the way of advertising. Once we had a registered customer, we could do direct sales of upgrades to those customers in lieu of expensive advertising campaigns. Sometimes we'd mail small glossy catalogs, but usually it was postcard-sized ads.

Logos claimed an edge in the market due to having more reference works to choose from than Biblesoft. This was true, but somewhat misleading. Not all reference works are useful in Bible study. If you have twice as many works to choose from, but half of them provide minimal (or no) usefulness in terms of Bible study, do you really have twice as many works? However, Logos did have an edge in useful and/or desired works due to Jim being the bottleneck at Biblesoft - and he spent most of his time doing management tasks rather than processing reference works. So it became obvious that another tack was needed so that reference works could be processed faster. Therefore the next evolution in PC Study Bible was needed in order to get away from manually crafting code for each work. Hence was born the Reference Work Compiler, which took any given work - containing markup tags - and compiled it into a general database that the program could use. Adding a reference work was, in theory, as simple as running a new work through the compiler and providing the resulting file to the customer. In actuality, there often was some amount of programming required to support some new feature that was driven by a new reference work.

It was at this time that I was hired, along with Keith, to maintain the current version of the software while the four other programmers wrote the new back-end that 1) contained the database, 2) fed data to the user interface, and 3) supported the reference work compiler. This was all written in C++. Keith wrote a new Bible Reading Plan, and I fixed bugs. When the back end was close to being finished, Keith and I transitioned to working on the front-end (User Interface) for PC Study Bible Version 3. We used Delphi for the UI since it provided Rapid Application Development of front-ends. When PC Study Bible Version 3 was released, we had to make changes to the UI simply because the sheer number of reference works that became available through it. In Version 2 and earlier, each work had three buttons of its own (one to open, one to cross-reference, and one for smart-reference). Frankly, in Version 2 the number of buttons on the screen was a bit overwhelming - resembling the control panel of a space shuttle. (As I said, it was the easiest of the hard interfaces on the market). There was much back-and-forth on the interface. We wanted it to be intuitive (especially for existing users), but it needed generalizing and simplifying. In the end, it was still more complicated than I cared for, but Jim was right more often than he was wrong when it came to what appealed to the customers. But he was sometimes wrong. Let me give a couple examples. Jim came up with the appendable clipboard. It extended the industry-standard clipboard feature with the ability to append things to the clipboard instead of replacing them. A user could quickly gather up related things on the clipboard by successive copy operations. Genius! Of course, we had an option for turning that off if you wanted traditional clipboard operation. But on the other hand, Jim also wanted nonstandard behavior on tabs and edit boxes. This added no additional functionality to them, it simply changed how they worked to be like Jim wanted. But it was so different from industry standard that it was downright confusing for anyone who used any other software on the PC (or Mac). So we added options for those things as well. Unfortunately, the weird behavior shipped as standard and you had to go to options to turn it off. We made sure technical support staff knew about the options.

It must be understood that Jim was THE USER. All interface and behavior choices were for his benefit. Because he was usually on-track with most of the rest of the users, this was generally a really good thing. Left to our own devices, we programmers would have made the program more like a software development tool. But this is also a case of someone's strength being, at the same time, their weakness. Sometimes Jim thought an industry standard was stupid. When he felt that way, he had no problem going contrary to standards. But regardless of whether or not it was stupid, it was still a standard - and if you are the only one bucking the standard, you don't seem innovative - you seem odd. Fortunately, we were able to talk him out of some of his weirder ideas in this vein, and provide options to undo the ones he insisted on. In the end, we got very few complaints and the users really liked our interface, especially if they had experienced the other apps on the market. Not to say that there aren't dyed-in-the-wool Logos users that think it is the ultimate study tool. Each program has its detractors and promoters. Each company has its own fan club. Perhaps I am biased, but I think that PC Study Bible was, overall, a superior product to everything else on the market, despite its shortcomings. And all software has shortcomings.

Version 3 was a complete rewrite of the application and it took over two years to complete. We corrected a lot of the issues with Version 2 (and created some new ones as well - such is software development). The new way of doing things led to a quickly expanding number of available reference works, from roughly two dozen to nearly two thousand within a short period of time. Logos still boasted of a larger selection of works, but many of them were of questionably utility. The reference work compiler was merely a front-end user-interface to the authoring capability built into the back-end. This was used by our text processing person to create new content for us to sell. But, having it built into the program allowed us to create the Biblesoft Authoring System (BAS). This was supported through Microsoft Word and through the Study Note feature of the program. In theory, someone could author just about any kind of reference work on their own and use it in PC Study Bible just like any of the works that Biblesoft (re)published. The Study Note feature essentially allowed users to create commentaries of their own, by creating notes on Bible passages. These notes could be exported in BAS format if the user wanted to create a reference work to share with others. The users could share the individual file for a study note set as well, but they could use the authoring system to use abilities not present in the in-program study note editor. For a short time in Version 4, Biblesoft had a web site for the Biblesoft Authoring System Exchange (BASE) where users could upload their content and download the content of others. However, this did not last very long due to a lack of any content moderator or dedicated web site support.

Logos had an equivalent authoring system called STEP, but they charged people to use it. And the charge was steep: $5,000 if I recall correctly. Biblesoft only charged for the selling of content created with BAS. The number of publishers would took advantage of either authoring option was minimal - BAS was primarily used by our staff and I think STEP was largely used by Logos itself.

It should be noted that a lot of capability was built into the back-end, which was the result of many brainstorming sessions, forward-thinking dreams, and attention to lessons learned in the previous decade of PC Study Bible. In fact, the program never plumbed the depths of all of its potential. Changes in the marketplace - especially in the 2000s - affected all Bible software providers, not just Biblesoft. However, since I only worked at Biblesoft, I cannot speak with authority about what was happening in the other companies. There is a certain personality type associated with entrepreneurs who start businesses. The reason they are successful is because they pay attention to all of the details of the business, making sure that everything happens that needs to happen. But this turns into a weakness as a company grows. This is actually a well-known phenomena that I've read about in various management publications. At some point, the size and scope of a business becomes too much for a single individual to manage effectively. That is why many startups stop growing at about $4 million annual income (the exact amount will vary depending on the market and other factors). The only way to break through this ceiling is for the founder to start delegating tasks to other people. Sounds simple, but it is very hard to do in practice. Part of it has to do with the psychology of entrepreneurs - the company is their baby that they have nurtured for years. Micromanaging things is how the business grew into a going concern the first place. Changing from this mindset is very difficult. Probably impossible for most people. There are very few Ken Olsons or Bill Gates that can make the transition from startup to small company to big company.

Remarkably, Jim was able to delegate the programming to others as long as he could micromanage the UI. This isn't a backhanded compliment - as stated earlier, his attention to the UI was a net benefit to the product. However, Jim (like most people in his situation) couldn't delegate other tasks. He'd assign tasks, but then he'd insist on micromanaging them. Under his leadership, the company would grow. Biblesoft would reach about $4 million net income with about 30 employees. But then Jim couldn't juggle all of the balls and things would start being neglected - his focus needed in one area took his attention away from another. In that situation it is easy to become reactive, putting out fires as they happen and not moving forward. As a consequence, the income would start to drop and then the company would have to lay people off. We'd drop down to a more manageable 20 employees. Once things were manageable, the company would start to grow again and the cycle would repeat. I don't recall how many of these cycles we went through, but it was several. As Technical Lead, at one point I was tasked with laying off two of the junior programmers under my direction as we passed the peak of one cycle. Again, this is not to say anything bad about Jim. In fact, the company I worked for before coming to Biblesoft was in the exact same situation though they were in an entirely different market. The cause was the same and the effects were remarkably similar.

It was sad, because there was obviously potential for growth in the market, but the company management wasn't able to tap into that potential. Nor was this unique to Biblesoft in the Bible software market. Logos was roughly the same size and never grew much past that. The other companies in the market also never really thrived either - they all just sort of slowly plodded along. My guess is that they all suffered the same common problem. To make things worse, the market began to change in ways that no one had predicted.

The rise of Amazon put most book stores out of business. The few that remained, such as Barnes & Noble, didn't really sell software, and the Christian bookstores all but disappeared over the decade. In addition, the internet became the way to distribute software. Downloads became more common and even physical product was ordered online instead of through stores. Most of the Bible software companies quickly adapted to this new model, but Biblesoft (and perhaps others) had problems because marketing became far more important. No longer could anyone rely on making big sales to bookstore chains which essentially advertised the product. But because of the chronic lack of growing income, Jim was adverse to spending money solely on advertising. Increasingly Biblesoft only sold into our existing customer base. Granted, there were over 70,000 users in the database, but most of them were one-time buyers. There was a segment, perhaps 10%, that would buy anything and everything we released. Management called them "collectors" - they were more interested in having everything even if they rarely, if ever, used what they purchased. Therein lay the next problem. Most people are not collectors - they will only purchase what they think they will use and rarely anything more. It makes sense. Who is going to read 20 different versions of the Bible, or 40 different commentaries? Most people will be content with a collection of less than that. Offering a new reference work would typically appeal only to those who specifically liked that reference work over what we already offered. But once we had all the major works, the return on investment was diminishing when new works were introduced. We'd get the collectors, of course, and maybe another 5% that really wanted that specific work. Instead, our biggest sellers were new releases of the software. A new version was a guarantee of a big influx of cash. But when one is light on income, the temptation becomes to release new versions as often as possible with the minimal possible effort. I think Biblesoft resisted that temptation fairly well, but Version 5 was probably the lightest on new features of all versions since Version 2.

Another change in the market had to do with the various free Bible study apps that started to appear, such as E-Sword and YouVersion. At first, these weren't much of a concern since they had relatively few works and even those were all in the public domain. They were also rather amateurish efforts compared to those who had been in the marketplace for over a decade. But they were free, which appealed to many people. Some of us tried to convince Jim that a free (trimmed-down) version of PC Study Bible might be a good way to bring in new customers who might then upgrade to a paid version. However, management saw this as something that would simply eat into the sales of our "starter" edition product.

As the market continued to become more challenging, and management refused to spend money on marketing, we had to become more inventive. One idea was the "Outreach CD" initiative. The idea was a good one: identify ministries that could benefit from their material being integrated into a custom version of PC Study Bible that they could distribute to their supporters. I don't know if we got any payments or if this was entirely an effort to raise market awareness of the program. The problem, however, is that after spending a lot of time and money, we only put out three different Outreach CDs. The company lost a lot of money doing this and further soured Jim on expending money to increase our market share. The reason this flopped is because, despite the enthusiastic response from many ministries, most of them ended up dragging the process out to the point that we had to cut them off to avoid hemorrhaging more money. The crux of the issue is that non-profit organizations operate in a completely different way than for-profit businesses. Most ministries have a relative stable income through regular donations, which reduces the urgency for them to do new things. When you are a company with expenses and a declining amount of money coming in, you need to predict when something will be done so you can allocate funds (or avoid it entirely if it will be too expensive). With several ministries leading the company on past the anticipated date (with all the associated additional cost), it did no harm to the ministries but grave financial harm to Biblesoft. Something to keep in mind when you deal with non-profit organizations...

Another attempt to increase market share was to court seminaries in hopes of them recommending PC Study Bible to students. This required two changes: the addition of a morphological search ability and the inclusion of some specific reference works. Jim wasn't particularly keen on this because PC Study Bible was aimed squarely at pastors, teachers, and lay people. Logos has gone more after the "scholarly" market and Biblesoft was okay with them leading that market. However members of management had talked with some seminaries and informed Jim that the investment cost was relatively low. Morphological search and other fixes and enhancements required about six months of development time, plus obtaining licenses to some reference works. As usual, the PC Study Bible morphological search was much simpler to use than what others offered, but with all of the necessary functionality. However, once the product was ready, the same seminaries that management had talked to said that the program was still not adequate without several other reference works that they had not listed six months earlier. It is unclear to me whether the seminaries made major changes in the curriculum that required new books, or if they had given us bad information. Jim was upset that we had invested the time and money with nothing to show for it (morphological search had limited appeal to our core market). These two experiences served as "proof" to Jim that spending money to expand the market was ineffective. Frankly, if a fraction of that money had been simply used to purchase ads on Google and on certain sites and in certain periodicals, Biblesoft would probably have expanded their market significantly.

On the technical side, we considered ways we could possibly broaden the number of computers that could run PC Study Bible. We briefly looked at Microsoft's .net platform, however there were no tools we could use without having to rewrite the entire program, which the company simply could not afford to do. One of the junior programmers went to a Microsoft seminar where Microsoft was promoting some new technology. He thought it was a good idea and, after talking with Microsoft presenters about our product, was convinced that we could convert to the new technology in six months. Six months was supposedly how long it would take to convert to .net. The six-month estimate came out a couple of other times about other tools or platforms. It seemed odd that everyone seemed to think that a programmer could convert the 800,000 lines of PC Study Bible code in six months. Rich and I talked about it and estimated that if the two of us worked on it full-time, we might be able to rewrite PC Study Bible in twelve months. In other words, two man years for highly experienced, high-performance programmers with a decade of experience in the problem domain. Anything less than that was beyond optimistic - it was delusional. In addition, I was highly suspicious of Microsoft's new technologies. More than once they had urged people to jump on a technology bandwagon only to change their mind - or completely drop the platform - within a year. Even a six-month effort to convert the software would be a complete waste. In fact, the technology promoted at the seminar (no, I do not recall what it was called), was abandoned by Microsoft less than twelve months later. Even so, none of the Microsoft technologies (.net or otherwise) would actually provide an advantage in terms of expanding the number of computers that the software would actually run on.

That isn't to say that Rich and I were against rewriting PC Study Bible, per se. Years of experience had taught us that we had made various missteps in terms of how things were implemented. They weren't "bugs" and they didn't affect the user experience, but working around those built-in restrictions was time-intensive and, therefore, expensive. For instance, I spent a month working around one of these problems, essentially making the back-end database work in a way it was never designed to. That was to solve only one issue. Frankly, I look back and am surprised it only took me a month. There is always the desire among developers to redo code in the "right" way. But at that point, the company simply couldn't afford the cost of a rewrite. And it never really got to the point after that where it could afford it.

Converting the C++ back-end to another platform probably could have been done in a matter of weeks, but the bulk of the code was in the front-end which was Delphi. At the time, the only platforms competing with Microsoft Windows were Linux and Mac. Linux had no standard GUI, so that was simply a non-starter. Mac was different situation. It only represented about 14% of the total market, but expanding our market by 14% would be worth the effort, assuming we didn't have to completely rewrite the program. Unfortunately, at that time, Delphi couldn't target the Mac. But there was the free Lazarus IDE which was Delphi-compatible and did target Mac as well as Windows. So I spent some time preparing the code to support changes: direct Windows calls wouldn't work on Mac, and the LCL (Lazarus Control Library) wasn't 100% compatible with the VCL (Delphi's Visual Control Library). In the first case, the changes actually made the code base better because O/S dependencies were isolated into a module that could be swapped out between Windows and Mac without other code changes. In the second case, VCL is what made Delphi a Rapid Application Development platform, and LCL and VCL were similar but not compatible. The compatibility was only 100% for the Pascal code itself. This required re-implementing certain UI components where the LCL didn't have a corresponding component to what we used in VCL. I won't go into all the other changes required to deal with the incompatibilities between the LCL and VCL where components were almost interchangeable, but not entirely. This all happened as part of a planned Version 6 and at that point I was the only remaining programmer. Only part of my time was spent on Mac compatibility, since other program changes were required. Nevertheless, in less than a year, the code base was in a state that would allow us to compile it under Lazarus. Unfortunately, despite working proof-of-concept tests, when we compiled the entire front-end under Lazarus, the resulting program was unstable and prone to fatal errors that caused it to end. Investigations led to the realization that Lazarus was simply not at a point where it could reliably generate good code. After digging into a couple of the fatal errors, I discovered serious bugs in the assembly code generated by the Lazarus compiler. It simply wasn't up to the task of a production version of a large commercial product. There were weeks of wasted time, but much of the changes resulted in better "code hygiene" which made the program easier to maintain. But we gave up on the idea of a Mac version at that point. Eventually, we packaged PC Study Bible with the WINE emulator that ran on Mac which gave us a version of the program on Mac. However, the performance was impacted and the UI was Windows-centric - which meant that only those Mac users who were desperate specifically for PC Study Bible running on the Mac were interested in it. We made some sales, but certainly not a 14% increase in the customer base.

Now, one might wonder why the code base was 800,000 lines of code. About 65,000 were in the back-end. Then there was the Reference Work Compiler, and a host of smaller utility programs, regression test scripts, UI definitions, and the like. Still, that left well over 650,000 lines of code in the front-end - roughly ten times the size of the back-end. Why was this? About 250,000 lines of code were part of the display technology. You must understand that this was developed in the days of Windows 96. Unicode was a standard, but neither Microsoft nor Apple actually implemented it in anything. Thus, our Greek and Hebrew display had to use True Type fonts that mapped those glyphs onto normal characters and then swap fonts as we displayed text. However, Hebrew is displayed right to left, so that had to be taken into consideration (sometimes mixing both left-to-right and right-to-left text on the same line). The display code didn't support Javascript, but it had basically all of the capabilities of a web browser of that era, plus Greek/Hebrew, plus right-to-left output, and other things that HTML didn't support at the time, such as conditional text display, an indirect nested font reference scheme (think CSS), floating divs, and so on. In addition to having the equivalent of an entire web browser, it also had to support in-place editing for the study notes. Additionally, whereas a browser loads an entire page and displays it, our displayer had to work with some massive reference works (multiple volumes, 10's of thousands of print pages), so it had to iterate through the contents, providing a sceeen-sized viewport into a much larger work. All this complexity was beyond any third-party code that was available at the time. So we wrote it from scratch.

Additionally there was support for a scripting engine that supported what we called the Biblesoft Macro language. This was used for regression testing. Users could run a script under direction from technical support, and we considered releasing documentation for the users at some point, but it was never ready for users. I no longer have access to the internal documents, so I couldn't even tell you how to write a Biblesoft Macro script if I wanted. Macros could also be initiated when certain reference works were opened, or when the location in them was changed, or by the user clicking on a link that was associated with a macro. I believe there was also a mechanism for associating a UI button with a macro script, though it was never used. In addition, there were hooks for a more sophisticated scripting system that we never got around to providing.

I lost track of the number of times that I was told that if we didn't get release X delivered to the customers by a certain date, the company would go out of business. We always managed to meet the deadlines, but hearing it so often left me somewhat skeptical. This had been going on for years. Obviously, the company wasn't flush with cash given that all but one developer had been laid off. The expand/contract cycles had ended and we were at minimal staff. There were no raises or new hires. But whether or not the company was on the edge of financial disaster had no practical effect on me: I couldn't work harder than I could work. The fact that one developer could support a code base that once required six developers was testimony to our ongoing refactoring of code that happened for a few weeks each year. We had done this for years by taking a week after each release to go back and clean up the "quick and dirty" things we had done in a rush to get the product done by the deadline. I knew from experience that this kind of "cancer" accumulated inside the code base, making it harder and harder to support because the code was increasingly fragile. It might not have been pristine code, but it was nothing like most software that had been around for over a decade without a rewrite. The UI might look dated, but the underlying code base was in remarkably good condition.

In the early days before the company was struggling financially, Jim was generous. I was paid a competitive salary for the time in the Seattle area, including yearly raises that I didn't even ask for. On a good year, Jim was very happy to give out bonus checks to everyone. At one point, Jim wasn't interested in providing a hymnal in the product. I decided to create one for free on my own time (while on vacation). The response from the users was very positive and Jim realized he shouldn't have opposed it. So he actually paid for my two weeks of effort even though I had provided it for free and without any thoughts of getting compensated. Jim felt a certain responsibility toward the employees and did not like lay offs. From what I hear he actually held off on some royalty payments in order to make payroll. So there was quite a stressful situation for him. And one must understand that Jim started the company in his retirement years, so he was in his 80's by this point.

The market continued to change with the rise of apps running on cell phones. Android and iPhone were the two major ones, but Windows had a smartphone for a while as well. Then there were all of the tablets running the IOS or Android operating systems. PC Study Bible already ran on the Windows tablets, so we were in that market space, but we were still limited to Windows which was losing market share to the phones at an ever increasing rate.

For various considerations, to which I am not privy, Jim decided to sell the company and retire. I suspect that part of the reason was he wanted to find someone with the financial wherewithal to move the company forward. I don't recall the exact time that it happened, but the company was sold to Kenneth Davin somewhere around 2010-2011. As is often the case with people who retire, Jim (who seemed in good health when he sold the company), passed away within a year or two of retiring. Kenn Davin was the owner of a construction company, so he had no background running a software company, but he knew some people who were in software development and he wanted a Bible app that ran on his phone. Further, he was friends with Gary Hill who wanted an electronic version of his Discovery Bible. Steve (the text processing guy at Bibleosft) and I had a meeting with Gary and Kenn and worked out a plan for creating an electronic Discovery Bible. However, within two weeks, Kenn dropped this and decided to focus on a mobile app instead. This was to be a new development effort - not a conversion of PC Study Bible to mobile.

Kenn had a developer friend who promised Kenn that he could create the new app in six months. There is the six-month-estimate again, that I'd heard from different people in years past. I'm not sure why this is, but it probably some sort of psychological flaw in us humans when we don't properly understand the problem domain. I'm sure that this relatively inexperienced developer honestly believed that his estimate was accurate. Given my experience in this problem domain, it was abundantly clear to me that there was no possible way that this timeline was realistic. I clearly let Kenn know this, but this is where his lack of experience in the software industry showed itself. His reply to me was that the developer had promised him six months and that was that. I understand that the human impulse is to trust people one knows over those that one does not know. However, this developer also had the assistance of two Biblesoft employees, who were web developers, but not very experienced software engineers. As when I was first hired, I was to maintain the existing product while the new product was developed. There wasn't really any other choice anyway, since I was the only reasonable choice for maintenance of PC Study Bible.

I wish I was wrong, but I wasn't. After six months, there still wasn't a working prototype of the new app. Then nine months came and went, with still no app. The effort was finally abandoned after nearly twelve months. One year of calendar time and three man years of effort were simply lost. And even PC Study Bible didn't progress very much as my hours were severely cut back for that year. I call it the "lost year". Now, I should note that some of the front-end app development itself was carried forward, but not much. Finally, Kenn dropped the failed effort and asked me to design a working database for the new app. When I saw what had been developed so far, it was unusable. It wasn't that it was a nonsensical design - just that it was designed by someone who didn't have the benefit of 20 years of Bible software development. In fact, it was exactly what I'd expect from a software developer with no Bible software experience. For instance, the database was suitable only for a typical Bible translation - not inerlinears, encyclopedias, commentaries, or any of the other types of reference works that PC Study Bible supported from the start.

It is important to describe the basic goals of the new app. First, the idea is that it would run on Android and iPhone, but would eventually replace PC Study Bible. In fact, the customers were told that we were working toward that, which excited many of them. No mobile device at the time could handle the sheer amount of data that PC Study Bible was already handling for users that had most or all of the reference works that we offered. Therefore the plan was to host all of the data online and the mobile app would simply be a client for that online database. TO get the multi-platform support, we went with a product called Sencha, which was essentially a Javascript framework that ran on IOS, MacOS, Android, and Windows. That was what Biblesoft was aiming at.

My hours were restored, though I was expected to spend about 20% of my time supporting PC Study Bible. I didn't work on the Sencha app, but I designed and created the online database that could support all the features of PC Study Bible, including study notes. Then began the process of populating the online database with the actual reference work data. I wrote a version of the Reference Work Compiler which translated the source files into SQL import files. I then used it to generate the files, uploaded them, and then imported the data. The whole process took about 18 months to complete (most of that was simply waiting for the uploads and data imports to complete). Not only was there data imports, but a search index was created to support quick searching. Have SQL do a text search across multiple large tables takes a long time. Now imagine hundreds or thousands of users doing searches concurrently. So, the search index allowed very fast searches. Additionally, indexes were needed for cross-references, smart-references, and things like book outlines. Over one billion records had been imported when all was said and done. Granted, some of those were reimports when a problem happened with the import, but it was a big database. Because the new reference work compiler could handle any of our existing formatted source files, any new reference work could be compiled with the old reference work compiler for PC Study Bible and with the new reference work compiler for the online database.

Then began the process of providing the online services that would access all of this data. These services would be called from the Sencha app. The process was that the Sencha developers would ask for a way to access data and I'd write a routine that would provide that data. However, we began to run into problems with the design of Sencha itself. It was obviously designed for much smaller tables and less complex data. This required the developers to fight the architecture as much as benefit from it. Some early versions of the Sencha app were released to the users. But it was a long road to get to the point that the mobile app had an appreciable amount of the functionality of PC Study Bible. Another problem that we ran into was that Sencha was slow. Even if we could minimize the amount of data being downloaded (which was another issue unto itself), many operations in Sencha were painfully slow. Eventually, one of the Sencha developers left Biblesoft and the other was re-tasked to support the rest of the company's websites. The Sencha app basically was abandoned. But we kept the online database in hopes that it would eventually be used.

Without the mobile app, we again had to focus on PC Study Bible to try to earn enough money to keep the company running. PC Study Bible was renamed to One Touch in preparation for eventually being multi-platform. We also lost the remaining Sencha developer, which left us without the resources to move Sencha forward. Along the way, Delphi had been updated to target Mac, IOS, Android, and Windows. However, a conversion of PC Study Bible to mobile would exceed the hardware requirements of those platforms. Mac could be easily done, but not mobile. However, with the online database, the idea of PC Study Bible on mobile was looking possible. We still couldn't do a straight conversion because the UI was simply way out of date. It barely appealed to anyone on Windows. It would be laughable on any other platform. There were some cases when management was out of town and I had finished the PC Study Bible assignments I had received. So I decided to use the updated Delphi to write a replacement for the Sencha app. By the time management was back in town, I had a working prototype that did much of what the Sencha app did, but much faster. As an interesting side-note, Embarcadero, who owned Delphi, eventually bought Sencha. By that time we had abandoned Sencha, which is probably for the best.

When management saw the new mobile app, the company devoted its time to the new app. I worked on it for about a year and we were ready for an initial release other than the fact that the app could be slow. It was an order of magnitude faster than the Sencha app, but downloading content from the online databases kept it from being as snappy as one would expect a mobile app to be. We reached a conclusion about how to address this and we were probably two to three months from having something ready to start selling. The company was literally just around the corner from a renaissance. However, I felt compelled to leave Biblesoft at that time, at the urging of the Spirit. But, in theory, they could have hired another programmer to do the final work. It might have taken then longer due to needing to get up to speed on everything, but I could imagine that they could have been ready with the new app by the end of that year (2020). However, that is not the path that Kenn chose. Again, I think it had to do with his lack of understanding of software development. He seemed to feel that he could have a programmer buddy of his do the work in his spare time with minimal cost. I can understand the feeling of throwing good money after bad, but it was a shame that the company was so close to turning around only to have management fail to seize the moment.

It was some time during the last year or two that we finally were able to put up a free version of PC Study Bible that people could download. But it was too little and many years too late. First, most of the other Bible software companies had provided a free or trial version of their products. Secondly, the free apps (and websites like Biblehub.com) were now providing, at no cost, most of the public domain materials that we sold. As a consequence, PC Study Bible Lite barely caused a ripple. The market changed for Logos as well. My understanding is that they are now focused on church management software, though they still offer their study app. Free still trumps functionality for many people. The fact that commercial products offer a superior experience to the free, or on-line, options is lost on most people. I think that there is still space in the market for commercial products, but it is primarily for niche players. However, I've also been surprised to run into entire congregations that are apparently unaware of either the free or commercial offerings. Clearly there is some amount of untapped market out there. The question, as always, is how do you reach those people?

From my discussions with friends who still worked at Biblesoft after I left, things stagnated for another year or so before all of the rest of the staff were laid off and the building space was sold. The company continued to exist as a legal entity and the web sites remained. I think people could still purchase PC Study Bible and various reference works from the online store, but I'm not sure about that. I even heard that, as recently as 2025, there was still a customer service person employed to answer customer calls and emails from her home. I occasionally checked the company web site to see if there were any announcements. However, in late 2025 I noticed that the biblesoft.com domain was no longer valid - the company now had no web presence. As of my most recent check, it was still gone.

Before I conclude, I feel it necessary to comment on the Biblesoft customer service. Though technical support and customer support used to be separate, as part of downsizing they were combined. These ladies were very kind, even to rude individuals. It shouldn't surprise me that people using Bible study software are nasty when they get frustrated about something, but I have to admit that it does shock me. I suppose those are the people most in need of studying the Bible. The support team was also helpful when it came to computer problems that had nothing to do with PC Study Bible. In all fairness, Microsoft ought to have paid us a lot of money given the amount of support for their products that we provided. And the support team also helped people who were having stressful life issues, sometimes praying with them. They were remarkable caring people doing a job that I don't think I'd last a day doing.

Biblesoft is still a registered business in Washington state. But it has been administratively dissolved. This could mean nothing more than that there have been no sales in two years. In fact, businesses have five years to reverse the dissolution. But the disappearance of the web presence does not bode well. Even if it is technically in existence, it is not in any practically sense "in business". I haven't talked to Kenn in years, so I don't know further details. And the few things I've heard through the grapevine are not things I can verify and therefore I refuse to share them. I don't know if the business exists in the mind of Kenn. I don't know if it will ever make a phoenix-like comeback. The only thing I know is that, at this point, it is not functioning as a business.

I talked a lot about Jim and Kenn because their decisions had so much influence on the company, but I don't wish to give the impression that they were particularly at fault for the eventual failure of the company. It is often difficult to adjust to a changing market when cash is short. Sometimes plans don't work out despite the best intentions and efforts. Sometimes it is best to wait until mature tools are available before trying to operate on the leading edge (some would call it the "bleeding edge"). I certainly occasionally made mistakes. For instance, the PC Study Bible preferences provided way more flexibility than was needed, which made them harder to use for most people. In retrospect, we probably should have made the program a little less customizable so that it would be simpler for the user and easier to maintain the code. Overall there were a lot of factors involved, including some big ones that I haven't mentioned. I don't think the finger can be pointed at any one person, event, or choice. A lot of creative and intelligent people were involved in the company's success, but couldn't prevent its decline.

The employees were a generally great group of people, many of whom I am still in contact with. I believe the product was used by God to draw many people into a deeper relationship with God, which was the company's vision statement. I feel sorry for the customers who spent hundreds, or even thousands of dollars on PC Study Bible over the years. For a long time I mourned the failure of Biblesoft to live up to what it could have been. But as God asked Samuel, "How long will you mourn Saul?", I felt like the Spirit asked me, "How long will you mourn Biblesoft?" This history serves as me closing the book on the subject. I will always think it a shame that all that potential came to an early end. But God's will be done, and I have moved on to other things.