OIC TC Activities Compared with Open-Source Projects

["Dennis E. Hamilton" <dennis.hamilton@acm.org>]

In the discussion today about who is doing the work at the moment and how others find ways to participate, I picked on the SVN commits and rate of change that Bart appears to be making to his piece of the tree as an example of people not knowing what is stable enough to grab onto, and also what there is that has others see something that arouses them to participate.

I have a similar experience with the Specification Analysis, where I have done a lot of tuning and have not made it clear that there is room to build discussion and think about build bridges between the specification extracts and our analysis of what the testable conformance is and then how we want to connect to our supplemental material, whatever it is, on interoperability determination and testing.  So I am merrily plugging along, but it is not like this is *our* result: it is at this point entirely my own play-pen.  For the transcription of the specification, that is understandable.  For the connection of discussion and analysis, it must be our effort, I suspect, or else it will simply be an under-used curiosity.  This is not a complaint, it is something that I am doing in the faith that there will be a productive way for others to become engaged at some point.  If not, we can agree to abandon the specification-analysis development and do something else.  The experience is useful for me either way, and I would not have jumped in if I hadn't seen an opportunity in it.  

This reminds me of the situation that arises with open-source projects.  It is often the case that developers and more committers do not dig into an open-source project until there an opportunity is recognized that that inspires the creative contributions of more participants.  There is no assurance that having something already usable will succeed in attracting contributors.  But this seems to be the pattern when an open-source effort takes hold in a solid way.

As Rob pointed out, there is also a socialization process involved in how we become prepared and motivated to engage in an active way and are able to participate in coordinated action.  There is a learning curve that must be endured, sometimes with a fair amount of figurative bloodshed, before we achieve a shared understanding and have enough that we can get our heads and hands around.  This is confounded by the fact that we are doing something that has not been done before by these participants and with this subject matter.  So the OIC TC is itself very much a work in progress.  I also think there is more agreement than we think, but we only find that out by testing it.  

(Personal aside: Using a particular example, it is more noticeable and time-consuming when Rob and I disagree about something before arriving at violent agreement or agreement to disagree.  It is perhaps not so noticeable that we agree on a great deal because that often happens more easily without being remarked upon at all.  And it often takes some work to arrive at enough mutual understanding enough of a topic and how we speak of it to recognize the agreement, just as it takes work to dig out the basis of an apparent disagreement.)

I don't want to go too far in making an open-source analogy, but it did strike me that there is some relevance.  In particular, we are talking about a coordinated effort accomplished by volunteers (whether or not with support of employers or otherwise).  There is no requirement that people take on work, of course, and we each have our personal priorities and commitments to deal with.

One major difference is that public open-source projects tend to have benevolent dictators.  This does not apply to an OASIS TC.  Here we must achieve consensus or some other form of explicit agreement that approves work as an agreed product of the TC.  Then there are even wider approvals required for the work to be an approved product of OASIS.  And finally, we want to see take-up in the world, what I trust has us be here at all.  In some ways, that makes things harder and more laborious and those who just want to jump to a result are often frustrated by the apparent overhead.  We have to learn together what is that "least that can possibly work" and have a reliable way of refining it as a result the TC stands behind.

 - Dennis

Dennis E. Hamilton
------------------
NuovoDoc: Design for Document System Interoperability 
mailto:Dennis.Hamilton@acm.org | gsm:+1-206.779.9430 
http://NuovoDoc.com http://ODMA.info/dev/ http://nfoWorks.org