You make a number of good points and it is interesting to hear the catchwords through your ears. On the subject of long-term funding we do have another model and that is the Library. Libraries have base funding for services – they don’t have to write grants. That doesn’t mean we want a library model for tools, though libraries effectively now run all sorts of search tools. Perhaps what we want is a model where new tools are developed by grant funded teams and then, if they are worth using on content, they get taken over by libraries.

I think you are right about the tool vs component business. I think that is what we were trying to get at with the idea of methods and recipes. A tool becomes a component when it is in the context of a research task.

The social side to tool development is the new perspective. We are all trying to figure out how to leverage all that creative thinking out there. I’m not sure we know how.

During the conference I snatched up some catchwords that, well, really caught me: reputational sites, discoverability and atomic tools. Obviously they are in close relation to the items Geoffrey’s breakout group came up with.

As a non-native speaker I do not know as to whether “reputational sites” is a common labeling, but recognition and reputation seem to point at the same concept of why people are motivated to do things – and sometimes even doing things for free. Look at at the open source community in general! It actually works. As a example of an already existing “reputational site” the website “http://www.ohloh.net/” might serve even better than “http://iterating.com/” which is more concerned about structuring the items.

Long-term funding without constantly writing grants – that sounds like a scientific utopia. Nevertheless, when it comes to funds it is always easy to argue that reusing what has already been paid for reduces costs. But what is out there to reuse? “Discoverability” appears slightly more apposite here than “visibility”. In my opinion it includes not only finding the tool, but finding out if it fits you. In short: discovering its context of use.

The last catchword “atomic tools” is something that kept my mind busy the recent two years. Tech guys like me fancy the concept of doing things as generic as possible. Beauty is our business. Although, in the end, being utimately generic is very often a kind of utopia thinking, too. A hard but inevitable lesson. Pondering on it, even defining what a tool _is_ seems to be really difficult.

I would describe a tool as an “artifact that supports or enables you to perform a task”. In order to talk about what makes something a tool for you, you first need to specify what task you are willing to do. (On the conference it took me a while to roughly find out what this meant to the majority.) The artifact, on the other hand, can scale from (cyber-)infrastructures down to systems, from systems to servers and applications (and nowadays often services), further down to scripts, macros and templates. (Perhaps even a piece of documentation could become a tool according to that definition. A recipe, if you like so.)

From this hierarchical point of view it might become clearer why the e-publishing working group at Humboldt University likes to talk about “publishing components” instead of “publishing tools”. It accents that there is a more complex context, a workflow or a process that frames the task in multiple ways and that the tool must fit in. Therefore, when it comes to tool silos I personally share the belief that finding suitable ways of describing the component character of a tool will increase “discoverability”.

What I take home for the CARPET project (http://www.dini.de/english-pages/carpet/) – which is actually addressing many of the discussed ideas for the domain of e-publishing – is an increased focus on the social side of tools, their usage and development. People talking to each other will step into the breach whenever a given structure of description has come to its limitations.

Thanks a lot,
Robin