I lamented the lack of public interest shown by the pharma companies in Open Source software and Geoff Hutchison commented:
When the Blue Obelisk met in San Francisco, we all heard from a pharma rep [PMR: was there a pharma rep in the Blue Obelisk meeting?] that applications get more attention than toolkits. So Jmol, Bioclipse, and hopefully Avogadro can get more attention than Open Babel, CDK, or JOELib.
PMR: We have different names for things, but I am assuming that an application is somethings that is shrinkwrapped, installs at the click of a button, has a user manual and does one or a small number of discrete actions (although applications bloat rapidly). Examples are rich renderers (hence Jmol) and editors (hence Avogadro). Then I’d see components where my ideal is a unix tool such as sed, ls, grep, with a small number of very well defined inputs and outputs. And finally a framework where several components can be configured in different ways by the user. I’d classify Bioclipse and OSCAR as frameworks, OpenBabel as a component and CDK, JOELib, JUMBO as component libraries. Stitching components together requires glueware which may be explicit (perl, python, ruby, java, etc.) or in a framework such as workflow (taverna, KNIME, Kepler, Pipeline Pilot). Glueware is difficult and expensive and often unique to the institution and I’ve talked to several people over the last week who have confirmed that one size does not fit all. and some problems aren’t fitted by any.
Using that terminology, an application does a small number of things in a reapeatble manner. Applications are not easey to reconfigure, or put differently, it is difficult to build an application which can be easily reconfigured. So increasingly the creativity is moving to those who can create “applications” from components, rather than relying on software manufacturers to do their thinking for them. If the pharma industry is to use knowledge technologies to help in its discovery it will have to get used to glueing together different data source and programmatic components. And hopefully at that stage it will discover that the Blue Obelisk can provide.
Names are slippery things when trying to classify software into Platonic ideas like this. Are MOE, PyMol, VMD, Sybyl, X-PLOR/CNS applications or frameworks? Each has a user-extensible programming language component, and several have the ability to create new user-defined GUI widgets. With their respective Python bindings I can bring OpenBabel, OpenEye or Daylight functionality into PyMol and VMD – are those two systems also glueware? The best answer is “yes, all of the above”.
(1) As someone working in ontologies I never try to be didactic – the names are either helpful or not. I would categoruse glueware as something that is likely to be non-portable and quite probably ephemeral. So I wouldn’t call any of the above glueware but suggest that – inc some cases – they can be used to provide it (though I suspect they could be better approaches). Just because something is programmable doesn’t necessary may it the best choice for glue.
Well, I was surprised to read the “small number of discrete actions” attributed to applications. I think of Word, Excel, and Firefox as applications, and they are also user extensible in various ways. If I wanted to talk about applications with only a few capabilities I think I would say “utility applications.” You mentioned sed as a unix tool which takes “a small number of very well defined inputs and outputs”, but as it’s Turing complete programming language it’s also subject to the halting problem. On top of that, how do you describe OSX .. or VMWare or Parallels or other emulators (which come shrinkwrapped with a manual, etc.)? So I don’t think the names as you described them are that helpful.
Peter, I think I’d also disagree with your definition of applications. Firefox isn’t shrink-wrapped. Some applications don’t have very good manuals. Andrew also brings up some good examples applications with built-in frameworks.
My implicit definition of applications was “a program with a user-visible interface.” The “visible” part is important these days. You have to show people what your application can accomplish. This could be a desktop application which you run locally, or a web service, like Flickr or Google Mail.
I also disagree that it is difficult to write an application which can be reconfigured or extended. Yes, sometimes it may be faster to cobble together various existing components. But Andrew’s example (and others) show that “plugins” and “scripting” are hot points with applications these days. Operating systems like Mac OS X now offer multiple scripting techniques.
My original point was from that dinner meeting at the ACS in San Francisco. If the Blue Obelisk (or open science in general) wants to demonstrate utility and the benefit for support from government, academia, and industry, it helps to have clear visible demonstrations. Personally, I think CrystalEye is a great application. So is PyMol.
(all)
FWIW Wikipedia (http://en.wikipedia.org/wiki/Application_software) has:
Application software is a subclass of computer software that employs the capabilities of a computer directly and thoroughly to a task that the user wishes to perform. This should be contrasted with system software which is involved in integrating a computer’s various capabilities, but typically does not directly apply them in the performance of tasks that benefit the user. In this context the term application refers to both the application software and its implementation.
A simple, if imperfect analogy in the world of hardware would be the relationship of an electric light bulb (an application) to an electric power generation plant (a system). The power plant merely generates electricity, not itself of any real use until harnessed to an application like the electric light that performs a service that benefits the user.
Typical examples of software applications are word processors, spreadsheets, and media players.
Multiple applications bundled together as a package are sometimes referred to as an application suite. Microsoft Office and OpenOffice.org, which bundle together a word processor, a spreadsheet, and several other discrete applications, are typical examples. The separate applications in a suite usually have a user interface that has some commonality making it easier for the user to learn and use each application. And often they may have some capability to interact with each other in ways beneficial to the user. For example, a spreadsheet might be able to be embedded in a word processor document even though it had been created in the separate spreadsheet application.
PMR: I will continue to explore this in future posts