OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Subject: Re: [ebxml-dev] ebXML open source !


There are a bunch of ebXML Open Source projects already in the works.

For example, there is the ebXML Registry/Repository project (ebxmlrr) at 

Similarly, there is openebxml.org which, if I'm not mistaken, is based on 

I would strongly encourage you and others to get involved in these projects and 
use them as vehicles to create the kinds of class diagrams etc. you are looking 



>Date: Fri, 04 Jan 2002 11:26:43 -0800
>From: Todd Boyle <tboyle@rosehill.net>
>Subject: Re: [ebxml-dev] ebXML has failed !
>X-Sender: tboyle@popmail.cortland.com
>To: ebxml-dev@lists.ebxml.org
>MIME-version: 1.0
>X-Authentication-warning: deneb.cortland.com: Host rosehill.net 
[] claimed to be ppro180.rosehill.net
>List-Owner: <mailto:ebxml-dev-help@lists.ebxml.org>
>List-Post: <mailto:ebxml-dev@lists.ebxml.org>
>List-Subscribe: <http://lists.ebxml.org/ob/adm.pl>, 
>List-Unsubscribe: <http://lists.ebxml.org/ob/adm.pl>, 
>List-Archive: <http://lists.ebxml.org/archives/ebxml-dev>
>List-Help: <http://lists.ebxml.org/elists/admin.shtml>, 
>List-Id: <ebxml-dev.lists.ebxml.org>
>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
>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
>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
>There are systems like the democratic source license for example.
>(shares of ownership based on code contributed:) 
>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
>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.
>The ebxml-dev list is sponsored by OASIS.
>To subscribe or unsubscribe from this elist use the subscription
>manager: <http://lists.ebxml.org/ob/adm.pl>

Peter Kacandes

Sr. Product Manager, Java XML APIs	phone number: 	408 276 7139, X17139
Java Software Products 			email:	peter.kacandes@sun.com

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC