A Simple Model
The Portable Applications Standards Committee (PASC) of the IEEE
Computer Society has been debating the future of POSIX for some months.
It is clear that many of those in the standards industry are extremely
disturbed by the overlapping development effort that goes on between
PASC and The Open Group (TOG). There is POSIX.1 and POSIX.2, and there
is the Single UNIX Specification (SUS). SUS is a proper superset of
POSIX; everything in the POSIX standards that it is based on is in SUS,
and in the case where there appears to be conflict between the two
standards, POSIX wins. However, implementers have to prove conformance
to two standards and have to spend effort developing two standards.
The current objective of PASC is to move to a collaborative method of
working whereby only one standard is produced: a single document,
written by all the interested parties, and adopted in all the groups
that wish to have it as a standard. This article proposes a method for
cooperative development to produce such a single standard.
The simple model proposed here is exactly that: simple. Even though a
few changes may be needed and details need to be worked out, this is
the best chance for all parties involved in POSIX development and
maintenance to work in a cooperative environment. The groups initially
targeted at this work are: The Open Group, ISO/IEC JTC1/SC22/WG15, and
the IEEE PASC group itself. However, the model is easily extendable to
additional groups if needed.
The diagram below shows the basic steps, which are:
Writing or revising the standard
- Balloting the draft
- Remediation of possible objections
Writing or Revising the Standard
This is logically the simplest part of the process, but the practical
logistics may be cumbersome. Basically, the work is done at an
announced time and place and is open to anyone to participate for a
small fee (approximately the current PASC fees). Anyone may chair these
meetings, but the logical choices would be either the PASC or TOG
leaders in the technical area.
The frequency of meetings should also be fairly straightforward.
Projects undergoing active development need to meet six to eight times
a year (or more) to facilitate the faster turnaround times the industry
needs and expects. These are working group meetings, dealing mainly
with issue resolution. Some of these meetings should probably coincide
with the quarterly PASC meetings and quarterly TOG meetings, though
this is not a necessity.
Groups not currently working on active development would meet once or
twice a year in conjunction with either TOG or PASC. Since WG15 has
approved a plan to meet only once a year at either a PASC meeting
(included in the above considerations) or the annual SC22 meeting (not
appropriate for a work project meeting), no special consideration for
meetings with WG15 should be necessary.
The only contentious issue in this phase is the process for making
decisions needed before formal balloting begins. TOG and WG15 are used
to formal voting while PASC employs a looser consensus process (at this
stage). The compromise
is simple: attempt a consensus solution, but failing that, take a
majority vote. Decisions which are of major importance may be requested
to be postponed until the next meeting if it is considered that a
significant number of the major participants are not in attendance (or
even better, a vote may be taken electronically after the meeting).
For example: in a contentious issue about whether or not to include
XYZ, it is noticed that 2 of the 3 vendors of XYZ are absent. There is
obviously no consensus, so a vote is deferred until the next meeting.
Eventually over 50% approve XYZ, so it is included in the draft (note
that in the balloting phase over 75% must approve the inclusion in
The most difficult aspect initially will be to get the PASC and TOG
logistical folks to coordinate the meetings as appropriate. Since these
are now done independently and up to a year in advance, modifying our
current schedules will be difficult. Once we get over the first year or
so, the future meetings should fall into place naturally.
Balloting the Draft
The model here is simple to describe, but a bit harder to coordinate.
Simply stated, each group ballots using its own method: IEEE votes by
individual, TOG by corporation, and WG15 by country. The difficulty
comes in coordinating the balloting. The IEEE and TOG ballot periods
are somewhat similar, and their timeframes could be adjusted a bit if
necessary. The difficulty is the ISO process, both because there are
more defined ballot points and because the ballots take longer.
However, most ISO comments are either editorial or copies of ballots
already submitted in one of the other ballots, so resolving the
comments is not the major problem. We already have a working
synchronization plan between PASC and WG15, so we have evidence that it
A whole new synchronization plan probably needs to be developed, but
let's start with the following model.
Information and Preliminary ballots are done with drafts before the
draft that goes to formal IEEE ballot and formal company review in TOG.
CD ballot (and equivalent) begins with the first IEEE ballot.
Final CD ballot is the draft approved by the corporations and IEEE.
This should not be a problem since the final CD ballot under the new
rules does not allow substantiative changes anyway, so there should not
have to be any additional remediation with IEEE or the ToG corporations
for these changes.
Another problem is what to do when formal balloting begins, and one
group approves it and the other does not. There is no requirement that
all groups approve a particular document, but it would be desirable. To
that end I propose the following compromise.
When a document reaches the stage where either IEEE or TOG approves it
(but not both), one final remediation process is performed. The revised
document is then recirculated. If both groups approve, we are done. If
the approving group still approves, and the disapproving group still
disapproves, we are also done, but in this case only the one group
adopts the standard and the other group drops the work item, and does
not pursue it independently.
The last point is important and must be made a condition of
participating in a joint effort such as this. Otherwise, the whole
concept of a single standard developed by a single group is worthless.
Each group much agree at the beginning of the development process to
abide by this rule.
ISO was not mentioned in this last issue because either IEEE or TOG
could (or should) advance the work to ISO.
Resolving comments and objections after a ballot should be done by the
whole group in an open process similar to the development phase.
However, what normally happens is that many of the original developers
drop out at this point for one reason or another (it is a bit tedious
after all). The only requirement this model would impose would be to
ensure that all the participating groups are still represented by
active participants during this phase.
Editor's Note: Lowell Johnson is Chair of the IEEE Portable
Applications Standards Committee, PASC. This article is a personal
submission from him into the debate, and cannot be taken as a statement
of PASC policy. This proposal is under discussion and deliberation by
members of all three groups. It will be debated during the July PASC
meeting in Nashua, New Hampshire. Watch this space for further news.