Standards development, cathedrals, bazaars etc.

Oil IT Journal editor Neil McNaughton considers the SEC’s significant investment in XBRL as auguring well for the standards movement in general—and for the newly rebranded POSC/Energistics. He reflects on the merits of ‘open’ and ‘closed’ standards development to suggest that a move to a more open process would allow more stakeholder involvement in upstream standards development.

We’ve been reporting on the extensible business reporting language (XBRL) for a while now. The last time we checked, Petrobras was the only oil and gas company to have publicly backed the standard. This is likely to change as the SEC is now financing the completion of the XBRL taxonomy and is to upgrade its EDGAR system to leverage the new technology. The move ‘presages widespread adoption of interactive data filing by companies that report their financial information to the SEC,’ which I read as code for the SEC making XBRL mandatory in the mid term.


I mention this because standards adoption has been the subject of much hand-wringing in the oil industry. To the extent that, just when the emergence of a new standard might actually force companies into adoption, the old chestnuts of anti-trust, or anti-competition fears are trotted out—conveniently avoiding the need to actually implement anything. The received view is that ‘standards’ are OK for places like Norway, but that in the ‘free enterprise’ world of the US they will never really fly. Well XBRL, with SEC backing has legs if not yet wings and oil CIO/CFOs might like to take a peek at just in case.


I can’t resist commenting on the POSC/Energistics rebranding exercise based upon my own recent experience of the ProdML ‘public comment’ period that closed this month. Visitors to the website may have spotted the occasional comment—these appeared briefly in public. But as soon as they were made, the ProdML group saw fit to remove them from public view. One has to wonder what twisted logic is behind such behavior. Are public comments on ProdML so sensitive that they need to be removed from public view asap—perhaps before Google records them for eternity?


My own query was why ProdML (and for that matter WitsML) didn’t make more of the merits of data validation—a subject which you, readers of this column, will be familiar with. An interesting and informative exchange with some ProdML luminaries ensued which I think would have benefited a wider audience. I think that in the context of development that leverages emerging W3C specifications, such dialog should be part of an education process. Which got me thinking about the contrast between the POSC/ProdML approach and the open source movement.

Cathedral and the Bazaar

On the topic of politics, standards and open source development, the seminal work is undoubtedly Eric Raymond’s The Cathedral and the Bazaar*. This argues that the web has radically changed the way software can be built—effectively shifting control from closed groups of expert ‘cathedral builders’ to public, lose associations of punters, ‘the Bazaar.’


The existence of Linux, Apache and a plethora of lesser projects demonstrates that, although these projects in fact mobilize as many expert experts as you could wish for, the ‘open’ methodology is a formidable approach to producing quality software. Perhaps the most paradoxical success of the open movement is the development of crypto code which has to an extent migrated from behind the experts’ closed doors to the public domain.


Are the ProdML team the cathedral builders and the rest of us the hordes at the gate? Probably not. In fact the ProdML team, rather late in the day, went outside of their project to involve some real cathedral builders, in the form of some of IBM’s web services gurus. They checked out the code and found a few issues—with data typing and schema complexity (see page 11). It’s not clear whether these are big issues—but what is sure is that any issues at all should be fixed as early as possible—before too much ProdML (or WitsML) code gets into regular use. Would a more open development process have avoided this kind of glitch? I think it probably would.

Heavy weather

PRODML members like many others have made heavy weather mapping old business practices onto the web. The difficulty is moving from a closed oil company type joint venture to a truly open collaboration. The POSCian workshops have been part of the problem here. As a part of the rather arcane funding buck-passing over the years, much of the serious activity of POSC has only been visible to members who divvy-up for special membership of the group. In a similar way, ProdML’s groundwork has been developed by a restricted group of sponsors free from public interference and scrutiny.


The problem with the ‘move fast with a small footprint’ approach is that it is very hard to ring-fence your data in such a way that it is will not impact other stakeholders. The SEG’s seismic standards, by and large lean towards the data acquisition community just as ProdML’s first audience is in the production arena. But in the end, data is consumed by applications; data has to be managed by data managers and data links across to other ‘foreign’ data. This argues in favor of a process that allows all stakeholders to get a peek at what’s going on as soon as possible.


I use the word ‘peek’ advisedly. Apart from the demonstrable merits of a more open development process there are not inconsiderable spin-offs. Lurkers are educated. Carbon is reduced as you no longer have to fly around the world to keep up to speed, and if the standard is going to be public, the sooner it is out there the better.


This article originally appeared in Oil IT Journal 2006 Issue # 11.

For more information or to comment on this topic email here.