[OpenISO] OpenISO.org Core Guidelines

[Norbert Bollow]

DocumentID: OI A200:draft1
ShortTitle: Core Guidelines
LongTitle: OpenISO.org Core Guidelines
Date: 2007-09-10
Working-Group: discuss at OpenISO.org
Editor: Norbert Bollow
About: OpenISO.org


# OpenISO.org Core Guidelines #

## Overview ##

OpenISO.org aims to provide a process in which concerns about proposed
standards are fairly evaluated in a transparent and fact-oriented
manner, according to requirements of openness and maturity (described
briefly in the section on decision-making processes and requirements
below; in addition, OpenISO.org is planning to develop separate
documents with detailed formulations of the requirements.)

For specifications which satisfy OpenISO.org's criteria for approval
as a standard all kinds of concerns are evaluated and reflected upon
in OpenISO.org's evaluation report on the specification.

Regarding specifications which do not satisfy the criteria for
approval as a standard, OpenISO.org evaluates only concerns about
issues which are in themselves serious enough to justify (if the
concern is found to be valid) refusal of approval as a standard.

In addition to deciding whether specifications fulfil OpenISO.org's
criteria for standards, during the evluation process a rating is
assigned to each specification.

This rating is one of the following:

1. Strongly discouraged
2. Discouraged
3. Recommended in some contexts
4. Recommended
5. Strongly recommended

Specifications with a rating of "strongly discouraged" or "discouraged"
are not approved as standards, while those with ratings of "recommended
in some contexts", "recommended" or "strongly recommended" are approve
as standards.

If after completion of OpenISO.org's evaluation of a specification
further concerns are raised, or if the validity of the justification
for the rating is challenged, these comments will be evaluated, and
if it is found that the facts justify such a step, the rating will be
adjusted.

There is a variety of reasons why a specification's rating may change.
It is possible that a serious issue has been overlooked or a mistake 
made during a specification's initial evulation.  It is also possible
for problems to get resolved outside the specification itself, for
example patent problems can go away when a patent expires or when a
sufficiently broad patent license is granted.

## Working-Groups ##

Like just about every other standards organization, OpenISO.org
organizes its activities by means of structuring them into a number
of Working-Groups.

In the case of OpenISO.org, these working-groups are implemented by
means of "discussion" email mailing lists.  For each Working-Group,
the subscribers of the mailing list are the members of the
Working-Group.

The OpenISO.org Working-Groups are organized in a hierarchical
manner, with the discuss at OpenISO.org Working-Group at the root of
the hierarchy.  All other OpenISO.org Working-Groups are directly
or indirectly sub-groups of discuss at OpenISO.org.  Each of these
subgroups reports to the Working-Group of which it is a subgroup.
Subgroups should be formed whenever the traffic on any of the
Working-Group mailing-lists becomes so intense that the sheer volume
of the traffic becomes an obstacle to productivity.

All Working-Group decisions must be justified in writing.

If the validity of the justification for a decision is disputed and
the Working-Group does not reach a consensus resolution of the issue,
OpenISO.org will as quickly as possible, by means of a process which
is independent of the Working-Group, evaluate the arguments from each
side in a fair and fact oriented manner, and any Working-Group actions
which depend on resolution of the disagreement are delayed until a
decision has been reached.  (See the section on dispute resolution
below.)

In order to prevent to wasting too much money on dealing with trolls,
those who have taken positions which are found to be frivolous will
after wards have to pay themselves for getting their disputes
resolved.  The same applies to anyone who engages in conflict-bombing
(initiating many conflicts simultaneously.)


## Decision-making Processes and Requirements ##

The fundamental decision-making principle is of course that decisions
should be made in a fact-based manner.  The fundamental question is:
What happens when there is no consensus about an appropriate
fact-based decision? In most existing standardization organizations,
at that stage the decision-making process either breaks down or the
committee members vote.  Both of these mechanisms are inadequate
because is the first case a company like Microsoft can prevent any
decision it doesn't like by means of breaking the consensus, and in
the second case it can manipulate every vote by means of telling
enough "gold certified" (economically dependent) partner companies to
vote, like it happened in the case of the ISO/IEC evaluation of OOXML.

