[OpenISO] OpenISO.org Core Guidelines

[Norbert Bollow]

"Std Lib0" <stdlib0 at googlemail.com> wrote:

> > 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.
> 
> this adjustment possibility makes me wonder if the prefixes STD and PR
> should be allowed in the process identifier. shouldn't they should be a
> suffix after the version number?

I agree that putting them into a suffix would be a logically
"cleaner" approach.

My proposal to put them before the TopicID part is based on
the desire to maximize impact that e.g. the difference between

"OI STD-F29300 Approval of ODF as OpenISO.org standard"

and

"OI PR-F29500 OpenISO.org Problem Report about OOXML"

is likely to have on a casual reader.  I think that moving the "PR" or
"STD" to suffix position could weaken the impact of what we're trying
to achieve here.

Standardization organizations like ISO/IEC JTC1 or OpenISO.org
have no power besides the ability to influence the market by
means of sending a signal to the market.  So we need to make
sure that the signal which we're going to send is going to be
an effective one.

> > 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.
> 
> 
> I don't agree with Microsoft practices much as all here probably, but
> citing its name in this sentence doesn't make it too 'personal'?
> Maybe 'a resourceful rogue company' is a better phrase.

I'm not sure that writing "rogue company" is legally safe (everyone
knows that we're talking about Microsoft, and as far as I know there
hasn't been a court decision yet declaring Microsoft to be a "rogue
company".)

However writing "a monopolistic company" instead of "Microsoft" is
ok with me and certainly legally safe.  Shall I make that change?

> > 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.)
> 
> 
> well, it's expected that a corrupt DCS' _current_ decision will be
> discarded, but this is not explicit. what about its past decisions?

Hmm... if we leave this unspecified, any disputes about what should
be done about decisions of a DCS company that has been found to be
corrupt or otherwise unreliable would be handled by the new, hopefully
better, DCS company as soon as a new one has been appointed.

I tend to think that leaving it at that is probably better than any
explicit rule that we could write now without havinf any information
about how and when the integrity of the old DCS company has broken down.

> > 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.
> 
> 
> I really like the ease to fork. Not only as a healthy pressure for
> openiso to provide excellence of service, but also because this will
> enormously help local governments to setup cheaper regional standard
> bodies by directly drawing on procedures and software from openiso.
> A standards body should be legitimate because there's a group of
> people believing in its process, not because nobody has the
> expertise to replicate its processes.

Yes... and in addition, some of OpenISO.org's software and processes
might turn out to be helpful in contexts which are not directly
related to standardization.  It's much better to empower everyone to
experiment with trying to set up good decision-making procedures for
any kind of purpose than to adopt a poliy which needlessly imposes a
"you should ask first" hurdle.

Greetings,
Norbert.


-- 
Norbert Bollow <nb at bollow.ch>                      http://Norbert.ch
President of the Swiss Internet User Group SIUG    http://SIUG.ch
Working on establishing a non-corrupt and
truly /open/ international standards organization  http://OpenISO.org