The Harbour Pilot

Vendor Hide and Seek

One of the challenges that has emerged over the past 15 years of software proliferation has been that software comes and goes. In part, that is the inevitable evolution of capability and functionality. In part it is driven by users demand for ever greater leverage of their investments in information technology. And in part, it is multiplied by the advances in communication, featuring, naturally, the internet. When you buy a house, you don’t expect to come home one day, and find that it has vanished, and so has its builder!

In the beginning, there was Unix – well there were a lot of operating systems, primarily proprietary mainframe hardware specific, but Unix was one of the earliest operating systems permitting users to sit at their own terminals and work. Unix was an early form of Open Source software (ignoring the arguments over ownership and licensing for now). As the desktop computer began to emerge, with its severely limited hardware resources, new operating systems were developed, many of them drawing significantly from the concepts used in Unix. Microsoft DOS (disk operating system) uses commands that are somewhat similar to Unix terminal commands (copy instead of cp, for instance).

Software for LANs also emerged (Banyan, Novell, Apple Talk), and so did application layer software (Lotus 1-2-3, SuperCalc, Wordperfect, Symphony). There have been thousands of such pieces of software, and heated arguments over superiority have raged for more than 2 decades. Software development was in its infancy, process, design tools, and documentation were indifferent, and so was quality assurance. And it was expensive, and very difficult to predict. This led to 2 related problems. The first was the notion of vapourware, as software houses promised release dates and feature sets that they could not deliver. The second problem was worse. Software houses went out of business…

An operation (business, government department, university, charitable group) would undergo a process of determining what software and hardware to commit to, to take advantage of new technologies. It is important to remember that there were at least 3 major components – hardware, operating system and application ware. All 3 had to match, and each of the vendors incorporated proprietary solutions into their products so that inter-operability was very poor. So our operation finally, after listening to all of the arguments, made a decision. It would take a year to make the decision, and then another year to implement and train everyone (at the best). Suddenly, one of the 3 went out of business…

Emerging from these situations was the understanding that it was imperative that vendors had to be qualified.

Vendor Qualifying Criteria

The criteria for approving a vendor included

• financial strength (they would not go bankrupt)
• quality assurance processes (they did not make junk)
• maturity (they would not have managerial upheavals)
• reliability (they were honest in their representations)
• support (since elements were proprietary, they had to provide support)

amongst others.

Although the world has moved on somewhat, adopting approved standards, reducing the level of proprietary technology (as a competitive edge), and increasing interoperability, the question of vendor quality is still a vital problem. IBM has had a difficult experience and reputation with launching and promoting software platforms, and then abandoning the products (and their install base) without much warning. Microsoft has not only been sued repeatedly for issues that turn on competitive abuse, but also has a challenging reputation for quality, reliability, support, proprietary file formats, and a lack of interoperability. So the issue should still be on the table.

Open Source Project Qualifying Criteria

Turning to Open Source, while the OSS projects and their products may not be “vendors” in the traditional sense, they are providers. The same questions need to be answered.

• The measure of financial strength of an OSS project is the depth of their professional technical project staff. As non-profit organisations, they may not have financial strengths in the same fashion as a for-profit corporation, but they do have budgets, they do have resources in volunteer contributions, and often, they have sponsorships and the long-term loans of technical resources from companies like Sun Microsystems, and increasingly, IBM.
• The quality standards of OSS projects must also be measured. Not all OSS projects are formally certified by QA process standard bodies, in part because those audits and certifications cost money, which OSS projects lack. Nevertheless, the project is likely to adopt standards informally, and at the top of their tool list is peer review. The code is published publicly, and anyone can access the code base and review it for potential vulnerabilities. Most of the time a mature OSS project will discover a potential problem area and publish it, well before the bug becomes a problem for the user install base. Bug tracking, resolution steps and progress, and changes to the code base are also completely public, and the development peers hold their own feet to the fire to address problems rapidly. In fact, the response time to bug fixes is very fast, and as a result, Open Source software continually publishes the latest snapshot of their code. Users of the Firefox browser can anticipate being notified every couple of days of updates, and they self-install easily as soon as you approve the process. This is in comparison to commercial software houses where bug fixes and patches are released, but often delayed until they can be built into a maintenance release – a much longer response timeline.
• Maturity is a loose description for the leadership of the provider of the software. While there are steering committees for the larger OSS projects, often made up of senior development professionals from sponsoring organisations, the project lead tends to be an identified and named individual – themselves a professional developer. Since the priority of both types of individual is NOT the financial stakes of the project, the focus of management is on the product – its quality, its ability to meet users’ requirements, and its efficiency and feature set. This compares very favourably with the best of the commercial software world, where the fiduciary duty to investors is appropriately, an overriding consideration.
• Reliability and trust can at times, be the basis for challenges from users to providers. That’s a delicate way to describe it, right? Well, it is really hard to obfuscate and mislead when the source code for the product is sitting right there in plain view to the development community. A little like a cat covering up on linoleum after an accident, isn’t it…
• Support – well that is a slightly different matter. The Open Source community are a technically literate group - when the software does not behave as expected, they can simply look at the underlying code and diagnose the flaw. In fact, they often go beyond this, fixing the flaw themselves and re-compiling the software, and then alerting the provider to the problem, the proposed solution, and having them modify the code base. Hmmm. Most of the user community have neither the skills nor the time to undertake this. Sooo, they must rely on other forms of support. Since no cash changes hand (other than donations), the expense of support can only come from the user community. Some projects have very low levels of support –sometimes even users’ guides and manuals are indifferent. To compensate for this, there are often at least websites that discuss the use of the software, what deficiencies they have encountered and how to deal with them. Better yet, the availability of wikis (encyclopaedia-like resources) and discussion boards has permitted better distribution of support information. In recent years, in addition to the volunteer development pool, there have also been volunteer support and documentation projects to accompany the software development. Where those exist, the OSS project can provide free support at least as comprehensive as the frequently non-responsive commercial alternatives. Lastly, there have emerged support operations who provide quality support in the form of help desks, for a fee. The more widely distributed OSS software offerings, with sizeable install bases often can point you in the direction os such a support provider. Decent quality software releases, that are themselves mature products, do not need such providers.

These are the issues to be addressed with respect to vendors when considering an OSS alternative

• How long has the project been around
• Who are the sponsors
• Is the project lead and the development team professional
• Do they support quality standards
• How many bugs have been addressed, and what is their response time for a fix
• How is their support documentation, on-line support facilities
• Do they support open standards
• How does the development community view the project
• Who has implemented the project’s offerings in their operation

All of this information is available – answering those questions should satisfy any vendor qualification process and provide considerable comfort with respect to their offerings.