Comments: Gated by NETN...@AUVM.AMERICAN.EDU
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!paladin.american.edu!
auvm!NDSUVM1.BITNET!NU021172
Return-Path: <@AUVM.AMERICAN.EDU,@VM42.CSO.UIUC.EDU:owner-powe...@VM1.NODAK.EDU>
Return-Path: <@VM1.NODAK.EDU:NU021...@VM1.NODAK.EDU>
Message-ID: < POWER-L%93062310024496@VM1.NODAK.EDU>
Newsgroups: bit.listserv.power-l
Date: Wed, 23 Jun 1993 10:01:18 CDT
Sender: POWER-L IBM RS/6000 POWER Family < POWE...@NDSUVM1.BITNET>
From: Marty Hoag < NU021...@NDSUVM1.BITNET>
Organization: North Dakota Higher Education Computer Network
Subject: Whitepaper on Open System Process Acceleration
Lines: 758
The following was issued as a press release by IBM recently. I thought
it might be of interest to some of you. (I will also store a copy in the
POWER-L archives as ANN6000 PR930611). Marty
WHITEPAPER ON OPEN SYSTEM PROCESS ACCELERATION:
A COMMON OPEN SOFTWARE ENVIRONMENT
June 11, 1993 (From IBM Press Release)
NOTE: A printed copy with several diagrams included is available
through the UniForum Assocation, Richard Jaross, 408-986-8840.
Overview
The common open software environment process came into being
as six of the major UNIX* System suppliers recognized that
more effective cooperation was the key to meeting
the demands of users for consistency and interoperability
among software suppliers. While the initial announcement
highlighted specific technology areas, the intent of the
companies at the announcement was to accelerate the process
by which open system software specifications are defined and
submitted to recognized industry standards forums.
Of course, this can be achieved only if the open system
industry rallies around the proposed process acceleration.
The purpose of this whitepaper is to lay out principles for
such process acceleration and then to stimulate its
adoption, benefiting customers and the industry through
increased growth and innovation in the open system
marketplace, in which the companies will continue to compete
vigorously. The proposed process acceleration is intended to
work with existing industry organizations to achieve faster
consensus among more vendors.
This whitepaper incorporates input from sources throughout
the open software industry as a result of many reviews and
intermediate drafts. Nevertheless some important points will
have been overlooked and further evolution will be necessary
for the open software industry to continue to improve its
competitive position. Feedback and conversation are
encouraged through the avenue given at the end of this
paper.
The audience for this whitepaper includes OEM suppliers of
open system software, independent software vendor suppliers,
and end users, all of whom depend upon a fair open
specification process, and will benefit from any process
acceleration. This whitepaper is also addressed to
existing consortia, which have already made substantial
contributions to the open system process, and are in a
perfect position to make even greater contributions with the
support of this acceleration.
This whitepaper has five major sections: First, a
demonstration of how this process will expand choice for the
customer of open system technology; Second, a proposed
evolution of the existing process for specifying and
implementing open system software; Third, an explanation of
how this process would work in practice; Fourth, a set of
principles that apply within the open system industry;
and Fifth, the stages in the life cycle of software
technology. An Appendix describes some tactics for how to
get involved.
The paper proposes no new organizations. Existing
organizations have accomplished much in the open systems
arena and will benefit from these accelerated processes.
This paper describes process and principles. It does not map
these onto existing industry organizations, except for
X/Open, whose specification, certification, and branding
process are widely recognized as the most comprehensive and
wide ranging in the industry. These make an excellent model
for the common open software environment process.
This overview section concludes by breaking apart the phrase
"common open software environment."
Common
Users have made it clear that they need system software to
be ``plug and play'' compatible between vendors. It is not
enough for each software supplier to provide self-consistent
software because that forces users either to make a
long-term commitment to a single supplier or to face a major
upheaval if they decide to change suppliers.
The common open software environment process will make use
of existing processes for specifying and deploying industry
standard software to help users determine when their
suppliers are providing compatible standard software and
when they are not. Specifications and branding will be used
to make this distinction clear.
The primary benefits of common specifications for industry
standard software are application portability and
interoperability. As application writers observe that the
same environment exists throughout the open system industry,
and as they realize the benefit of stable, open
specifications, they will be drawn to make more
and more applications available.
Open
One important use of "open" applies to the inclusive nature
of the process for defining and then approving
specifications. Such a process is open if ample opportunity
exists for every voice to be heard. Openness in this sense
is assured in the common open software environment process
by the active solicitation from working groups for input
from the industry, and by the use of existing
consensus-based standards organizations, such as X/Open, for
approving specifications. In order to achieve the consensus
necessary for approving specifications, participants in the
common open software environment process will need to
encourage early and frequent review of draft specifications.
A second important use of "open" applies to technology,
where it has been used generally to signify a programming
interface documented for others to use. Participants in the
announcement of the common open software environment
intended to clarify the definition of industry standard
"open" technology.
Under this clarification, a technology can be called
industry standard open only if there is available a detailed
written specification that governs correct behavior, and if
implementation of complying software is unrestricted (e.g.,
it is not required to go to any particular supplier for the
authorized software). Much current open system software
already meets this definition, but some does not. As a way
of demonstrating this new standard, X/Open is now applying
its specification requirements to two technologies that
formerly did not meet this test: OSF/Motif, and Novell
NetWare UNIX Client.
Vendors who implement to these specifications will be able
to receive the associated X/Open brand no matter how they
achieve the implementation, as long as they pass the
necessary tests. Industry standard open technology is well
specified, is endorsed by a recognized standards
organization, and can be implemented to the specification
without encumbrance. Source technology and sample
implementations should be licensed readily and equitably to
the industry with equal and early access for anyone.
Software Environment
Software Environment means defining a standards-based
environment for the building and deploying of complex
applications in a hardware neutral way. Thus the common
open software environment process results in products that
give users a choice of hardware vendors that does not limit
their software options.
Foundation for Customer Choice
With the success of the open systems comes an expanding set
of specifications of widely endorsed and broadly available
programming interfaces. In the open system environment,
customers are able to select a supplier of a particular
solution without limiting their future options for choosing
a different vendor for another solution.
Many vendors in the open software industry are determined
to define fully compatible software interfaces that
customers will find on all platforms bearing a common brand
for particular technologies, with brands controlled by an
industry neutral standards organization.
Like the companies that recently announced a proposed
standard for HDTV, the members of the open software industry
are banding together to propose standards for fully
interoperable software. Then, like the suppliers of HDTV
equipment, these vendors will compete vigorously against
each other to sell their own particular product.
More specifically, the products that result from the open
software process will benefit developers, administrators and
end users by expanding their choices now and for the future.
For application developers, common open software products
offer easier access to an expanded market. Developers will
be able to focus on development needs, not on rationalizing
middleware differences, because specifications and brands
will assure them of the compatibility they require on
systems from different vendors. The efficiency of
application creators will increase along with innovation
resulting in improved availability of application titles for
end users.
For system and network administrators, common open software
products offer easier system and network expansion. Again,
the specifications and brands will assure such
administrators of the compatibility of systems from
different vendors, thus accelerating the availability of
single point multiplatform system management capability.
For end users, they bring a consistent look and feel on the
desktop. Interaction with the computer is intuitive and
users can move from platform to platform with the confidence
of familiarity. User productivity will increase through
reduced training and education expense. The common
environment will increase the number of available
applications by simplifying application development, thus
benefiting everyone.
Finally, system integrators will have available to them more
competitive choices for compatible systems, since any
vendor's product that conforms to the appropriate
specifications and carries the associated brand will provide
equivalent functionality. Efficiencies realized in system
and network administration will be passed on to users as
lower cost of support and reduced downtime.
Thus all these customer constituencies will be free to
select a vendor today without limiting their choices for
tomorrow. The open software specifications provide the
foundation for choice. The common open software environment
process accelerates the adoption of standards.
Adding a Catalyst to the Open System Process
Technical innovation and user requirements have
traditionally driven companies or groups of companies
to create solutions for the computing marketplace.
Companies then competed for customers on the merits of their
individual products. Sometimes this meant the products
would work in multi-vendor environments and sometimes not,
but in any event customers made their choice evident by
their purchases.
As de facto standards emerged from the choice of users, open
system providers have negotiated specifications through
standards organizations, and implementations of these
specifications have become available across the majority of
vendor platforms. Thus the amount of common open software
has grown over time.
In an effort to accelerate the availability of open system
specifications, the common open software environment process
describes a catalyst to the open system process. The
catalyst is inserted in two phases of the open system
process. First, at the point before formal submission of
specifications to recognized industry bodies, working groups
comprising representatives from the major interest groups in
the open system industry will try to come quickly to
consensus on a common recommendation. Then submission to
the industry standards organization will allow the
specification to be reviewed widely and approved more
quickly.
Second, in some cases cooperative development of an initial
implementation can help to further coalesce the standard to
promote compatible product solutions while accelerating time
to market. A complete specification, with an implementation
that supports development of a comprehensive test suite will
be a catalyst to truly consistent APIs and behavior.
This initial implementation will be licensed and made
available readily and equitably to the industry at large.
Both of these catalyst activities directly benefit the
industry by reducing costs, and directly benefit users by
reducing fragmentation.
Acting only as a catalyst to the existing open system
process, this proposal adds no new process stages or
organizations. Existing open system initiatives such as
OSF, POSIX, UI, and X/Open, which were formed to provide
open specification forums, among other services, have laid a
solid foundation for the current acceleration. Their best
practices, such as requests for technology, member working
groups and early access to code should be retained.
The acceleration of the common open software environment
process should make it easier to form working groups with
broader representation than heretofore. The opportunity
exists for a significant degree of synergy among these
organizations.
How the Process Would Work in Practice
Central to the above process is achieving consensus to
endorse a specification of particular technology behavior
which then gets formalized at a vendor-neutral industry
organization. For this to happen, some forums must exist for
conversation at several levels. This section describes how
that might work.
Formation of ad hoc working groups
There are plenty of examples of successful multi-vendor
solutions emerging from cooperation among open system
vendors, and many of these have come from ANSI, UI, OSF, and
the X Consortium. The companies that announced the common
open software environment spanned membership of these
organizations, and will work with these groups to come
quickly to recommendations on open system specifications.
Ad hoc working groups may be formed in some technologies as
a way to get started on rapid progress while the existing
industry infrastructure evolves to accommodate the breakdown
of old barriers, while preserving the vital roles of
existing organizations.
There's a well-known trade-off between the size of a group
and its ability to make rapid progress: smaller groups move
more quickly. There's an inverse trade-off between
the size of a group and an ability to reach approval in a
broader community: results of a larger group effort gain
broad approval more quickly because the direct involvement
of more affected people exposes more problems sooner.
The dilemma for the common open software environment is to
form working groups sufficiently small to make rapid
progress, and sufficiently large to account for the needs of
a broad enough community. In part this can be accomplished
if a smaller group takes the lead and solicits input from
the broader community. Such working groups should therefore
make themselves known by a public declaration, stating the
problem on which they will focus, who the participants are,
and how others can make their input known.
In all cases recommendations of these working groups will be
submitted for widespread review and finalization by
recognized industry organizations. The composition of
working groups should draw upon companies who can foster
the success of the particular areas of technology, and is
not limited to any specific set of companies.
Preparation of Formal Specification and certification tests
Each working group is to be charged with producing a
detailed formal specification that meets the open definition
above and that can be handed over for consideration by a
certification and branding program at the close of the
project. It is expected that the certification and branding
program would be managed by a neutral industry group such as
X/Open or the OMG.
After the specification is finalized by a body such as
X/Open, the working group members could also assist the
standards body by providing it, either directly or
indirectly, a set of certification tests of sufficient
completeness and quality to be used in a branding program.
This body would evaluate the tests and coordinate as
appropriate with the working group to reach the necessary
test quality.
After both the specification and the tests are accepted
then a complete branding program can begin, and individual
vendors can cite conformance.
The catalyst added by the common open software environment
process is the discipline of requiring working groups to
define and publish a draft specification, to provide test
suites appropriate for branding, and to deliver an equitably
licensed sample implementation.
Sample Implementation
Implementations of the specification could come to the
marketplace in any number of ways. In some cases, industry
members may want to cooperate in the development of a
implementation of the specification. In others, one or more
individual vendors might have implementations that others
could license.
Early availability of an implementation for use by multiple
vendors can help achieve a solution with uniform
compatibility and consistent behavior. In all cases, the
common open software environment process requires a readily
licensed sample implementation, available consistently to
the industry. In any case, any vendor is free to develop
its own implementation of the specification.
Key points of common open software environment process
There are five key points to the common open software
environment process, reflecting how it works to provide a
catalyst to the existing open system processes:
- System suppliers come together in a working group
to accelerate the recommendation of a draft specification,
in a specific technology area.
- Each draft specification will be submitted to a recognized
industry body for broad review under established
processes, and, if accepted, will provide an unencumbered
specification to which anyone can build an implementation.
- One or more sample implementations should exist for each
specification so that any interested vendor can exercise a
make/buy decision. These implementations should be readily
and equitably licensed to the industry.
- Test suites should be available for certification and
branding to the specification.
- The process allows for different companies to participate
for each technology area.
Principles of the Process
This section describes the acceleration from the point of
view of the participants: contributors to open system
specifications and vendors of open system products.
Contributors
To demonstrate a commitment to the principles of the common
open software environment process, suppliers of open
software technology would:
- Accelerate multi-vendor definition of a draft
specification ahead of the standards setting organization
if necessary, by participating in ad hoc groups
representing a critical mass of the open system industry.
- Submit an unencumbered draft specification to an industry
review and adoption process, and abide by the decisions of
specification reviews.
- Ensure their implementation conforms to a rigorous
specification, certification, and branding mechanism.
- Allow the building of unencumbered (no royalty) common
behavior implementations to the specification. (Any
necessary patent licenses should be openly licensable on
reasonable terms and conditions consistent with standards
organization practice.)
- Encourage availability for open licensing of a sample
implementation and certification test suites, including
early access to source code to ensure rapid deployment.
- Compete vigorously against each other on the basis of
quality implementation, service, support, price, and other
added value.
Vendors
This same set of principles can be extended to what vendors
of open system products can expect of the common open
software environment process. Vendors of products that
emerge from the common open software environment should
expect:
- that the specification will provide sufficient detail for
them to build an implementation from scratch and that if
they do so they will have no royalties to pay for use
of the specification.
- to be able to brand their implementations to the available
specifications so that their customers know of their
compatibility with other open system vendors.
- that vendors, working together or separately on
implementations based on the open system specification,
will be encouraged to make such implementations available
for licensing, including early access.
The principles in this section tend to apply differently
during particular stages of the life cycle of software, and
open systems vendors engage in the process differently at
different stages. The next section, taken together
with the appendix, describes how to be a full participant in
the common open software environment process at all stages.
Software Life Cycle and Stages of the Process
Software technology passes through roughly four stages in
its life cycle as it relates to the common open software
environment process. Economics of product differentiation
drive some software forward through these stages, as the
value of differentiation decreases and the value of
commonality increases.
For the technology that ultimately becomes industry
standard, the following four stages apply from inception
through industry standardization:
- Innovation: Vendors market a variety of solutions, often
incompatible, trying to bring new function to market
quickly, to meet a range of user requirements.
- Common Direction: User demand for commonality drives
innovative approaches into a more consistent direction.
- Deployment: Vendors produce a draft specification, show
industry endorsements, produce sample implementation(s),
produce rigorous test suites.
- Availability: Formal approved specification exists and
certification branding is available. Vendors compete
against each other on the basis of quality, service,
price, and other added value.
The remainder of this section comments more on each of these stages.
Innovation
In the innovative phase, many different solutions may exist
and users can select those that best meet their needs but
may be constrained by incompatibility between vendors.
Vendors accept the high risk of developing products because
of the potential reward. Users accept a corresponding high
risk because the technology may become obsolete. A basis of
commonality has not been established. This may be because
the marketplace has not yet clarified the scope and priority
of user needs or decided which solutions best meet those
needs. Or the technology may be one where a variety of
different optimization points are needed to address a range
of requirements. Thus both users and vendors benefit from
innovation as long as the economics support it.
The process described in this whitepaper addresses only the
software that moves out of the innovative phase with a
recognition of a demand for a common direction.
Common Direction
As technology matures users see the value in, for example,
exchanging data between solutions from different vendors.
Thus the value of commonality grows to equal the value of
differentiation in elements of some technologies. In the
face of this demand, vendors may confer to set a common
direction, as a catalyst to the open system process.
The common open software environment process allows for any
group of vendors to initiate action toward a common
direction, in fulfillment of a perceived user demand.
It becomes a common direction only when a critical mass of
vendors across the industry give it their support, while
retaining their ability to address independently the broader
range of differentiated user needs.
Clearly, if sufficient vendors withhold support, their vote
signals continued differentiation. Leadership of a common
direction can come from any quarter, often initially through
meetings of a few vendors. An action becomes a common
direction only with an ample following made evident through
public endorsements, and eventually through votes at
industry organizations that formalize a specification.
A common direction can take any of several forms:
- Vendors could decide to integrate some existing
technologies and to write a new specification (e.g., the
common desktop environment).
- Vendors could decide to endorse a de facto standard (e.g.,
Motif).
- Vendors could set up a work group to write a draft
specification of a common set of Application Programming
Interfaces.
Deployment
In technologies where commonality has a critical mass of
support, it behooves the industry to move as rapidly as
possible to a specification, implementation, tests, and a
brand. This can be accomplished in many different ways,
ranging from a single company writing all components and
licensing it to others, to a collection of cooperative
development and test agreements between companies who decide
to share the cost and the ownership (e.g., the common
desktop environment).
The deployment stage should include provisions for early
access of specifications, implementations and tests to
facilitate broad, rapid deployment across the industry.
Availability
After a specification is approved and adequate test suites
are available, a certification branding program can begin,
and a support structure must exist for resolving ambiguities
in the specification or in the tests. Thus vendors will
compete against each other on the basis of product
availability, quality, service, price, and other added
value. All certified implementations would be permitted to
carry the brand, and would be expected to exhibit the
specified behavior.
Concluding Remarks
The common open software environment process has been
proposed as a way to accelerate the adoption of standards
for the open system industry. Thus it is neither an
initiative nor a group nor a club nor a consortium.
The common open software environment process is an open
system process, a set of principles, a commitment to
catalyze, and a mindset to accelerate.
The purpose of this whitepaper is:
- to lay out the principles for a common open software
environment in which contributors and vendors cooperate
for the growth of the industry and for the benefit of
users, and
- to describe a process that embodies this cooperation.
Now the task is to build support for these principles and
processes. UniForum has volunteered to be a focal point for
your feedback. Please contact Ed Palmer at 408-986-8840
ext.12, or by email at c...@uniforum.org.
APPENDIX
Tactical Scenarios
The body of this paper outlines some principles and
strategies for the common open software environment process.
These are necessary but not sufficient to document how
vendors might engage for the best advantage to themselves
and to open systems. This appendix proposes a tactical
response for several scenarios, with a focus on setting
common directions, the catalyst in the common open software
environment process.
1. Starting a New Common Direction Activity
Suppose your company has some state of the art expertise in
a technology in which commonality will be required in the
near future for its market to continue to grow. How should
you introduce a common direction, and how can it follow
the common open software environment process?
Here are some suggested steps:
1. Test your assessment of the business opportunity and
the technology against the principles described in this
paper.
a. Demand for commonality
b. Key multi-vendor agreement
c. Commitment to open specification
d. Availability of sample implementation and tests.
2. Become familiar with the principles of the common
open software environment process as described in this
document, and engage others on the basis of these
principles.
3. Identify and engage other companies. Work with
existing working group or use an RFP or your own
networks to find like-minded vendors. Seek to build a
critical mass of both large and small vendors, while
keeping your group small enough to be manageable.
2. Conducting a Common Direction Setting Activity
Suppose there is now a group formed which intends to set a
common direction, and you are one of the initial members.
By voluntarily participating in a common direction setting
group in the open software industry, you assume
responsibility for accelerating a technology to a
specification that will be widely adopted and implemented.
Such adoption can only happen if the requirements of vendors
both inside and outside the direction setting group are
adequately accounted for. Accordingly, the following
tactics are directed at both rapid progress and broad
participation.
Here are some suggested steps:
1. Seek input from companies not included in your small
group to be certain that all requirements are
understood and no opportunities for input are
overlooked.
2. Identify an appropriate vendor-neutral standards
organization and begin conversation with them regarding
your intent to set common direction and to build a
draft specification, if applicable.
3. At an appropriate time make a press announcement
citing the common open software environment process and
seek public endorsement from a broad spectrum of open
system vendors for the direction you are setting
including others who have endorsed the common open
software environment process.
4. Prepare a draft specification for submission to the
selected standards organization. Adjust the
specification as needed to accommodate the review
process. Work towards a passing vote through member
consensus.
5. Follow through with your implementation of the
specification. Engage other companies in a cooperative
development, if desired. Provide technology licenses,
including early access, to other vendors.
6. Facilitate broad availability of implementations to
the specification
3. Joining an Existing Direction Setting Activity
Suppose a group of companies has made a public announcement
of a direction-setting activity and you wish to be involved.
You agree that commonality has become necessary in this
technology, and it is a vital part of the future of your
business. Accordingly you wish to facilitate the adoption
of a common direction, and you wish to have your own product
implementation in the marketplace as early as possible.
How can you position your company either to influence the
common direction, or at least to take maximum advantage of
it?
Here are some suggested steps:
1. Contact one or more of the companies that announced
the common direction setting activity and request
status reports.
2. Make your requirements known to the participants in
the common direction setting group.
3. If you wish to influence the common direction,
prepare a position paper or presentation. Approach one
or more of the companies to provide input, recognizing
that the companies will be looking for ways to
accelerate the definition of a common direction, and
recognizing as well that your proposal might be
declined in favor of others. Proposals that either
bring missing technology or add representation for an
additional constituency should be received favorably.
4. Seek to be involved in any press releases that come
from the common direction group, stating your
involvement with and endorsement of the activity.
5. Contact the selected vendor-neutral standards
organization and register with them at a level
appropriate to your desire for review. Participate in
their review and adoption processes.
6. Consider developing a sample implementation, either
alone or working with other companies. Alternately,
take all available early access of source code and
proceed aggressively to build your own product
implementation.
4. Other Stages of Software Life Cycle
This appendix has focused on the setting of common
directions, which is a primary catalyst activity in the
common open software environment process. Similar steps can
be taken to engage with other vendors in the evolution of
technology in all other stages as well.
Please Note:
Questions about the content or currency of this press release
should be directed to your local IBM representative.