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 !


Todd,

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

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

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

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 
for.

cheers

pk

>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 
[207.229.102.93] 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>, 
<mailto:ebxml-dev-request@lists.ebxml.org?body=subscribe>
>List-Unsubscribe: <http://lists.ebxml.org/ob/adm.pl>, 
<mailto:ebxml-dev-request@lists.ebxml.org?body=unsubscribe>
>List-Archive: <http://lists.ebxml.org/archives/ebxml-dev>
>List-Help: <http://lists.ebxml.org/elists/admin.shtml>, 
<mailto:ebxml-dev-request@lists.ebxml.org?body=help>
>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
>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
>
>
>----------------------------------------------------------------
>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