Cooperative Development ­ A Simple Model

Lowell Johnson
<lowell.johnson@unisys.com>

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:

1. Writing or revising the standard
2. Balloting the draft
3. 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 IEEE).

   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 is possible!

   A whole new synchronization plan probably needs to be developed, but let's start with the following model.

   1. Information and Preliminary ballots are done with drafts before the draft that goes to formal IEEE ballot and formal company review in TOG.
   2. CD ballot (and equivalent) begins with the first IEEE ballot.
   3. 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.

      Remediation

      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.