Re: [ebxml-dev] ebXML has failed !

[Todd Boyle <tboyle@rosehill.net>]

ebXML encompassed, from the outset, many technologies that
already existed.  One could hardly say, it has failed.

Those technologies have continued to evolve and improve, and would
have done so independently of the existence of ebXML.

The ebXML group could hardly have invented messageware on its
own, for example, or metadata registries, or invented a globally
agreeable vocabulary etc.  Even if they had invented great things,
who would have listened?  The context mechanism, for example.

The percentage of original creation has been below 20% or
sometimes zero, i.e. the ebXML has functioned as a sort of
caucus which made choices among rival technologies in order
to fit them into a working whole.   In other cases ebXML faced
a need like creating a vocabulary sooner than EWG, or
articulating a different business process model from the UMM
metamodel, it seems to me, it ran out of fuel.

I hope this isn't sounding negative because ebXML rocks, it has
been fantastic source of information that has accelerated a lot
of those other technologies and had a unique role of resolving
the gaps at the boundaries between them.  In a sense, ebXML
is an administrative operation, that accepts technology submissions
quite informally, accepts management suggestions on all kinds
of fine-grained topics and arbitrates among them.  It has a fine
community of very capable, intelligent people and makes a
valuable contribution.

Frankly I wish ebXML would encode its results and conclusions
in open source code, as well as long specifications and class
diagrams.

I also wish ebXML community would realize what a unique
accomplishment it has achieved in its open process.  ebXML has
been a *very* big deal in terms of these dimensions;

A=number of participants,
B= number of countries,
C=number of competing vendors and other contexts,
D=number of technology domains
E=average complexity of the domains
   etc. etc.

ebXML participants should budget / allocate a few precious cycles to
understanding why this somehow has succeeded in such an unusual
fashion, and what aspects of its professional collaboration model
caused this success.   There were some common rules in all
the workgroups but they were not rigid. There was an expectation
of fast turnaround, in days and weeks not months.  There were
4 major meetings per year. There were frequent teleconferences
but not much travel otherwise.

What can we learn from these things, to further improve systematic
performance or behavior of this collaboration?

We should define the needs for a content distribution system that
reliably disseminates information, appropriately, to large audiences.
This surely would include improving the intelligence at the endpoints
of the network, enabling the participant to filter and manage knowledge
content, files, and structures such as source code and UML models.
I do not regard these mailing lists, with 25 folders in my email program,
as the final achievement.

If there is an ebXML community that has an independent composition
other than UN/CEFACT, it should become self-aware like HAL 9000.
It should consciously examine its leadership/governance model.

We should define the needs for a governance system that achieves the
judgment and historical context of a representative democracy while
avoiding its vulnerability to special interests.  One which achieves the
exactness of direct voting on issues, without the vulnerability to mass
psychology, mutually unreconciled decisions, and potential injustices.

The other standards bodies are facing these same challenges --the
Orlando Interop conference last month was very thought provoking.
http://www.omg.org/interop has the powerpoints from the meeting.

I believe there is a huge, unmet need for better distribution of knowledge
in P2P lateral models like ebXML, and better cultural model for
governance.  The present model is, "let a hierarchy of leaders
make policy decisions, coordinate and run things."  That is ok but I
want to point out three problems with the model itself:

1 . This encapsulates into one mechanism a single bundle of
decisions that must be accepted all-or-none, as in electing a president.
In other words, you decide who you trust and delegate all decisions.

2.  The problem domain of ebXML may be too deep and fast moving,
and interdependent for a single hierarchical management to maintain
competence.

3.  The model too easily results in displeased members departure
from the group.  In other words the system gives them no choice,
because it does not measure each decision in any granular or
quantitative way.  The hierarchic, delegated governance model is
mostly found in states, where the participants are immobilized and
cannot leave. And in corporations.  But ebXML is a peer community.
In pop psychology this is an adult-to-adult relation instead of parent-child.


There is a mutual dependency between solving these twin problems
(governance, and "knowledge management" or distribution), and the
models within which we find ourselves today.  In other words the
present model may not be well-suited to addressing these problems.

The improvements in the model cannot appear without a large scale
discussion and MIGRATION in thoughts and practices by existing
members.   There is not a demonstrated interest in these problems,
else they would have been discussed and solved by now.

The discussion itself depends on a large scale PLATFORM much
better than email, for intense, real-time collaboration over the internet.

And that depends on a vision and REQUIREMENT DEFINITION for this
new platform.  Do we dare to move any discussions off the mailing
lists into something faster such as IM or voice multiconferencing,
like the teleconferences?  This really accelerates the work of the
main people but it totally leaves behind all the rest of the community.

Many of the open source communities such as GNUE now rely
mainly on Sourceforge structure for source code and files, and
IRC chat for core developers.  The list was very active until 2000
then went totally dead as the developers went into fulltime IRC chat.
Now they publish Kernel Cousins.  The latest weekly summary of
the mailing lists (and some of the IRC) traffic is at
  http://kt.zork.net/GNUe/gnue20011222_8.html

An example of governance improvements would be decentralized
infrastructure for proposing political or technical questions for votes
by members, together with an online voting system that maintains
the votes.  Since decisions are interdependent, the system might
allow the member to go back and change votes.  Perhaps not every
one would have equal power.   If the writers of the American constitution
had the internet and MySQL and Apache they would have probably
included at least SOME mechanisms for direct democracy on
issues.

There are systems like the democratic source license for example.
(shares of ownership based on code contributed:) 
http://www.dsf.org.uk/dspl11.html

The governance model is crucial to addressing the economic incentive
problem facing all volunteer groups like ebXML.  In other words, there
are thousands of really great developers but they *all* need to pay their
rent, and apparently, very very few developers can even survive here,
as independent consultants while working with a pure, abstract standards
body.   It is tough even for open source software developers but at least,
they have revenue from derivative works, service and support, etc.

I believe ebXML will need a better platform and governance model anyway,
to deal with the continuous challenges that are inherent in this industry
or whatever it is.  This profession.

This new profession will not go away.  The range and scale of what we are
trying to manage is far beyond any one person's capability to govern
or coordinate.  I have been waiting for some Tim Berners Lee or Linus
Torvalds to emerge, to guide the ebXML model but that's impossible,
because we have already frozen into a hierarchic model.

We need a whole, broad orchestration platform, some kind
of a market paradigm, to unlock our productivity.  There are 6 bilion
people.  It is implausible that a tiny group like this, or even its
sponsor organizations, will be effective with the current email
and hierarchy models.   We may have some helpful influence
but in general, we will be lost in the background noise as
commercial and proprietary models predominate, in a darwinian
process.

In general, the best work of ebXML volunteers may just go into
the features of proprietary software vendors.  As voluntary donations
to the middleware and ERP vendors.

ebXML can improve its value proposition to developers and
volunteers if it focuses on the right problems.

Todd