head: Making the Unix Case: saving Impress Recruiting

DECK: Author Paul Murphy's previous Linuxworld article on making the Unix decision suggested that Unix is usually a smarter business choice than Windows. The current article, second in a series, looks at what it takes to implement that knowledge in a small business.

Note

The "I" in the scenario being explored is that of a consultant asked to make strategic systems recommendations for a small software development house. The company, its staff and products, are fabrications but the situation presented, and the remedies offered, reflect the author's recent experience with real-world clients facing similar decisions. Impress Recruiting is imaginary, but the conditions, decisions, and outcomes described are broadly based on real events.

Background

Impress Recruiting was founded in the late seventies as a software commercialization spinoff from the highly successful management and outplacement consulting firm of Kutting, Cash, and Dole. The product, marketed under the Impress name, was originally built in Cobol-74 on Burroughs A-Series gear. It started as a resume summarization and retrieval tool for recruiters but became, over time, a full featured recruiter time management system aimed at small to mid size temporary services agencies.

By late 1986 Ayer McReady, the original designer and a co-founder of the firm, had supervised porting to SCO Unix with VT220 style terminals. Version 3.0 supported up to 32 users communicating via a serial line multiport board with an i80286 based machine and was written largely in RM-COBOL with a Unify 3.0 database backend. Networked Windows clients were added in 1990 and, by late 1992 the company claimed more than 300 client installations supporting over 4,000 active recruiters in three countries.

In 1996, four years after Mr. McReady's retirement, the company responded to perceived market pressure for an NT server based solution by offering a completely rewritten release featuring a Sybase 4.91 backend that ran on both the old SCO environment and the new NT one along with a fat Windows client written mostly in BASIC.

Over the next four years new sales disappeared as competition intensified, support costs rose 25 percent per year, and existing customers started to drop off support as they found new software or were merged into larger companies with other software preferences. A new product development effort, intended to revitalize sales, was started in 1998 for the NT4/Windows 98 architecture but produced no new sales when released in early 2000 in part because of incompatibilities with Windows 2000. Conversion costs looked high and sales prospects poor so the decision was made to let the developers and marketing people go and to stop efforts to port Impress to newer Windows environments.

By August of 2001 there were only 93 companies on support, accounting for a total of 988 licensed seats with about two thirds of them using still SCO 5.4 and the remainder on NT. A further 18 companies, all SCO users and accounting for 431 licensed seats, continue to use the product but do not pay for support contracts.

Client interviews show the usual combination of personal loyalty and resistance to change. Much of the gear in customer hands is obsolete with over half the recruiters unhappily using Windows 95 on 15" screens but little management concern about modernization evident.

Current revenues, from support, training, and some custom work won't make $250,000 this year; cash is down to nearly nothing, and the family has warned the remaining seven employees that the company may be closed. There's talk about an employee take-over and about using dot net and XP, but that's all it is; talk. Most of the staff focus on day to day activities with no clear vision and no driving force behind their efforts.

Angela Lieberman, grand daughter of the original McReady and current general manager, says that the family is willing to put some push behind the company if it can be saved but won't front another nickel in guilt money.

My job is to help her decide what to do: fold, sell out to a larger firm that wants her client base, or attempt to re- invigorate the company with new products or services? Folding isn't a real option for her and the only company to approach her with respect to a sale in the last six months didn't offer much in the way of value. My real job, therefore, is to devise an action strategy to save the company.

The Plan

That strategy is Linux. The question here isn't what to do, but how to get it done.

She needs to:

  1. commit to develop, sell, and support a new Linux based product suite;
  2. build a changeover support package for her customers that combines financing, some remote processing services, training, and new business opportunities for those customers;
  3. aggressively pursue the 18 current users who don't pay support by asking for their involvement and offering them an opportunity to get the new software cheap later by signing up for support now; and,
  4. move her design focus for the software up scale from the small, owner managed, companies she mainly works with now to larger, multi-site, organizations made by consolidating the smaller agencies under professional management.

Unfortunately this isn't what the staff expect me to say. Most are resigned to failure and treat me as if I dressed in black robes and carried a scythe. Because it isn't what they expect, just saying it in a report and repeating it in a presentation isn't going to cut it; the company would just pay my consulting fees and carry on dying.

Actions

