VOICE Home Page: http://www.os2voice.org

[Newsletter Index] [Previous Page] [Next Page] [Features Index]

WarpDoctor: An OS/2 Watershed Event

By: Abel McClendon and Lynn Maxson

We have reason to believe that 12 million copies of OS/2 have been distributed, if not actually purchased. Of that number probably 90+ percent went into "enterprise" accounts (non-individual / non-SOHO). At its peak then OS/2 had possibly 1.2 million non-enterprise users. Of that number an undetermined fraction continue to use OS/2 as their desktop operating system of choice. They do so despite defections and the siren calls from other desktop OS alternatives.

That leaves us then with a number greater than one user and appreciably less than two million as the size of the OS/2 community. It's not knowing that number, not knowing how to reach them, and not having a gauge on their continued commitment that inhibits a service or product vendor on taking on the marketing risk of OS/2 development. If we who comprise the OS/2 community want to see our investment thrive and grow into the foreseeable future, then it is up to us to discover the number, be able to reach the community, and determine, if not enhance, its resolution to remain viable.

To that end VOICE has stepped in with the WarpDoctor project for which we(VOICE) need to determine these numbers, who they represent, and the scope of their needs in order for this project to succeed. WarpDoctor has the objective "to support the information, software, and hardware needs of the OS/2 community". It cannot succeed without first reaching the community and the community in turn expressing its needs. Moreover the larger the community the more the needs and the greater the cost of supporting them. Though initiated with a dedicated core of volunteers in this its startup period, they cannot sustain the effort on a ongoing, long term basis. Therein lies the crux of the matter.

WarpDoctor will be a support system. Like any system it requires (and consumes) resources. Proper preparation says that we must engage in capacity planning, the amount of resources necessary to meet expected demand, and scalability, the ability to match resources to actual demand. Both of these, capacity planning and scalability, are demand-based.

This creates a problem for any system initiated with volunteer resources--people, hardware, software, or other--that demand could exceed capacity, that the volunteered resources will not scale up to demand. For example, we will implement WarpDoctor as an internet application. This means it will have a dedicated website. Currently the resources (space, communication lines) for that website have been volunteered as shared within a larger environment. We have given no consideration to the possibility of its growing to the point of becoming the dominant consumer of the shared resources.

Let's understand that volunteers must not jeopardize their regular income sources by spending too much time or money on their volunteer work. Thus the number of volunteers available is a limiting factor on the growth of the project as a volunteer effort. If the project grows beyond that limit, other means of funding must be sought. Whether such means will be needed, what they might be, and their potential extent, must be discovered.

At the moment the only funding source available to VOICE comes from its members who pay an annual fee. An individual membership is $25 annually. Clearly, this limits the funds available for this project. VOICE needs at least 100 times as many members as it has at present, to gain necessary funds so that it is not necessary to continue volunteer support for WarpDoctor indefinitely. The challenge that the initial, volunteer-supported, WarpDoctor faces is that it needs to be so valuable that it will attract new members in such quantities that volunteer resources could be gradually reduced and the project would become funded and continue to grow.

WarpDoctor represents a serious risk to VOICE. It is one thing to see what you can achieve, what demand you can meet, with volunteered resources. It is another when they are inadequate, when the actual demand exceeds available or planned-for capacity. It creates a sense of failure, inadequacy, or disappointment in the minds of its users, those creating the demand. That in turn will have a negative effect on the rate of new members, the only source of increased funding.

Moreover WarpDoctor has competition as there are a number of other internet-based sources, most of which offer free-access and are volunteer-based only. Now WarpDoctor offers free access with expectations that its higher service level, its ability to satisfy user demand, and its higher response level, as well as it's ability to minimize user time and effort, relative to other sources will translate sufficient numbers of users into members.

WarpDoctor then must transcend the "nice" level of its competitors in the minds of its users to a "needed" one, to where the user perceives the continuing value received (at least potentially) well worth the cost (of membership). This transcendence, this thing that separates it from its competitors, has to be in place at time of takeoff, at general availability.

Now VOICE itself through its board of directors does not view the other offerings as competitors. It supports anything that supports OS/2. It wants no harm to come to them and certainly wants to see them continue and grow. What it would prefer it to somehow meld them within WarpDoctor. Unfortunately the technology associated with the internet makes the connectivity a non-issue, given that certain sites already offer links to "hundreds" of other sites. They do so without realizing that those links themselves, particularly as their number increases, becomes daunting to users, discouraging them from seeking farther.

Anyone who wants to offer a service must exhibit a sensitivity to demands on a user's time. Not only must they provide the service (the service level) but do so with minimal demand on the user (response time). The issue then is not how many connections, how many paths you make available, but in how short a path you provide to fulfill the service. If you view your service as simply providing connections, then you need go no further. If your service is to provide answers (solutions), then you must reduce the connections the user needs to traverse. You must assist the user throughout his journey.

We know the OS/2 community is an international one. Simply counting the different languages supported by the fixpaks for OS/2 we have over 30 different languages. We have some reason to believe that over half of the OS/2 user community is non-english-speaking. We cannot help someone if we cannot communicate with them. Thus we need to consider offering multi-lingual support.

Very quickly what begins as a simple idea of providing a website with an information database plus an intelligent search engine starts to fall apart as we examine them and their consequences more closely. It works for english-speaking users, but denies them access to non-english information sources. We could offer multiple language-specific search engines, but what if they don't exist or require different information databases. Clearly the narrow view that we individually might hold on what is necessary must expand when we take the aggregate view (and needs) of an entire community.

It has to consider how it determines needs. We may decide to determine needs strictly on demand. Even at that new needs may arrive at a rate that exceeds our capacity to respond to them. That develops into a backlog of needs. Now we could take them on a FIFO basis, allowing the order of demand to determine our allocation of resources. Or we could use a priority system, somehow rating some needs as more important than others. Or maybe we could organize them into needs categories and prioritize the categories as well as the entries within the categories. Regardless of any choice we need to keep the backlog within reason, below the point at which the user perceives the service as non-responsive.

Actually it gets even more basic. Who determines needs, sets categories, establishes priorities, and allocates resources? Who better than the members funding the resources? That separates WarpDoctor from its competitors (volunteer-based and -directed). That makes it member-directed as well as member-based. That in turn creates its own challenge.

For now the members must have a means of viewing needs, organizing them into categories, prioritizing them, and then determine when to allocate resources. That implies an ongoing means of raising issues (needs), discussing them, determining their importance (prioritizing), and then their order of implementation (resource allocation). Both the prioritizing and allocation require some voting mechanism that supports the dynamics of changing needs.

Technically with the exception of the backlog (unmet needs) all these are solvable. The backlog is strictly resource dependent. The only means currently of having sufficient resources lies in membership funding. Thus VOICE to have WarpDoctor perform as desired must also have a membership to match. That membership will come from the OS/2 community who can vote to support WarpDoctor by joining VOICE. The larger their vote the more resources available to WarpDoctor. The more resources available the more needs it will meet.

While WarpDoctor is a test of VOICE and its volunteers it is also a test of the OS/2 community. Is it large and interested enough to sustain funding an increasing portion of its support needs in information, software, and hardware? As volunteers we are working with other volunteers to make WarpDoctor a reality. While we may suffice to get it underway we know that we need the OS/2 community's support to take it to the level necessary to make it the premier offering of its kind. We think the OS/2 community is worth it. Does the OS/2 community feel the same way?