|
ELECTRONIC SEISMOLOGIST September/October 1998
Steve Malone Recently the Electronic Seismologist (ES) has been wasting his time glancing through a variety of computer trade rags and has noticed a plethora of articles with strange titles bearing little apparent relevance to the usual standard geeky bits and bytes. Being easily attracted by seemingly irrelevant titles, he became hooked on these articles comparing software development strategies with two medieval institutions. Both cathedrals and bazaars provided major focal points for the daily lives of the peasants, masters, and maybe even the seismologists of 1,000 years ago in central Europe. Both were places for obtaining nourishment (for the belly or soul), news, and information, and were centers for social interaction. Even for those who did not pray in the cathedrals or shop in the bazaars, both institutions affected their daily lives in profound ways, just as today those who donÍt use computer software are nevertheless affected strongly by its use around them. Of course, the construction of a cathedral was totally different from that of a bazaar. The cathedral was carefully planned, designed by a master builder, financed by the manor lord, and constructed by skilled craftsmen who were rigorously trained in their particular specialties. The bazaar, on the other hand, was thrown together by merchants and craftsmen with little advance planning. The bazaar changed and evolved rapidly as the tradesmen and their customers came and went. It could be abandoned, move to a new place, or include different features when the next joust was announced. The cathedral was grand and powerful, and its features had been well thought out by experts for the benefit of its users. It was expensive to build and, when finished, it was usually the only one in the neighborhood. Since everyone could use it, the cost per person was small (just a tithe for life). So what does this have to do with software, much less seismology, forsooth? Software packages can be easily classified as either cathedral packages or bazaar packages. The monolithic, commercial programs designed by computer science gurus and coded and tested by legions of highly trained programmers and software engineers for us poor peasants to worship at/with are the cathedrals. The bazaars are the freeware or nonproprietary packages developed, modified, and enhanced by any and all in a continuous amorphous, out-of-control way. Cathedrals are most main vendor operating systems and general purpose programs such as MS-Word, FrameMaker, Excel, CorelDraw, and Oracle. Bazaars are X-Windows, TclTk, GNU, FreeSoftware Foundation. Linux is a premier example of a bazaar-type software product. Under the coordination of the superb bazaar-master, Linus Torvals, hundreds of programmers have contributed to this operating system now used on thousands if not tens of thousands of computers. Perhaps the original, biggest, and certainly grandest bazaar of them all is the Internet. Although it started with attempts at significant design, sort of a cathedral-like project (maybe a small church), it soon got away from the original team and was modified and extended in many different ways unanticipated in its youth. Anyone can set up a booth on the Internet and hawk his unique wares if he follows some pretty simple rules. On the other hand, a cathedral in this milieu might be AOL or MS-NET, where one can attend, but on which one is not likely to develop a new killer "app." The bazaar model is much more than just free software: It is openly available source code which is developed, debugged, and modified by an engaged set of its active users, and those users are not picked by, nor work for, any one authority. This model of software development is reported to have been the inspiration for NetScape, Inc. to change its development strategy and to start giving away source code to its browser earlier this year. Okay, okay, so the ES is getting pretty far away from seismology. Before every readerÍs eyes have glazed over, he will attempt to bring this back to something vaguely relevant. At first glance one might think that most software written for seismological use is of the bazaar type. Of course, the big commercial seismic processing packages and programs such as rdseed or weed from IRIS underwent cathedral-type development, but what about the smaller, freely available packages written by one or two talented seismologists, such as SAC or Hypoinverse? The ES thinks that such packages are, in a sense, also cathedral packages, or at least churches. They are designed and written by one person or a few tightly coordinated individuals with their own visions of what the package should do and how it should be put together. One of the earliest bazaar-type seismology packages the ES can think of is the Ad Hoc (AH) package out of Lamont. In this case a very simple waveform format and some basic utility programs were designed, and then all were invited to use and add to the collection. The package enjoyed a following in the mid-1980s and was adopted and extended by several different groups, but perhaps because it did not have strong enough active leadership to provide basic maintenance and documentation, it has languished in recent years. Similar to AH, the CSS database schema and utilities enjoyed a diverse following with compatible development efforts coming from a variety of different camps. Strong support from the nuclear test monitoring community and its simple but powerful design have extended its usefulness to the present time. A number of high-quality, cathedral-type software packages such as Geotools, Datascope Application Package, and the AnalystÍs Review Station (ARS) of SAIC have been based on CSS. An example of a less successful approach to the bazaar model of software development is the Seismic Unified Data System (SUDS), which began about ten years ago. In this case a fairly sophisticated and very computer-sciencey design concept was developed with an attempt to be very inclusive. A great deal of effort was made to solicit lots of input and participation from the comunity. Even though SUDS was well promoted and seemed to be a viable concept, for some reason it never really caught on. The ES is of the opinion that more than a good design and promotion are needed for a bazaar to succeed. At least a few working booths with interesting wares must be set up to attract other players to join the party. While there are certainly other bazaar examples of seismology software development, a recent effort which the ES thinks provides a good example is the Earthworm project. (Finally the third term in the title for this article is invoked!) Earthworm was originally a sytem to be designed and built by a small group of primarily computer specialists at the U.S. Geological Survey in Menlo Park and then added to by anyone interested. Its main purpose was to provide a seismic acquisition and automatic processing system for regional seismic networks. The design concept was that a single seismic processing task would be handled by a single cheap computer, each listening and talking on a local ethernet. New modules could be designed by anyone and built independently of one another. The main USGS Earthworm team was to get it going and then take modules built by others and armor-plate them to be robust, tested, and well documented. The modularity and scalability of the concept were touted as major attributes. Of course, original concepts and plans have a habit of getting into trouble when the action begins. The getting-things-going took much longer than many had hoped, and it looked as if an extended cathedral construction project would result. However, the need was great and the concept sound, and after several years a working base system was generated to replace the aging Real-Time-Pickers (RTPs) the USGS relied on. Then Earthworm escaped from the original development group. At both the University of Alaska ("Iceworm") and the University of Washington ("Sunworm"), basic parts of the original system were grabbed and used in separate development efforts. The original system was extended and modified in ways not originally anticipated. Particularly at the U of A, significant new approaches were developed, and the original USGS group, to its credit, adapted some of these back into the original system. Thus, almost in spite of the habits of the USGS cathedral-builders, a bazaar was born. Development on the Earthworm project is currently continuing in a distributed fashon, with several different groups working on parts of the system in which they have an interest or need. While the original USGS Earthworm team continues to develop code for the system, its role must change. For a bazaar to work there must be not only participation by many but also coordination and synthesis by an authority figure. The stalls must be organized in some sort of order and, at least, face the same way. This authority must be willing to accept the unconventional and help adapt it to the system even if it has no interest in it nor even thinks it is a wise approach. The participants must be willing to contribute their efforts, following the basic rules administered by the authority, and take suggestions for how their parts can best be integrated. The authority figure in this case is the USGS Earthworm team, which must modify its role as the system developer to be a careful blend of computer sophisticate, traffic cop, promoter, and behind-the-scenes director. It must be willing to accept, understand, support, and even promote concepts, approaches, and software from many others. It remains to be seen if the Earthworm project will flourish, but the ES is convinced that the bazaar model for development is an imperative if it is to do so. On a bigger scale, a different seismic development project is ripe for the bazaar model. The IRIS-sponsored FISSURES project has all the potential of becoming the next-generation definitive approach to seismic data processing. This project has both financial support from IRIS and community interest. It's still too early to see the direction it is going, but it seems to be moving. At the risk of preaching to the choir the ES suggests to potential bazaar coordinators/authority figures several rules to follow for effective software development using this model.
REFERENCES
SRL encourages guest columnists to contribute to the "Electronic Seismologist." Please contact Steve Malone with your ideas. His e-mail address is steve@geophys.washington.edu.
Posted: 14 September 1998 |