What I'm going to have to do is re-motivate, and quickly enough that my fees don't become part of the problem. As part of that I've got to get them to buy into two things:

  1. that there is value and opportunity in going ahead;
  2. that they can do this without becoming somebody else,
and make one informed decision: do they use licensed or freeware tools for the new system?

To do this I'm going to call an all day staff meeting around a before-and-after comparison followed by a question and answer session.

The comparison will be based on the last real sales pitch, from October of last year, made to a Mrs. Flo Updegraph of Wagner, Wisconsin, in which they offered a ten user system for around $28,068 installed -- of which only $8,750 (31 percent) was in Impress license fees.

That's the key point: from the Impress perspective this sale had a potential cash value of only $8,750 - not the $28,068 they asked Flo to write checks for. The 69 percent of this for which success would get them nothing was made up of 10 Dell Dimension 4100, 733r PCs running Windows 98 with Office 2000 and a Dell 1300 with an 800MHz PIII running NT small business server. This represented the minimum in Microsoft licensing and hardware for their software to work - and more than two thirds of their sale by value.

The money was a killer issue for Mrs Updegraph but the tactical mistake that doomed the sale was mention of Microsoft licensing requirements for the new gear. Most systems people take this stuff for granted and see a clear distinction between the cost of the package ($8,750) and the cost of the third party products needed to run the package ($19,318) but Mrs. Updegraph doesn't. She's a small business owner spending what she sees as her own money. As far as she is concerned, she already owns Microsoft office because she licensed Office 5.0 for a 386 back in 1990 and has been cheerfully copying it ever since.

She knows, of course, that this is wrong but denies it to herself; so holding her feet to the fire on PC upgrades and Windows licensing was the right thing to do, but after that meeting she was never heard from again and did not return calls.

That's what happened then, now the question I have to get them to think about is: how would this situation play out if Impress were available as a Linux product using a browser based client?

The big picture answer is that this would allow the sales presentation to draw a clear distinction between Impress and Windows related costs. The small picture answers are:

  1. that it saves money; and,
  2. that it would minimize downstream support and change costs.

Since nearly every client wants a total cost picture, Impress could offer ten 15" network appliances from Thinknic at $320 each with a Dell 1400SC server at $1,932 for a 1GHz machine with 256MB, two 18GB disks, and a 5/10GB tape with Red Hat 7.1 pre-loaded. That would yield a total cost of $13,882 with 63 percent of it for Impress software.

The separation issue is crucial here. Using today's pricing instead of last year's for both alternatives, the fact that the client would now be asked to pay $13,800 up front instead of $25,271 is obviously important but cost attribution is actually more important. In the Windows based sales pitch the cost of adding Windows services is sold as part of the Impress decision; in the Linux version it is a separate issue.

Her recruiters will still need to use a word processor that can read Microsoft Word files and she knows it. By pointing, in the configuration proposal, at the use of the X client built into the thinknics and suggesting use of the OpenOffice.org under Ximian Evolution, Impress achieves three things:

  1. they give Mrs Updegraph a way out of the trap she's got herself into by illegally copying Microsoft applications because adopting Openoffice.org lets her stop doing things she knows are wrong without forcing her to abandon her rationalizations for doing so;

  2. they cast themselves as heros, the people whose open software inter-operates with anyone else's and who have the technical smarts to make things happen at a reasonable cost; and,

  3. they show their understanding of her business needs and the staff training constraints she works under.
The net effect is the positive opposite of what happened last year when Impress needed to enforce Microsoft license compliance as a condition for making their own sale; now they wear the white hats of rescuers instead of the black hats of enforcers.


Impact of Change to Linux
  1. Clear separation between Impress and third party costs
  2. Impress share of total sale increased from 35% to 63%
  3. Customer Capital cost cut by 45%
  4. Customer 5 year cost reduced by 48%
Effect of Change to Linux
Before Changes After Changes
Cost of Impress Licenses $8,750 $8,750
Cost of Server with 10 desktops1 $16,521 $5,132
Total cash cost $25,271 $13,882
Estimated five year cost2 $47,800 $24,820
Percent of deal on which Impress makes a margin 35% 63%
1Current costs are from the vendor web sites as of Nov 11/01.
2Impress Support costs are 25% of base license cost per year.

