How do we make Tools easier to share and transfer?

The decentralized nature of developing metrics has resulted in some silos being replicated in ecosystem services metrics. Developing truly integrated metrics has been a challenge, often because resources are limited for development, drivers are focused on single issues, or expertise is focused in one area. Some general tool dimensions are common across efforts to date. Tools or metrics can be grouped into value based and unit based systems. The value based ones include the economic valuation methods that really define many of the ecosystem service discussions out there. They tend to be more macroeconomic and at a landscape or regional scale. These are clearly not great for those of us working on transactions.

The unit based systems that allow for metrics are very diverse. They are site based and often have some field data inputs - but can be grouped into condition, model or function based. Condition based are the set of metrics that look at outcomes of environmental management, such as measures of pollutant load, species counts, vegetation counts, and so on. Model based is often a landscape or process model that is tied to best practices that allow for site level decisions. Carbon credits are a good example of this type. The final type are function based systems. Function based systems combine some of the condition and model traits - but try to measure site level performance of objective ecological, physical, chemical or even social functions at a site level. Where condition based systems look for a response, function based prescribe the conditions needed to achieve a response. The benefit of function based in a transactional world is that it allows for controlling for exogenous forces. (It is a policy call on whether exogenous barriers matter or not.)

As tools continue to be developed - this type of meta-analysis is necessary to strategize across applications, developers and geographies. Tools depend on the mix of ecological realities, institutional and regulatory drivers, and the goals for ecosystem services. Discussion of the dimension of these forces on tool developers can go a long way to developing more inclusive, comprehensive and transportable tool.

As a software developer, I can relay this bit of wisdom: If you want something you develop to be reusable by others, it must have a clearly defined and documented public programmer's interface (this usually means a published software API), and if it is too large to manipulate logically via one central API, then the software should be split into modules of a more sensible size. Additionally and very importantly (although far too frequently overlooked), it must have a free software license if anyone else other than the original developer is ever going to be able to extend of modify it.

The rather obvious (and too often lacking) requirement here is that to manipulate and extend other people's software tools, you will need to be a programmer or have the resources to hire one. If on the other hand, you simply want everyone's end-user application to link to everyone else's application, that (I am afraid) is typically untenable, partly due to the additional workload you are giving to every tool-maker to link their tool to everyone else's and partly due to the political reality that only the tools with the most marketing are actually going to be considered for linking in the first place.

Let's take GRASS GIS (http://grass.fbk.eu) as an example of doing the software reusability thing correctly.

The entire GRASS system is written in ANSI C with a published API. Because it is such a large package, the codebase is divided into several hundred modules, each of which may be executed independently of the others. In fact, every command in GRASS is an independent executable which accesses the internal GRASS databases using an ANSI C library called libgrass.

If, as an ecosystem services tool developer, I wished to create a model based on TOPMODEL (a physically based hydrologic model), I could write a program in ANSI C, which used the code in libgrass and the r.topmodel GRASS implementation of TOPMODEL as a starting point for my own ecosystem service assessment.

If I already have a program written in ANSI C (or in a language with bindings to ANSI C - which means almost all modern languages), I can simply study the GRASS APIs and build links from its functionality into my own programs. Because all of the GRASS code is available under the GNU GPL license, I can also be assured that this codebase will never be locked up from me, and even if the team responsible for GRASS were to abandon the project at some point in the future, I could still use their code to continue developing my own products.

Ah, but alas, it seems that the ecosystem service tool development arena is often more filled with software users than software developers, so bringing this kind of development rigor to fruition in this community is still probably a long way off.

  My 2c,

    Gary Johnson