[Koha] Koha (was Introduction - Sean McIntyre)

[Sean McIntyre]

Hi Chris N,

Thanks for the nice welcome.  Just curious, what high school did you 
graduate from?  I graduated from Robinson in '85.

So if I understand your first paragraph, the confusion was created when 
we made available a "flavor" for download, rather than just submitting 
changes back to the community elected release manager.  Did I understand 
that correctly?  If so, I can say that there is no intent to ever do 
such a thing again for a variety of reasons, including the confusion it 
has caused.

Glad to hear your point that the different "flavor" issue pre-dates the 
acquisition, we certainly felt we had inherited a challenge in this area.

I like your point on simply merging everything back together and thus 
eliminating these complexities.  This is not a small piece of work by 
any means, but I am biased towards "simple".  Unfortunately, the LLEK 
code base was not maintained in such a way as to make merging back with 
the community maintained Official Koha easy; it in fact will be 
challenging.  No one can say with certainty what the intent of the 
LibLime owners were at the time LLEK was established, but if they were 
intending to fork the code it would look very much like what we have 
acquired.

As you point out, we have made available all of the software 
enhancements and mods that pre-date the acquisition in a fashion that 
the release managers can work with them.  This was not difficult for us 
as we had always intended to do this and had thus maintained the 
baseline in a fashion that made this easy to do.  As I've said, this is 
not the case on LLEK due to decisions made by the previous owners.  So, 
while we have the goal of a single baseline, we have customer 
commitments in the near term that will delay this for some time.  If we 
could, we'd consider doing it immediately, but the projects we have 
inherited and their schedules are such that this seems unlikely.  At a 
certain point we have to prioritize the paying clients above other work 
and this appears to us to be one of those cases; there is just not 
enough time and resources to do everything at once.

So, while we seem to be in agreement on the goal (which is great!); 
achieving this in the next few weeks or months, while meeting our client 
commitments is just not very likely.  It would be great for LibLime (me 
in particular), to not have these multiple baseline issues, but that's 
not the hand I've been dealt.  So, please accept my assurance that we 
share the goal of a single baseline over time and are going to take 
incremental steps towards that as we work on our client commitments, but 
this will take a good deal of time to get where we all want to be.  The 
lesson for all involved is that un-doing a fork is painful and expensive.

Best,
Sean McIntyre
Engineering Mgr, ILS
LibLime, a Division of PTFS



On 5/14/2010 11:16 PM, Christopher Nighswonger wrote:
> 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
>