When I get Angela to call a staff meeting, tell them that their future lies with Linux and FreeBSD, and then present these two scenarios it immediately becomes obvious that most of them have deeply conflicted reactions. They came to the meeting expecting to be told when, and in what order, they would be laid off and the company closed. Instead I'm offering them a route to future success and this is deeply resented. At some gut level most of them would rather have had their expectations met and the company closed than that some arrogant stranger should come in and tell them how to run their business.

It takes all morning to present this case and work through the cost comparisons but by noon a few are starting to see past the cost differences to achieve some understanding of how Flo Updegraph would see it. They know her, in one form or another her attitudes reflect the client base and they're doing something they've never done before: looking at those Windows costs from the perspective of the small business owner.

As a breakthrough this calls for a lunch to let it sink in; the afternoon, I tell them, will be devoted to answering their most immediate questions about the proposed changes.

The first questions are predictable:

  1. four of them claim good SCO skills, how portable is this to Linux?
    I tell them that the core concepts are the same, only the implementations differ. Some of the program names are different, some of the arguments are different, there are some shell level differences, and back-up and recovery are unrecognizable; but really it's like switching from a GM car to a Ford - if you know how to drive, it doesn't take that long to figure out where the horn is or how to unlock the gas cap.

  2. They've become used to thinking of PCs as the default desktop. To them, a smart display is a new idea, so they want to know how well a Thinknic works relative to a client PC?
    I tell them that I don't recommend 15 inch screens for real work but that, within that limitation, they're much more reliable, and far simpler than PCs. Given that the clients now generally use tiny screens, the Thinknics offer a great solution that meets customer expectations for desktop use while establishing a uniform browser environment easily duplicated on notebooks and other portable gear. They're perfect, too, I tell them, for home access by recruiters since they're basically foolproof and easily secured. Head's nod, that's a problem a lot of their customers have.
    Still a 15 inch screen is quite limiting, so I talk about upgrade options; about 17" flat screens on other thin clients, about adding in more document processing using 21" high readability screens, about using Sunrays in secure environments or NC900s in high flexibility ones, and about extending their software's reach to much larger customers with much more diverse concerns.
    That gets attention. They're not ready to understand that Windows is brand, not a product; but they've looked at upgrades for existing Windows 98 customers and know that a faster PC with a bigger screen is only that - a faster PC with a bigger screen. As long as it runs Windows 98 it can't be used to do anything its predecessor couldn't. When I talk about adopting the right technology for the job and point out that the Thinknics do one job extremely well but are inappropriate for other jobs they're ready to articulate their own frustrations, as developers, about PC upgrades not leading to exploitable technical consequences.

  3. One of them asks about bringing some of the gear in for testing
    That's the key step of course; get them involved, show them results, and they'll be on board. Angela sees this, leaps in: "we'll order four tomorrow", she says, "and Paul will help us set up that old HP E40 (the Pentium-Pro box, not the earlier PA-RISC one) we have as a Linux test server."

  4. They start talking about making that work. One admits to having Linux on a home PC, someone formulates the application transition question.
    The application is now mainly expressed as stored procedures tailored to Sybase for the SCO solution and to SQL-Server 6.0 for the NT one. There are still lots of COBOL programs for both as well as some C for the SCO solution and BASIC for the NT one. The client, of course, is entirely BASIC, how will all this get converted to Linux?

    That's both a very difficult, and a very easy, question. The client, of course, disappears from a maintenance and development perspective; they're going to develop for display on Netscape, Konqueror, Opera, or IE on a lowest common denominator basis. That leaves two very important issues with respect to the application:

    1. they have to decide how far they want to go in getting away from selling other people's products; and,

    2. they have to decide whether they want to port the existing release to Linux or develop a new foundation product for the next evolution of Impress.

    They could decide, for example, to simply port existing functionality to Linux by adopting Sybase and doing the minimum amount of recoding and testing needed to get things to recompile and run properly on Linux. That, I tell them, will be a matter of a few weeks of work most of which they can do themselves although I strongly recommend bringing in a Syabse expert with serious production experience to help them get the core scripting and database controls right. This causes some resentment because they know Sybase 4.91 quite well, but, of course, Sybase 12.5 is not the same product. Most of production oriented services they're experts on for 4.91 are now fully automated but - and this is something I tell all my clients - only production experience fills the gulf between good tools and and smooth operations. Learning from an expert is always faster and cheaper than learning from experience.
    A more interesting decision would be to re-write the entire system in a completely Unix-consistent architecture. This, I tell them, isn't nearly as difficult or risky as it sounds because they would not be developing code in the sense that they understand that process now. For most business purposes, Unix development is no longer about application coding, it's about application assembly. Take pre-defined pieces developed by others and either string them together to do what you want or modify them a little bit and then string them together. No different in principle from using pipes to form complex processing applications by stringing together simple utilities, this process is enabled in both freeware and licensed forms.
    The real question is whether to use freeware like Perl and PHP with PostgreSQL or a comprehensive licensed environment like Unify Vision. In both cases, I tell them, getting experienced help will be crucial. A good Vision programmer, or comparable PERL wizard with business and PHP/Apache experience, could probably work with two or three of the current staff to assemble a new generation Impress in three to four weeks.

    This, of course, meets with deafening silence. They know this is wrong; just defining screen handling takes weeks, even in BASIC on a Windows machine.

    I tell them that this isn't about programming as they understand it. Just learning mod_perl or PHP is trivial, give any of them a book and a few days and they'll be experts. Unfortunately they'll be extremely unproductive experts because the real wizardry doesn't come from understanding the language concepts or even specific structures; it comes from knowing what libraries to use and what's in them. You don't get that kind of facility in a day or two, it takes a year or more of daily use to get close to proficiency.

    But, put a couple of domain experts - like them - together with someone who has the needed facility and the team can assemble a working application in an unbelievably short time because the pieces are essentially pre-defined.

    So the real question is: where are the skills and pre-tested, pre-defined pieces going to come from? Go with a high end environment like Vision and they'll be selling Unify, or whoever they go with, as part of every deal. Go with an all open-source production and they have to be prepared to open-source a lot of their own stuff. The freeware community is symbiotic, I tell them, you take what you need, you admit it publically, and you put back what you can for other people to use.

    To them this is obvious nonsense. Source code control is at the root of their product control; letting other people use their code is so self-evidently absurd they think I'm not serious. But I am, the various public licenses boil down to fairness and they need to understand what that means if they want to use open source components. The real bottom line is that their future success with Impress doesn't depend on source code control anyway; it's domain knowledge and customer relationships that matter. Right here and now, however, they're a tough crowd and I'm not pushing it; even though, in the long run this is the way most small developers are going to have to go.

  5. They already know how most of their customers will react but finally someone asks the business question: customers on support are entitled to new releases automatically. If they get the other 18 back on support too, who pays for the work needed to get the upgrades ready, tested, and installable?
    Angela fields that one. If the conversion looks good and the uptake among supported customers is strong, the family will put money behind a marketing push. Restart the company, configure for growth, and go after new accounts, new services, new business.

  6. But will it work? Lots of heads nod as one staffer expresses concern about using open source software for mission critical systems. "If we do this", she asks "aren't we lowering the barriers for other companies to grab our customers? They'll want to continue with Microsoft and see us heading for dreamland, couldn't someone who caters to that attitude just snap them up?
    A few customers, I say, will undoubtedly defect. They'll point at the use of Linux as a reason for the change but you can bet that a lot of these guys have employees agitating for change to some other package right now anyway -so you're going to lose some no matter what you do.

    The real issue here is defining the Impress product. Do they sell software or knowledge? Did their COBOL coding skills keep them alive for so long or was it their knowledge of the industry? There are better products out there - are those 111 user companies just too lazy or stupid to change or is there something else keeping them loyal? Like maybe their knowledge that you understand their business, that you guys are there to help? It's the business knowledge and relationships that matter, I tell them, not the code. That's why adopting Linux isn't what's going to save this company, it's letting go of the Windows cost anchor that will free you to succeed.

  7. In the resulting silence, someone asks: "are there other business opportunities that go with this?
    Angela takes this one too. "There are," she says, "but we haven't explored them yet. We can look at things like remotely managing client systems for them, like doing batch document conversion using our own in-house systems in an ASP model, offering our customers an easy way to connect their data to the personnel systems maintained by their clients - again using an ASP model; or maybe building a web style portal aimed at enabling resume and commission switching among our clients - giving them a competitive advantage on larger contracts. Lots of things to look at and some, I'm sure, will pan out when we look at them closely."

It isn't that much, but it's enough. Suddenly there's hope in the room, I'm forgiven for not shutting them down and talking about open-source. I'll be here for the next few days setting up the test system and answering questions, but really my work is done.