Therefore, OpenISO.org adopts the rule that all disgreements which
cannot be resolved by means of Working-Group consensus processes must
be addressed by means of an independent, professional evaluation of
the relevant facts.

Every decision must be justified in writing.

If it turns out that there are several justifiable viewpoints, the
proponents of the various possible approaches can all get their
preferred solutions equally endorsed by OpenISO.org provided that the
openness and maturity requirements are fulfilled.

Openness requirements will include that there should be no patent
issues etc.

Maturity requirements include that there should be a BSD-, Apache- or
LGPL-licensed reference implementation and that the spec has been
reviewed for cross-cultural applicability and with regard to its
impact on people with disabilities.  Where a significantly earlier
standard with significant marketplace adoption already exists, the
OpenISO.org maturity requirements also include that for any new
standard which will compete with the pre-existing standard, for every
aspect of how the new proposed standard which can be objectively
compared with the pre-existing standard, the new proposed standard
must in that respect be at least as good as the pre-existing standard.


## Dispute Resolution ##

Ultimately OpenISO.org intends to outsource the dispute resolution
process to a legally independent "Decision Consulting Services" (DCS)
business.  The DCS company will have a conditionally-exclusive
contract in the sense that as long as the DCS company provides an
excellent quality of service at a reasonable price (the precise
requirements for fulfilling these conditions will have to be spelled
out in detail in the contract), OpenISO.org will source (as resources
allow), from the DCS company, dispute resolution services for all
disagreements that the respective Working-Groups do not succeed in
resolving among themselves in a mutually-acceptable way.

If there are unresolved conflicts and OpenISO.org does not have the
necessary financial resources for resolving them, OpenISO.org
standardization work will be stalled in the concerned areas until some
interested party contributes the necessary  financial resources for
getting the conflicted questions examined in a proper, professional
manner.

OpenISO.org itself will be established as a foundation under Swiss
law, and its bylaws will require it to terminate the contract with the
DRPP and never anymore give it any business if it is ever found to be
in violation of the contracture requirement to provide an excellent
quality of service at a reasonable price.  If a foundation under Swiss
law fails to act according to the principles in its bylaws, it should
possible to force the foundation to comply with its bylaws by means of
asking the responsible government authorities which are responsible
for the supervision of foundations to act on the issue.  Besides that,
recouse to Switerzland's well-developed court system is also possible.
Therefore, a very trustworthy assurance of intergrity can be achieved
by establishing OpenISO.org as a foundation under Swiss law with a
strong requirement in the bylaws to switch to a different DCS company
if the DCS company is ever found to be corrupt or otherwise not up to
an excellent standard of reliability.  In such a situation, the new
DCS company must be strongly different from all previous DCS companies
in that a new DCS company must be chosen where no board member or
executive has served as board member or executive of one of
OpenISO.org's previous DCS companies.  (Unlike OpenISO.org itself,
which will be a foundation, the DCS company will be a normal company.)

The DCS company will be contractually required to provide its services
in a transparent, verifiable manner.  All decisions taken by the DCS
company must be justified in writing and made available for public
scrutiny.  All the DCS company's employees must be identified by means
of a unique permanent pseudonym, so that any systematic bias in the
actions of particular employee can be detected.  In addition to the
permanent pseudonyms, there will be separate, randomly-generated
pseudonyms with short-term validity for use during the dispute
resolution processes themselves.  Only after completion of any given
dispute-resolution process will it be disclosed what permanent
pseudonym corresponds to the short-term pseudonym which was used
during a specific dispute resolution process.  The introduction of
these short-term pseudonyms is an additional safeguard against
corruptions, which increases the difficulty of exploiting any
knowledge about vulnerability to undue influencing of a particular
employee of the DCS company.

The start-up plan for all this is that initially, the founder of
OpenISO.org takes care of the DCS function until the time
requirements for this function become too great for that und
OpenISO.org manages to acquire sufficient financial resources for
being able to outsource this function.  At that stage the founder
of OpenISO.org may name the company that becomes the initial DCS
company.  In particular, at that time the OpenISO.org founder will
have the right to name a privately-held company of his own for this
function.

