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
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@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
Thanks for the thoughtful and constructive response, Sean. On Sat, May 15, 2010 at 7:38 AM, Sean McIntyre <smcintyre@ptfs.com> wrote:
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?
For the most part, yes. I was not suggesting that you not publish your code base at all: only that the method of maintaining a public git repo and making submissions to the current release manager is and has been the modus operandi of the community rather than each doing their own "release."
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.
Point well taken! Even the best of intentions is misunderstood at times, and I'm thrilled that we are now able to work through all of this. <snip>
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.
<snip> I think that we will just have to agree to disagree on the point of the difficulty of re-merging the LLEK code base back into the official code base. There are individuals in this community with professional experience in merging much, much more difficult messes back together than LLEK ever thought about being.
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.
A sorrowful lesson indeed. Thanks for your responsiveness, Sean. This is a refreshing change in what has heretofore been a rough relationship. Kind Regards, Chris
Hi Sean, I'd like to add my welcome to that of the others. Your words are very reassuring and I am heartened by the discussion which has followed. I look forward greatly to seeing LEK and Harley integrated back into Koha and the community going from strength to strength. NIce to have you on board and communicating so openly. It would be great if PTFS could get a few people down to KohaCon10. Would be an excellent opportunity and its only 12 hours flying time from LA - its not really the ends of the earth! Cheers Jo. On Sun, May 16, 2010 at 12:59 AM, Christopher Nighswonger <chris.nighswonger@gmail.com> wrote:
Thanks for the thoughtful and constructive response, Sean.
On Sat, May 15, 2010 at 7:38 AM, Sean McIntyre <smcintyre@ptfs.com> wrote:
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?
For the most part, yes. I was not suggesting that you not publish your code base at all: only that the method of maintaining a public git repo and making submissions to the current release manager is and has been the modus operandi of the community rather than each doing their own "release."
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.
Point well taken! Even the best of intentions is misunderstood at times, and I'm thrilled that we are now able to work through all of this.
<snip>
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.
<snip>
I think that we will just have to agree to disagree on the point of the difficulty of re-merging the LLEK code base back into the official code base. There are individuals in this community with professional experience in merging much, much more difficult messes back together than LLEK ever thought about being.
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.
A sorrowful lesson indeed.
Thanks for your responsiveness, Sean. This is a refreshing change in what has heretofore been a rough relationship.
Kind Regards, Chris _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
-- Joann Ransom RLIANZA Head of Libraries, Horowhenua Library Trust.
-----Original Message----- From: koha-bounces@lists.katipo.co.nz [mailto:koha-bounces@lists.katipo.co.nz] On Behalf Of Joann Ransom Sent: Sunday, 16 May 2010 12:23 PM To: smcintyre@ptfs.com; Koha Mailing List Subject: Re: [Koha] Koha (was Introduction - Sean McIntyre)
Hi Sean,
I'd like to add my welcome to that of the others. Your words are very reassuring and I am heartened by the discussion which has followed.
I look forward greatly to seeing LEK and Harley integrated back into Koha and the community going from strength to strength. NIce to have you on board and communicating so openly. It would be great if PTFS could get a few people down to KohaCon10. Would be an excellent opportunity and its only 12 hours flying time from LA - its not really the ends of the earth!
Cheers Jo.
On Sun, May 16, 2010 at 12:59 AM, Christopher Nighswonger <chris.nighswonger@gmail.com> wrote:
Thanks for the thoughtful and constructive response, Sean.
On Sat, May 15, 2010 at 7:38 AM, Sean McIntyre <smcintyre@ptfs.com> wrote:
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?
For the most part, yes. I was not suggesting that you not publish your code base at all: only that the method of maintaining a public git repo and making submissions to the current release manager is and has been the modus operandi of the community rather than each doing their own "release."
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.
Point well taken! Even the best of intentions is misunderstood at times, and I'm thrilled that we are now able to work through all of this.
<snip>
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
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.
<snip>
I think that we will just have to agree to disagree on the point of the difficulty of re-merging the LLEK code base back into the official code base. There are individuals in this community with professional experience in merging much, much more difficult messes back together than LLEK ever thought about being.
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
I too extend a sincere welcome to Sean. I've been greatly encouraged by the release of code in Harley and by Sean's sincere words to the list. Nonetheless an aspect of the discussion has heightened my overall concerns. I had not visited koha.org for some time. I did so today to follow up the discussion between Sean and Chris N. What has been published there is disappointing to say the least. First, there is no such thing as Community Koha. There is Koha. And there is Liblime's closed source fork. (Though enough has been written on and off this list to confirm that Liblime's customers should simply demand delivery of the source code. If that were refused, copyright holders of the software being distributed by Liblime can assert their rights. There are quite a number of people in a position to do that.) Secondly, the site unambiguously encourages libraries to download Harley as though it is something superior to Koha. What is the future upgrade path for libraries that adopt it? Whilst these, the insulting and incorrect post to koha-community.org (April 30) and the NZ trademark application remain in place, the motives of Sean's organisation remain very much in question. Bob Birchall CALYX base 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.
A sorrowful lesson indeed.
Thanks for your responsiveness, Sean. This is a refreshing change in what has heretofore been a rough relationship.
Kind Regards, Chris _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
-- Joann Ransom RLIANZA Head of Libraries, Horowhenua Library Trust. _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha No virus found in this incoming message. Checked by AVG - www.avg.com Version: 8.5.437 / Virus Database: 271.1.1/2876 - Release Date: 05/15/10 18:26:00
On Sat, 15 May 2010, Sean McIntyre wrote:
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.
Is there any reason you could not make the code repository available to the public? This would let others look at the differences and start working to figure out how to merge the two. While this is not as good as you activly pushing the code and working to merge it, it is far better than the current situation, and given the time commitments that you are referring to, it may be the best that you can do for the short term. David Lang
participants (5)
-
Bob Birchall ＠ Calyx -
Christopher Nighswonger -
david＠lang.hm -
Joann Ransom -
Sean McIntyre