Before the Fun Begins…

May 16, 2007 — In our last edition of The Latest Word (TLW), we indicated that we would be discussing Helix prices soon. That time has come.

For those of you who have been waiting restlessly for an ‘update from the trail,’ we had one almost ready to go into this edition, but due partly to technical problems, partly to the sheer volume of material we had to convey and partly as a nod to those of you who just think we tend to be too verbose, we’ve broken it apart from today’s news, and we’ll post it next week.

That leaves us with two important announcements to make today. While those of you who have already upgraded to a Helix 6 product may not find much in the way of news in the first one, it might be worth a glance if only to pat yourself on the back for helping us, or to provide ammunition to use on your friends or customers who are still holding out. But if you’re truly in a hurry, then by all means proceed directly to the second.

It’s Official: Helix 6.1 is Next

Four years ago this very month, an edition of TLW proclaimed that “For far too long, the easy alternative has been the one taken, resulting in a Helix that is far behind its market in several key respects.” In that moment, and in several that followed, we stated our commitment to doing the job right, even if doing so caused us to lose more time in the process. We have stuck with that design imperative and while the journey has been long and difficult, a lot of good progress has been made and when we look over our shoulders, nothing we have built since then needs to be dug up, knocked down and rebuilt to get us where we want to go.

If you’re reading this, it means that you made that commitment with us … even if it was only a commitment to hang on and see if we make it. When we were getting ready to unleash the macOS native Helix Server in December of 2005, we knew that only the most hard core Helix fanatics among you would take the plunge into the strange but temporary world we were creating where an OS 9 Client was served by a macOS Server. That hard core amounted to approximately one third of those who owned the most current version of Helix at the time. Our prediction was quite accurate; the remaining two-thirds dug in their heels, determined not to spend another dime on Helix until we gave their end-users and macOS interface that would free them from having to run in Classic. They haven’t abandoned Helix for another platform; they just can’t justify spending money to prolong their ‘Classic agony.’

By virtue of the pricing we established at the time, the proceeds from the Helix 6.0 Server upgrade and new license sales took us far — though not quite far enough — over the hill and into the next projects: macOS native versions of Helix Engine and Client. (Of course, Server is already done and RADE is patiently waiting its turn.) We have been fortunate to have had some additional help during the past several months or we wouldn’t be writing this update today. But those funds are disappearing rapidly. We have often speculated during this difficult time that if only half of the remaining holdouts would upgrade, the remainder of the work would be funded and we could move ahead full steam instead of working in fits and starts. But that hasn’t happened.

If we haven’t said so officially as yet, the next release of Helix is called Helix 6.1. It will add macOS native versions of Helix Engine and Client to the existing Helix product line. And as we have promised, those who purchase either a new Helix 6.0 product or an upgrade prior to that release will get a free upgrade to the corresponding Helix 6.1 product or products that they own. Those who have gone along with us on this wild journey know that we have tried in as many ways as we know how to reward those who help us achieve our goals. We offer our heartfelt thanks to those among you who have made that financial commitment and we promise you that we will strive to continue to find ways to reward your faithfulness. We can’t say how at this point, because we don’t know what tomorrow will bring, but take a look at our track record and we think you’ll agree that we do what we can.

Right now our pressing need is to fund the ‘final push’ to get the macOS Client and Engine out the door, and pricing is a critical element of that push. Before we delve into the specifics of the new pricing, we need to make it crystal clear that this is not an announcement of an imminent product release. Yet at the same time, without meaning to be cagey in any way, it also bears mentioning that if you look back at our price change announcements since 2002, they are always followed in reasonably short order by an announcement either of the beginning or the end of beta testing. With the exception of the monumental, seemingly endless beta testing of the revised TCP/IP networking, most of our beta cycles have been blissfully short by comparison. And, without unnecessarily raising expectations, the next announcement from us should be about the beginning of beta testing.

Somewhere between this announcement and that one, we will make the price changes we’re going to discuss today official. We don’t know exactly when that will be, but when it happens, it will change the price of the current product. We’ve always worked to price Helix upgrades in such a way that it makes more sense to upgrade from one version to the next than to skip a version. And our tiered-upgrade pricing means that staying current translates to reduced — even free — prices on future upgrades.

While this message has gotten through to many users, too many still miss the point. When we compare the cost of developing Helix to the revenue generated from users who actively keep their Helix licenses up to date, we see that to keep moving forward, we simply have to charge more. How much more? Here’s a link to our revised pricing. A quick glance will reveal a few key things:

The tentative price increase was revised on September 28, 2007 & again on November 6, when the new prices took effect. The percentages mentioned in this original article are no longer accurate.

