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@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