I've started considering the use of "git" for the development of standards. The fit with standards development is good.
During standards development we have multiple groups are working on supplements and a base standard. We presently use supplements and CPs as a high level visible organizing principle. These correspond to different bug fix and feature add paths in a config management system (CMS). There are multiple distributed development groups, each needing their own head. These occasionally interact by spawning changes to another branch.
This is very similar to the environment inside the Linux Kernel and X window system. Both of those are very large projects that have autonomous development teams and individuals working to generate a single common release. There are a variety of internal projects that have low interactions with others (e.g., device drivers, 3D rendering, etc.) These do find and spawn fixes to other projects. They do have to maintain long-duration multi-release projects while sustaining regular small feature releases and bug fixes. The end result has to support multiple releases, back ports to earlier releases, and reversions.
So the problem space is very similar.
The core differences between standards development and software development (and these matter a lot to the people involved) are:
- The underlying file formats used by SDOs are hostile to external change management. Software developers use computer languages that are regular text files. The languages are designed to maximize change locality. It is natural to change one line in the language and have only one line of text change in the file body. SDOs use Word and other formats that are generally hostile to this concept. They are usually opaque binary blobs.
- The tools used to develop these files are hostile to external change management. There is no tooling integration with CVS, or any of the commonly available CMS tools.
This is one reason that Wiki's are exploding in popularity for documents. Although they are a pitiful CMS, they are a tool that does generate a text form underlying object. They remain mostly hostile to external change management. For example, the mediawiki tool that is behind Wikipedia, IHE wiki, and many others, does not support easy export and import of the underlying text files. For example, the inability to use wget (or any similar tool) to export or capture contents is a bug that was recognized and listed several years ago. It remains on the not planned (much less scheduled) for a fix or feature add. The developers acknowledge that they are hostile to external CMS and do not view this as an important problem.
Consider the possibilities opened by the slow moving efforts to move DICOM into an XML format. The actual format selected is DocBook, so the DICOM in XML should really be renamed DICOM in DocBook. DocBook is very friendly to external CMS and also friendly to export into multiple forms (PDF, DOC, HTML, SGML, Wiki). Unfortunately, DocBook lacks usable GUI writing tools.
The lack of usable GUI writing tools has been a profound barrier to the acceptance of DocBook. The writers will not use it. Only the occasional odd-ball writer will tolerate DocBook.