Introduction

The example of GRASS GIS is used to showcase a software project of positive legacy. This kind of legacy is a valuable asset for software development. While ensuring code functionality by the careful maintenance of existing code, the approach eventually incorporates “cutting edge“ technologies once they themselves have stood the test of time. It is shown how the rise of Integrated Development Environments (IDE) will help to ensure the future-saving of the project by gradual yet strategic increasing of the developer base. The two faces of Legacy

According to Wikipedia there are two ways to apply the term “legacy” to software, which seem to be almost mutually exclusive: On the one hand, in a pro-innovation view, old application programs are considered “legacy” which continue to be used because the user does not want to replace or redesign them. Yet, on the other hand, from a task-solving perspective, legacy software often differs from its suggested alternative by actually working and scaling, making the term not pejorative at all.

Several FOSS GIS projects have been in existence for a very long time, giving them “legacy”. The most noteworthy ones may be UMN Mapserver and GRASS GIS, which are entirely community-controlled projects. The Legacy of GRASS GIS: Alive and kicking

The GRASS GIS project has been evolving for more than twenty years. Development was started by the US military (CERN). In the early 1990s, the code was handed over to academia, where development started again by the mid 1990s. The licensing under the General Public Licence (GPL) in 1999 resulted in a dramatic increase of development. Over the years, the functionality evolved from a integer raster-based GIS to include floating point operations, a topology-based vector model, volume-support and finally inclusion of OGC-services.

Apart from the traditional use as a desktop GIS, GRASS is also used as part of the backend of other applications like Quantum GIS, uDig (JGRASS). For web mapping is can be used in conjunction with UMN Mapserver or as a standalone OGC WPS-Service (pyWPS). Coding Paradigm

With a highly modular code paradigm, following the approach of (scriptable) Unix shell commands, the canonic codebase consists of more than 300 ANSI C-modules, with additional add-on scripts and modules being independently provided and hosted by the user communities.

Serial Code Development: A small group of constant contributors volunteerly adds new features and updates old ones. There is no stringent commercial development except for the FOSS-approach to hire programmers on demand to solve specific tasks.

The majority of the developer community is highly fluent in the code structure and uses text based tools for development such as vi or Emacs. For newcomers, this situation results in a steep learning curve. Besides, the constant overall development of libraries forces contributors of add-on C-modules to adapt their code. As a consequence, many C-based add-on-modules become defunct over time, while Shell-style Scripts remain usable since the C-module interfaces remain unchanged despite the internal changes. Arguing the case for extended IDE usage

During the last years Integrated Development Environments (IDEs) became widely available for code development. They allow for easy navigation in large code repositories and collaborative development. Many younger programmers consider the availability of IDEs as given. Therefore it makes sense to foster the know-how regarding GRASS-development with IDEs, such as Eclipse/CDT. Also, due to the availability of code-tracking and refactoring tools, add-on modules could much more easily being updated to the latest standards by their coders.

The decision of the GRASS GIS community to stick to C-code in the spirit of positive-legacy allowed for successful deployment of a native version for Microsoft Windows™, avoiding the performance losses of Cygwin-based installations. Since IDEs such as Eclipse are platform independent, this also allows for active code development on non-Linux systems, such as Microsoft Windows™. In regard to the “dark side of legacy” such as retiring of the current pre-IDE developers and the resulting loss in know how and skill, it is even more important to enable IDE-based development to help document the code while there is time. Conclusion

As it has been shown, GRASS GIS has proven over the last two decades to be a working and scaling geoinformation system environment. It continues to grow and is very well alive. The development approach of the community is basically conservative, yet integrates additional technologies once they are considered as mature and of relevance. The usage of IDEs is expected to extend and rejunevate the developer community. It will also broaden and speed up the development process in a second fashion, as it also enables the active development on non-linux stystems. This documents the positive, stabilizing effects of trusted software which “just works well” and can be continued to be developed on various platforms. Outlook

A tool to describe processing chains would be desirable to document and manage the community-inherent know-how about how to orchestrate the GRASS modules to cope with complex tasks. Usually every task can be solved in various ways, some of them more efficient than others.

While this knowledge remains only marginally archived, the leaving of experienced member from the user community will result in massive losses of know how and skill. A likely tool for this task is CyberIntegrator (CI), a workflow-based system that supports interactive workflow creation, connection to external data and event streams, provenance tracking, and incorporation of workflow fragments and functionality from other systems and applications. Trials for the integration of CI and GRASS GIS are underway. Once such tools have been tied into the GRASS GIS environment, the future-saving of a community driven FOSS GI-project will be ensured for years to come.