Making up the rules as we go along...
15 July 2002--Our July 2nd posting, "Dialogs in the Rough," about the plight of Helix with respect to its developer community, touched a lot of nerves. More off-list email has been generated by this topic than anything since the first announcement in June.
The responses have fallen largely into two categories. In the first, we’ve heard from a significant number of users who are not developers, indeed some who claim they would never (never ever) need the services of a developer, yet who all support the concept. Jack Caviness, a Helix user since 1984, put it succinctly with this excerpt from his posting to The Helix List:
"I have long felt that if Helix ownership (whoever it may be) would not support the developer community, it [Helix] was doomed. There simply are not enough of us independent users to keep it afloat. I know that Matt tells us that there are far more Helix users out there than there are developers, but developers purchase more software. If they don’t, they stop eating. Therefore, Helix needs developers. Users like me need developers."
Words like these have poured in this week off-list and on the phone. Yes. In the best of all possible worlds, Helix developers get more customers who in turn buy more Helix which in turn keeps the company going. This is and should be the baseline result of cooperation between the company and its developers.
In the second category, developers have responded with an odd mixture of appreciation laced with cynicism and fear. Clearly, developers agree with the (pardon the overused phrase) "win-win" nature of the proposition; I.e., successful developers means a successful Helix and vice versa. However, there’s a great deal of skepticism about the potential Pandora’s Box that opens when that phone call occurs.
One Helix developer expressed his concern this way:
"As you know, most clients that use Helix as a result of hiring a developer have no interest in Helix, and certainly don’t track Helix' progress (or lack thereof). They became Helix clients because their developer told them to use Helix. Helix only becomes an issue when the client demands features that Helix can’t deliver (OSX, Windows client) or has bug issues that are beyond the scope of the developer’s control. In these instances, direct contact from Helix could be valuable, and may buy some time before the client decides to go with an alternative platform."
And one very clearly reasoned suggestion included an important caveat at the end:
"I have a couple of nervous Helix clients who could benefit from a call from an "official" Helix spokesperson... not to lie to the client, but to make the client feel that they are important, and to put a somewhat positive spin on events. Something like:
'Hi, I understand that you are one of [Developer’s Name]’s clients, and I know you must be concerned about rumors regarding the future of Helix. We’re calling to assure you that we’re doing everything we can to secure the future for Helix. As soon as we have some news we’ll let you know.
Meanwhile, rest assured that you are working with one of our best developers and don’t hesitate to call if we can help you in any way. If you need upgrades to version 5.0.2 or additional client licenses, let your developer know, and we will work with [him or her] to give you a price break, and get you up and running smoothly.'
These calls should only be made at the request of a developer, or at least after talking with the developer."
Listen folks, we said we were going to work out the mechanics, and we’ve had enough great feedback already to start that process, but first, let’s go on record about a few things:
- We have not made one such phone call yet.
- We will not make one such phone call until we have some kind of consensus on what should be involved in that communication.
- We’re all very sensitive to the current situation of Helix, so please rest assured that if we did call one of your clients, we would not discuss that aspect of business with them at all. That we’d leave to you.
In fact, a significant rationale behind the desire to have a "developer customer registry" at all is so that we (I.e., "the company") will know when to stay out of the way of that relationship.
Let’s read that again: "Stay out of the way." Like in the Hippocratic Oath, where it says "First, do no harm."
We don’t want anyone to feel like we’ve gone off half-cocked, which brings us back to the big question, what can QSA ToolWorks do to bring more business to its developers?
We’re trying to discover the nature of the variable "x" in this equation:
[Developer] + [Work] + [x] = Happy Helix Customer
where "x" is either something QSA ToolWorks is, does, or does not do.
Naturally, we appreciate your feedback as this notion evolves. At the risk of raising expectations unnecessarily (or opening the aforementioned Pandora’s Box), let’s just say that we’re not doing this just for the sake of doing this, but for the sake of the future. We are committed to the concept that Helix will survive. When that day in the future gets here, we don’t want to first begin picking up the pieces and trying to reassemble a company. If we knew for sure that there was no future for Helix, none of this would be necessary, none of it would be happening and none of it would make any difference.
Gil Numeroff
And speaking of Pandora’s box, we opened one last week and found a whole bunch of interesting things inside that you might want. The first of these is available now at the Helix Web Store… (CD case — sold out.)