[kforge-dev] environments, applications, services?
john.bywater at appropriatesoftwarefoundation.org
Thu Apr 13 11:10:27 UTC 2006
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
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
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
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
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
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
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-... :-) ).
More information about the kforge-dev