[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: Re: [ebxml-dev] ebXML has failed !
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
Powered by eList eXpress LLC