[kforge-dev] environments, applications, services?

[John Bywater]

We have written some Python software called KForge.

One can install it, and then provide various different KForge 
application services using the same installation. You can also install 
KForge a number of times, so different installed versions can be run 
separately on the same machine.

Just now in KForge, such an application service has been named 
"environment".

Although this follows Trac, I think it is a terrible name, because 
environment usually denotes that which surrounds and conditions a being, 
rather than directly denoting a being as such.

Rather than Trac, I propose we follow a broader and more established 
current. The term Application Service Provider (ASP) has been around now 
for many years, and seems not to have distributed confusion throughout 
the world.

As such, I would propose we adopt these terms and definitions:

1. Application. Something one can install. An application of software 
written in an established software programming language (to include: the 
idea of the system, the system design, the working code--installed or 
otherwise).

2. Service. Something installed. "An instance of an application", or 
"the affect supported by the working code" - "it's features, 
capabilities, or function", "what it was designed to do" (to include: a 
service provided by installing an application, regardless of whether or 
not the installed application is capable of supporting various different 
services from the same single installation, and regardless of whether or 
not various different services are provided using one or many different 
installations of the application).

3. Provider. Somebody who installs something. Human beings responsible 
for delivering the affect of the working code (the service) to client users.

I propose this irrespective of the objects of KForge.

Particularly I don't propose to avoid a supposed "collision" with the 
Service object in the KForge domain model. Indeed, the usage of the term 
'Service' in KForge conforms with the above meanings: a service in 
KForge is an instance of the set of affects of a (plugged-in) software 
application.

In summary, one can download Trac a software application. One can 
install the download, and provide a Trac application service.

One can also download the KForge software application. One can install 
the download, thereby creating a "service of KForge" (another 
application service).

Then, one can use KForge to provide many Trac application services 
within the KForge application service. This is because the KForge 
software application supports plugging in the Trac software application. 
When services are provided using KForge in this way, we could denote 
them either as "services in KForge" or as "a KForge service of a 
particular plugin".

To be meaningful, the word phrase "a KForge service" does need adequate 
context to provide disambiguation between the alternative meanings: 
"service of Kforge" or "service in KForge".

So when we speak about services and KForges we must try to be clear 
about what we are talking about. It shouldn't be too hard to indicate, 
or to ask.

We could give services of KForge individual names. For example, we use 
the name "KnowledgeForge" to denote the service of KForge provided by 
the Open Knowledge Foundation at http://knowledgeforge.net/. The 
KnowledgeForge service has a project called KForge, which has a 
Subversion service, and a Trac service.

Does this make sense? I suppose, the fact that "service" is becoming 
oversignified is merely the affect of the software industry's moving to 
software-as-a-service (away from software-as-a-commodity, with 
restrictive EULAs), as a continuation of the more general movement to 
"service economy" (which as everybody knows, exists on the series: 
commodity-service-relationship-brain-... :-) ).

Best wishes,

John.