[Koha] Koha (was Introduction - Sean McIntyre)

[Christopher Nighswonger]

Heya Sean,

It's nice to have you on board. We certainly look forward to having
you as a regular in the community.

As a common point of interest, I moved to the Northern VA area in 1974
and left when I graduated from High School in 1988. I did return to
work for VDOT in Fairfax, VA as an HCI for a short stint in 90 and 91.

On Fri, May 14, 2010 at 9:30 PM, Sean McIntyre <smcintyre at ptfs.com> wrote:

<snip>

> Your suggestions on language that might have been received better than
> what we chose seem quite good to me.  It was a bit of a struggle for us
> as what we were describing had inherent complexities as noted above.  We
> felt good about labeling the release 'Harley', as that had no intrinsic
> meaning.  As you say however, the language we used has caused some
> confusion.  In fact, our own customers are a bit confused as to which
> "flavor" (deliberately trying to use a term that is not overloaded) of
> Koha has the most features.  For us, there are three choices we can
> offer.  The community supported 3.2 alpha Koha, 'Harley' or the LibLime
> Enterprise Koha; each of which have some unique features that could make
> them attractive options.  Overtime, we would like these to come together
> in some fashion for a whole variety of reasons, not the least of which
> is to eliminate potential confusion.
>
> As we go forward, how would you and others like the Koha 3.2 alpha
> software referred to?  Does the phrase you have used here, "community
> supported Koha" work for the majority?  How do other vendors deal with
> this terminology challenge?  Our preference would be to use terms that
> everyone is comfortable with across the board, the greater value here is
> in the software not the labels affixed to that software.

I think one of the fundamental problems with choosing a "name" is that
there has been no vendor within the community to release a flavor of
Koha separate from that released by the community elected Release
Manager. (Someone step in and correct me if I'm wrong.) Up until a
year or so ago, the Koha community worked together as a fairly well
oiled machine. There was the broad understanding and general consensus
that everyone waited on the Release Manager for the next official Koha
release. Now I know that there were some "internal" variations of Koha
running around, but the code changes represented by them were by and
large already submitted to the RM and simply awaiting integration,
testing, and release in the official code base. But I digress...

Probably the best route to have taken would have been for LL/PTFS to
have simply pushed the Harley code base to their public git repo and
simply announced via the mailing lists/websites that they were
beginning to maintain an open public git repo and outline the features
contained in the Harley code base as an offering for inclusion into
the official code base. This is how every other vendor has
accomplished this same thing in the past.

As it is, there is now the confusion which you mention over which
"flavor" should be used by the end user. Very frankly: We have never
had that problem prior to the introduction by LL of their three
flavors about a year ago. (Now, you at least have the consolation of
knowing that this most recent move was not really the origin of this
confusion.)

So the entire concept of having to choose a "name" now for what has
always been the only official Koha release revolves around this matter
of now having multiple flavors of Koha.

I would kindly suggest that the real and final solution to the entire
issue is to be found in your last statement of the first quoted
paragraph above:

> Overtime, we would like these to come together
> in some fashion for a whole variety of reasons, not the least of which
> is to eliminate potential confusion.

Getting both the Harley and LLEK code bases merged back into the
official Koha code base and returning to a single, official release is
the best possible solution to all problems, issues, confusions, or
<your_favorite_term_goes_here>, etc.

So, to answer your naming question: We should continue to refer to the
official code base simply as "Koha" because that is what it is.
Vendors should simply make their code base available via public git
repos and refer to them as such. (I know... everyone has the "right"
to "release" their own "version." But strength is had in unity in this
case. Diversity of "released versions" will inevitably drain resources
from the official code base and the products will be the poorer for
it. One such example is given in the next paragraph.)

I would trespass a bit further on your good will and say that the
fastest way to get both the Harley and LLEK code bases re-integrated
into the official code base is to push them both to public repos and
allow the team of developers to begin merging immediately. LL/PTFS has
done this with the Harley code base. Kudos!!! This is a *very*
positive step. Let's bring this along with the publishing of the LLEK
code base as well. (A case in point demonstrating the urgency of this
need is the fact that one vendor has already begun work on hourly
loans. IIRC LLEK already has this feature. So said vendor is wasting
both time and money developing a feature which is already in
existence. That time and money could be spent developing another new
feature which, in turn, LL/PTFS would benefit from at really no
development cost to themselves. This is one of the *many* pluses of
the FOSS model; no one entity bears the full cost of R&D.)

All of this is kindly meant, and I hope has been well said.

Kind Regards,
Chris Nighswonger
Koha 3.2 Release Maintainer