VOICE Home Page: http://www.os2voice.org
[Previous Page] [Next Page]
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
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,
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
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
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
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?