This set-up provides the OpenISO.org founder with a rational economic
incentive for doing a good job with the OpenISO.org start-up, while at
the same time setting up appropriate incentives for ensuring long-term
integrity of the decision-making processes.


## Requirements for Working-Group Participation ##

### Patent Non-Assertion Convenants Requirement ###


Every participant in an OpenISO.org Working-Group must disclose
whether this is done on behalf of, by request of, or while getting
paid by an organization.

Participation in the discuss at OpenISO.org Working-Group does not
require execution of a patent covenant.

However, when subgroups of the discuss at OpenISO.org Working-Group
are created, for each such subgroup a "List of specifications"
will be specified for which a patent covenant as follows will be
required of participants in the subgroup.  This covenant is modeled
on Sun's promise <http://www.oasis-open.org/committees/office/ipr.php>.

> [Participant/Organization] irrevocably covenants that, subject
> solely to the reciprocity requirement described below, he/she/it
> will not seek to enforce any of his/her/its enforceable [Country of
> Participant/Organization] or foreign patents against any
> implementation of one of the following specifications [List of
> specifications] or of any subsequent version thereof, in the
> development or OpenISO.org evaluation of which [Participant/Organization]
> participates ("Implementation of a Covered Specification").
> Notwithstanding the commitment above, [Participant/Organization]'s
> covenant shall not apply and [Participant/Organization] makes no
> assurance, covenant or commitment not to assert or enforce any or
> all of his/her/its patent rights against any individual, corporation
> or other entity that asserts, threatens or seeks at any time to
> enforce its own or another party's [Country of Participant/Organization]
> or foreign patents or patent rights against any Implementation of a
> Covered Specification.


### Pseudonymous Participation ###

Pseudonymous participation in Working-Groups is allowed.  While
Working-Group participants must inform OpenISO.org of their real name,
address and employer (if any), and must provide the required patent
non-assertion convenants, OpenISO.org promises to not disclose this
information to third parties as long as the patent non-assertion
convenants are not violated.


## Commitment to Free Software ##

The software which OpenISO.org will use must be "open" publicly
available Free Software.  The reason for this is as follows: When
the  software which a standardization organization uses to implement
its workflow is proprietary (is this the case with the "livelink"
system used by ISO?) that has the effect of creating a form of
lock-in to the standardization organization which at odds with the
fundamental principle of openness that is so important for legitimate
standardization processes:  Whenever a group of people feel that their
concerns and views are not properly taken into account by the existing
standardization organizations, they must have the freedom to fork the
standardization process to create their own specification,
endorsement, problem report or amendment documents.


## Reflectivity ##

OpenISO.org is intended to be a reflective organization in the sense
that it should always strive for a good understanding of its own
processes in the light of relevant scientific research in the fields
of economics, organizational development and standardization.

The plan is to get started with generating some draft recommendations
and problem reports for some specifications that are worthy or not
worthy of being called a "standard".

However OpenISO.org intends to avoid moving anything from "draft"
status to "published" endorsement or problem report before there is
confidence in discuss at OpenISO.org Working-Group that OpenISO.org has
a sufficiently mature understanding of all important concerns and
attracts enough attention from interested parties that errors or
significant omissions are likely to get pointed out.

Here's a pointer to a book that might turn out to be useful as a
frame of reference in the evaluation of existing standardization
processes and in developing one which works well and robustly:

  Surowiecki, James (2004). The Wisdom of Crowds: Why the Many Are
  Smarter Than the Few and How Collective Wisdom Shapes Business,
  Economies, Societies and Nations Little, Brown ISBN 0-316-86173-1

For the development of guidelines and procedures for standardization
work it may be a good strategy to work mostly manually (without much
use of automated tools) initially, documenting workable procedures
as they emerge.  Procedures which appear to be in any way
untrustworthy are subject to the decision making principles of
OpenSO.org and can be challenged at any time.