• The price to upgrade Helix Server from 5.3 goes up about 30%.
• The price to upgrade Helix Server from 5.2 or earlier goes up about 60%.
• The price to upgrade Helix RADE from 5.2 or later goes up 100%.
• The price for most new Helix purchases goes up 50%. (However, the price for a new Helix Server license actually goes down about 5%.)

If this news has you steamed, think about buying concert tickets. When the concert is announced, there are typically two prices: the advance (discounted) price, or a higher price at the door. We have been selling Helix at the advance price ever since Helix 6.0 shipped. We still are, and you can save a lot of money by buying now, but we are getting ready to ‘open the doors’ on this new release, and the advance pricing is going away, tied to some major step in our progress.

So consider this fair warning: if you haven’t upgraded to Helix 6.0 yet, buy now, or pay more later.

Universal Helix May Be Closer Than You Think

Before we begin this discussion, let’s take a moment to clarify what ‘Universal Helix‘ means. It means the Helix code is compiled as a macOS Universal application, allowing it to run natively on both PowerPC and Intel-based Macs. It has nothing to do with Windows. That is a project for the future, one we have historically referred to as the Platform-independent Helix Client, or PiHC. If you need a fuller explanation, click the logo on the right.

One of the big problems we’ve encountered as we trudge forward is that because Helix is PowerPC code, it requires Rosetta to operate on Intel-based Macs. What you may not be aware of is that since we switched from CodeWarrior to Xcode it takes an inordinate amount of time to debug even small changes to the code. Where it used to take just a minute or two to see the results of a code change, it now sometimes takes over half an hour. That’s frustrating, because it breaks the rhythm of writing good code, and it costs us dearly in time and money.

However, we can compile our code on Intel-based Macs, and we’ve seen that even a lowly ‘first generation’ MacBook with a CoreDuo processor (not the current Core2Duo or Xeon chips) compiles Helix 6 to 10 times faster than our G4s. But you can’t debug Rosetta code on Intel-based Macs, so before we can debug 6 to 10 times faster, we have to make the Helix code Universal.

A critical element of good planning is frequent plan review. As we move down the road, we learn things we couldn't have known when we first set out. When we decided to hold off on doing Universal Helix until we finished converting all of our products from PowerPC to native macOS, part of that decision was rooted in our assumption that the Universal conversion would also be a fairly huge undertaking. We have since learned that this assumption was not absolutely correct.

In addition to that, we are also reconsidering the decision to postpone making Helix a Universal application because:

1. Compiling our code costs us close to two days a week in productivity. That translates into nearly a week lost each month, or a month every three-to-four months. If we had Universal code, not only would we not have to be concerned with potential problems in running Helix under Rosetta, but our work would move along at a much faster pace.
2. Debugging our code on Intel-based Macs is impossible until our code is Universal. Consequently, the best way to fix bugs — actually watching each line of code as it runs — takes about ten times longer than it could.

The changes required to build Helix as Universal code should take our two top engineers about a month. Had we done that in January, we would have made up any lost time by now and be working faster today. The decision seemed right at the time, but we are regretting it now, and this creates a huge temptation for us to shift gears in that direction.

Even so, we’re so close to delivering our first beta version to testers that we’ve decided to wait at least until we’ve analyzed the results of the first round of beta testing before deciding when to do that work. If we find that we are as close to shipping as we hope, we’ll bite the bullet and press on until that is done.

However, if we find we still have a lot of work to do, we will be facing a hard decision. In theory, taking a month to convert Helix to Universal and then resuming the work on Engine and Client would allow us to ‘catch up’ in about three months, and then to proceed at a much faster pace from then on. But that’s in theory. It’s impossible — and therefore wrong — to call it fact from where we stand right now, but the more we look at it, the more we see that every sign seems to point in that direction. On the other hand, we do want to get these products into your hands as soon as possible, and we don’t want to rush a process that needs to be handled carefully. But it seems a very safe bet to say that we could — with a small detour — be working much faster than we are today, with an obvious benefit for everybody.

Of course, on top of the time factor the problem (as always) is money. We’ve promised to put every possible penny into just getting to macOS, and we’ve kept to that promise so far. But we know how much the Universal project is going to cost and how long it will take (and what it will gain us once it is done) and we have come to the conclusion that it needs to be done sooner rather than later.

As these things came into focus, we began contacting some of our larger customers and gauging their interest is specifically funding the Universal work. The response was almost universally (pardon the pun) positive, and we already have nearly two-thirds of that amount verbally committed. As soon as we have the rest (and we are comfortable with where we stand in beta testing) we are going to ‘write the check’ and go for it.