LibLime Enterprise Koha Q&A
Hi folks, I would like to further clarify LibLime's recent announcement about the LibLime Enterprise Koha platform and its implications for the greater Koha community, as well as LibLime customers. First, we at LibLime apologize for what may have seemed like a surprise announcement. We have been working hard on creating a business model that will both ensure the success of our customers and the long-term viability of Koha. We hope that the discussion below in Q & A format will help promote better understanding about what we are doing, and that we can all move forward, wishing each other well. Q: Is LibLime Enterprise Koha a 'Fork' of Koha? A: LibLime Enterprise Koha is not a 'fork' of Koha. LibLime Enterprise Koha is a set of deployment and development procedures that allows us to provide our customers with ongoing updates to Koha on a realistic schedule. This is a change in process for LibLime, but not a change in philosophy. Prior to this change, our development process began with contribution to the Koha community, often before a set of patches was even approved by the sponsoring customer. This real-time contribution process created enormous overhead, especially given the volume of development that LibLime is involved in (which historically and currently represents an order of magnitude more than the entire rest of the community combined). Our new approach moves the contribution phase of development to the end of the cycle, which allows us and our customers adequate time to vet the functionality and to ensure that it integrates seamlessly with the public Koha repository. Q: Has LibLime withdrawn from the Koha community? A: LibLime has not withdrawn, and does not intend to withdraw, from the Koha community. LibLime has invested significant resources into Koha development and community infrastructure and will continue to do so. LibLime will publish our LibLime Enterprise Koha enhancements. The integration process with the main Koha code repository will be a seamless one. We currently support dozens of libraries running on official Koha versions on their own servers and it is critical to their success that they benefit from the LibLime customer-sponsored contributions. Q: Is LibLime Enterprise Koha truly open source both in the letter and spirit of the movement? A: Our announcements are clear on this issue. From the press release "Just to make one thing crystal clear: All of LibLime's development efforts will be available to the library community under an open-source license," ... "These are process changes, not philosophical changes. As the leader in open-source solutions for libraries, LibLime is 100% committed to the open-source movement." Q: Why has LibLime chosen to deploy LibLime Enterprise Koha as a Software as a Service offering only? A: Our new cloud-computing platform makes the process of developing, upgrading and maintaining Koha a seamless and fully-automated process. We have not yet developed the mechanism for managing remote Koha installations outside of our platform. The requirements for keeping these off-platform installations in sync with the rest of our install base is not feasible. We are 100% committed to continuing to upgrade our Appliance customers(non-hosted) and to keep them in step with the latest community-released versions of Koha. Thanks for your understanding. Sincerely, Josh -- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE CEO migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
This is good news to hear. The question burning in my mind as a developer is this: will your enterprise version be available via git as you develop it, or will you just be releasing tarballs of source on a periodic basis ( which is how I interpreted your press release ). Thanks, Kyle http://www.kylehall.info Information Technology Crawford County Federated Library System ( http://www.ccfls.org ) On Tue, Sep 15, 2009 at 5:15 PM, Joshua Ferraro <jmf@liblime.com> wrote:
Hi folks,
I would like to further clarify LibLime's recent announcement about the LibLime Enterprise Koha platform and its implications for the greater Koha community, as well as LibLime customers.
First, we at LibLime apologize for what may have seemed like a surprise announcement. We have been working hard on creating a business model that will both ensure the success of our customers and the long-term viability of Koha. We hope that the discussion below in Q & A format will help promote better understanding about what we are doing, and that we can all move forward, wishing each other well.
Q: Is LibLime Enterprise Koha a 'Fork' of Koha?
A: LibLime Enterprise Koha is not a 'fork' of Koha. LibLime Enterprise Koha is a set of deployment and development procedures that allows us to provide our customers with ongoing updates to Koha on a realistic schedule.
This is a change in process for LibLime, but not a change in philosophy. Prior to this change, our development process began with contribution to the Koha community, often before a set of patches was even approved by the sponsoring customer. This real-time contribution process created enormous overhead, especially given the volume of development that LibLime is involved in (which historically and currently represents an order of magnitude more than the entire rest of the community combined). Our new approach moves the contribution phase of development to the end of the cycle, which allows us and our customers adequate time to vet the functionality and to ensure that it integrates seamlessly with the public Koha repository.
Q: Has LibLime withdrawn from the Koha community?
A: LibLime has not withdrawn, and does not intend to withdraw, from the Koha community. LibLime has invested significant resources into Koha development and community infrastructure and will continue to do so. LibLime will publish our LibLime Enterprise Koha enhancements. The integration process with the main Koha code repository will be a seamless one. We currently support dozens of libraries running on official Koha versions on their own servers and it is critical to their success that they benefit from the LibLime customer-sponsored contributions.
Q: Is LibLime Enterprise Koha truly open source both in the letter and spirit of the movement?
A: Our announcements are clear on this issue. From the press release "Just to make one thing crystal clear: All of LibLime's development efforts will be available to the library community under an open-source license," ... "These are process changes, not philosophical changes. As the leader in open-source solutions for libraries, LibLime is 100% committed to the open-source movement."
Q: Why has LibLime chosen to deploy LibLime Enterprise Koha as a Software as a Service offering only?
A: Our new cloud-computing platform makes the process of developing, upgrading and maintaining Koha a seamless and fully-automated process. We have not yet developed the mechanism for managing remote Koha installations outside of our platform. The requirements for keeping these off-platform installations in sync with the rest of our install base is not feasible. We are 100% committed to continuing to upgrade our Appliance customers(non-hosted) and to keep them in step with the latest community-released versions of Koha.
Thanks for your understanding.
Sincerely,
Josh
-- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE CEO migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
2009/9/16 Kyle Hall <kyle.m.hall@gmail.com>:
This is good news to hear. The question burning in my mind as a developer is this: will your enterprise version be available via git as you develop it, or will you just be releasing tarballs of source on a periodic basis ( which is how I interpreted your press release ).
I second Kyle This does sound like good news, would you be willing to make your git repository public so that others can begin the task of integrating the code back into mainstream Koha? Doing so would make any question of a fork disappear immediately, so I propose this is the quickest and easiest step to take to quell the rising unease. If it is just a change in process not philosophy then spending the 20 minutes or so to make the repository public will not be a too onerous task. Chris Koha Translation Manager
On Tue, Sep 15, 2009 at 5:52 PM, Chris Cormack <chris@bigballofwax.co.nz> wrote:
2009/9/16 Kyle Hall <kyle.m.hall@gmail.com>:
This is good news to hear. The question burning in my mind as a developer is this: will your enterprise version be available via git as you develop it, or will you just be releasing tarballs of source on a periodic basis ( which is how I interpreted your press release ).
I second Kyle
This does sound like good news, would you be willing to make your git repository public so that others can begin the task of integrating the code back into mainstream Koha?
Doing so would make any question of a fork disappear immediately, so I propose this is the quickest and easiest step to take to quell the rising unease.
If it is just a change in process not philosophy then spending the 20 minutes or so to make the repository public will not be a too onerous task.
I would like to add my voice at this point to the call for a public repo. This will certainly help bring a resolution to a number of outstanding issues between Liblime and the Koha community. The more quickly this is done, the more clarity will be communicated concerning Liblime's intentions. Regards, Christopher Nighswonger Faculty Member Network & Systems Director Foundations Bible College & Seminary www.foundations.edu www.fbcradio.or
I too would be interesting in seeing the public repository from LibLime. (If anyone is interested our repository address for Koha code is on the wiki -- http://wiki.koha.org/doku.php?id=en:development:git_repos --- amongst many other's. This wiki page is becoming very useful so I wanted to make sure to plug it again and encourage others to post their collections of public code for all to see.) -Brendan --------------------------------------------------------------------------------------------------------------- Brendan A. Gallagher ByWater Solutions CEO, Director of Innovation Support and Consulting for Open Source Software Installation, Data Migration, Training, Customization, Hosting and Complete Support Packages Headquarters: Santa Barbara, CA - Office: West Haven, CT Phone # (203)823-5847 http://bywatersolutions.com info@bywatersolutions.com --------------------------------------------------------------------------------------------------------------- On Sep 15, 2009, at 2:52 PM, Chris Cormack wrote:
2009/9/16 Kyle Hall <kyle.m.hall@gmail.com>:
This is good news to hear. The question burning in my mind as a developer is this: will your enterprise version be available via git as you develop it, or will you just be releasing tarballs of source on a periodic basis ( which is how I interpreted your press release ).
I second Kyle
This does sound like good news, would you be willing to make your git repository public so that others can begin the task of integrating the code back into mainstream Koha?
Doing so would make any question of a fork disappear immediately, so I propose this is the quickest and easiest step to take to quell the rising unease.
If it is just a change in process not philosophy then spending the 20 minutes or so to make the repository public will not be a too onerous task.
Chris Koha Translation Manager _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
I would also love to see a public repository from LibLime. I'm thrilled to have access to all of the stuff from Bywater, Catalyst, BibLibre, and independent developers around the globe. Seeing LibLime added to that list would make me so happy. Having access makes my job a lot more educational and fun. I have no doubt that the features from Liblime will be amazing. I can't wait for the world to see them! Liz Rea NEKLS On Sep 15, 2009, at 11:07 PM, Brendan Gallagher wrote:
I too would be interesting in seeing the public repository from LibLime.
(If anyone is interested our repository address for Koha code is on the wiki -- http://wiki.koha.org/doku.php?id=en:development:git_repos --- amongst many other's. This wiki page is becoming very useful so I wanted to make sure to plug it again and encourage others to post their collections of public code for all to see.)
-Brendan
--------------------------------------------------------------------------------------------------------------- Brendan A. Gallagher ByWater Solutions CEO, Director of Innovation Support and Consulting for Open Source Software Installation, Data Migration, Training, Customization, Hosting and Complete Support Packages Headquarters: Santa Barbara, CA - Office: West Haven, CT Phone # (203)823-5847 http://bywatersolutions.com info@bywatersolutions.com ---------------------------------------------------------------------------------------------------------------
On Sep 15, 2009, at 2:52 PM, Chris Cormack wrote:
2009/9/16 Kyle Hall <kyle.m.hall@gmail.com>:
This is good news to hear. The question burning in my mind as a developer is this: will your enterprise version be available via git as you develop it, or will you just be releasing tarballs of source on a periodic basis ( which is how I interpreted your press release ).
I second Kyle
This does sound like good news, would you be willing to make your git repository public so that others can begin the task of integrating the code back into mainstream Koha?
Doing so would make any question of a fork disappear immediately, so I propose this is the quickest and easiest step to take to quell the rising unease.
If it is just a change in process not philosophy then spending the 20 minutes or so to make the repository public will not be a too onerous task.
Chris Koha Translation Manager _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Hi Joshua, I was very pleased to receive your email. I felt it was such a shame that your relationship with the Koha international community was ending in such an awful way given the great contributions you have made over the years. It really would be a sign of good faith on your intentions if you could make your Git repositories available alongside the others. I understand this would take next to no time at all. Regards, Joann Ransom. Horowhenua Library Trust. On Wed, Sep 16, 2009 at 9:15 AM, Joshua Ferraro <jmf@liblime.com> wrote:
Hi folks,
I would like to further clarify LibLime's recent announcement about the LibLime Enterprise Koha platform and its implications for the greater Koha community, as well as LibLime customers.
First, we at LibLime apologize for what may have seemed like a surprise announcement. We have been working hard on creating a business model that will both ensure the success of our customers and the long-term viability of Koha. We hope that the discussion below in Q & A format will help promote better understanding about what we are doing, and that we can all move forward, wishing each other well.
Q: Is LibLime Enterprise Koha a 'Fork' of Koha?
A: LibLime Enterprise Koha is not a 'fork' of Koha. LibLime Enterprise Koha is a set of deployment and development procedures that allows us to provide our customers with ongoing updates to Koha on a realistic schedule.
This is a change in process for LibLime, but not a change in philosophy. Prior to this change, our development process began with contribution to the Koha community, often before a set of patches was even approved by the sponsoring customer. This real-time contribution process created enormous overhead, especially given the volume of development that LibLime is involved in (which historically and currently represents an order of magnitude more than the entire rest of the community combined). Our new approach moves the contribution phase of development to the end of the cycle, which allows us and our customers adequate time to vet the functionality and to ensure that it integrates seamlessly with the public Koha repository.
Q: Has LibLime withdrawn from the Koha community?
A: LibLime has not withdrawn, and does not intend to withdraw, from the Koha community. LibLime has invested significant resources into Koha development and community infrastructure and will continue to do so. LibLime will publish our LibLime Enterprise Koha enhancements. The integration process with the main Koha code repository will be a seamless one. We currently support dozens of libraries running on official Koha versions on their own servers and it is critical to their success that they benefit from the LibLime customer-sponsored contributions.
Q: Is LibLime Enterprise Koha truly open source both in the letter and spirit of the movement?
A: Our announcements are clear on this issue. From the press release "Just to make one thing crystal clear: All of LibLime's development efforts will be available to the library community under an open-source license," ... "These are process changes, not philosophical changes. As the leader in open-source solutions for libraries, LibLime is 100% committed to the open-source movement."
Q: Why has LibLime chosen to deploy LibLime Enterprise Koha as a Software as a Service offering only?
A: Our new cloud-computing platform makes the process of developing, upgrading and maintaining Koha a seamless and fully-automated process. We have not yet developed the mechanism for managing remote Koha installations outside of our platform. The requirements for keeping these off-platform installations in sync with the rest of our install base is not feasible. We are 100% committed to continuing to upgrade our Appliance customers(non-hosted) and to keep them in step with the latest community-released versions of Koha.
Thanks for your understanding.
Sincerely,
Josh
-- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE CEO migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
-- Joann Ransom RLIANZA Acting Head of Libraries, Horowhenua Library Trust.
Hello, Joshua! I was very glad to hear, that LL will publish Koha git repo. I'd really like to have a look at it - I'm not sure if I should start working on certain issues - maybe LL have already fixed them and I can move along? Piotr Wejman Biblioteka CSNE
Joshua Ferraro a écrit :
Hi folks,
We have been working hard on creating a business model that will both ensure the success of our customers and the long-term viability of Koha. mmm... strange we (BibLibre) don't need a "BibLibre enterprise Koha" to have a sustainable business (we are 9, probably soon 12, so not a magnitude from your size) We hope that the discussion below in Q & A format will help promote better understanding about what we are doing, and that we can all move forward, wishing each other well.
OK, let's see and add my comments.
Q: Is LibLime Enterprise Koha a 'Fork' of Koha?
A: LibLime Enterprise Koha is not a 'fork' of Koha. LibLime Enterprise Koha is a set of deployment and development procedures that allows us to provide our customers with ongoing updates to Koha on a realistic schedule.
This is a change in process for LibLime, but not a change in philosophy. Prior to this change, our development process began with contribution to the Koha community, often before a set of patches was even approved by the sponsoring customer. This real-time contribution process created enormous overhead, especially given the volume of development that LibLime is involved in (which historically and currently represents an order of magnitude more than the entire rest of the community combined). mmm... looking at: http://git.biblibre.com/gitstat/authors.html i'm still the 1st committer (add tipaul, Paul Poulain and Paul POULAIN
It's written here : http://www.liblime.com/products/koha/koha-solution-comparison that Enterprise Koha has many "liblime enhancements". None of them having been published. So, if not a fork, how do you call that ! I must add that, at BibLibre, we use some internal tools to host Koha. They let us check any customer installation, add a new install,... but this is NOT Koha. This is a good and full use of Linux command line. they have no licence as they are 100% internal + not used by our customers at all + not really something "releasable". Our hosted customers use a 100% standard Koha. Sometimes, we fix a bug not already included in a release but here how we do: - (Usually Nahuel) fixes the bug and build a patch - he apply it on our hosted customers - he send it to patches@koha.org - on the next release, the patch is in official release, so the "git rebase" works fine. It happend sometimes that the community says "the patch must be improved". In this case, a revert & apply of the final accepted patch does the job for our customers. (did I say I really loves git ?) patches). It's trues LLers are ranked in the firsts commiters, but it's not true that "it represents an order of magnitude more...") The same results are available from: http://www.ohloh.net/p/koha/contributors or http://git.koha.org/gitstat/chart.php?chart_parameter1=4&chart_parameter_ver=v3.00.00&submit=1&chart_parameter2_year=2009&chart_parameter2_month=0&submit=1&showcount=10 that shows for 3.0.0 LL is 1st with 2200 patches and BibLibre (add koha-fr.org and biblibre.com) 2nd with 759 patches. For 1.0, 2.0, and 2.2, LL numbers would be much differents (as for 1.0 LL and BibLibre didn't exists, and for 2.0, you didn't exist, and for 2.2 you were starting your involvement. (And please, stop saying "before 3.0, Koha was bugguy". It's simply an insult for all of us that worked hard for 1.x and 2.x, and it's just false, there were dozens of libraries using it) I'm impatiently waiting for 3.2 numbers. I think it will be: BibLibre 50% of the patches, owen, 10%, PTFS 10%, jesse weaver 10%, chris_n 10%, others 10%, and LL a few. (sorry if I forget someone, I don't have true numbers yet)
Our new approach moves the contribution phase of development to the end of the cycle, which allows us and our customers adequate time to vet the functionality and to ensure that it integrates seamlessly with the public Koha repository.
which, obviously, makes you be withdrawn from the community. As Nicolas said recently: "we're successful because of the community, not despite the community". It's a technical non-sense to pretend to release code once it's totally done. It's a big mistake ! Do you seriously think it will be possible to merge your code with our code if 6 or more months occurs between the dates? Just an example: you didn't release "Guided and saved reports organization and parameters". That's something the community want, and BibLibre could probably develop soon and quickly (we wrote the RFC on wiki.koha.org many months ago). How would you deal with this? The community version would have something, you would have another one. It's a dead end for you josh ! you won't be able to sustain the community improvements in your forked version. I know you won't believe me, but let's have a meeting in 2 years to see who was right. You can be sure i'll say and say again everywhere it's a technical non-sense and dead-end.
Q: Has LibLime withdrawn from the Koha community?
A: LibLime has not withdrawn, and does not intend to withdraw, from the Koha community. LibLime has invested significant resources into Koha development and community infrastructure and will continue to do so. You recently loose all your employees involved in the community: Galen Charlton, Nicoles Engard, Joe Atzberger. I should add (but she weren't involved in the community) Debra Denault. So, how do you plan to stay involved? Who will be involved? LibLime will publish our LibLime Enterprise Koha enhancements. The integration process with the main Koha code repository will be a seamless one. as everybody: give the git repo! should need less than one hour of work.
I want to add something: I don't have access to http://www.koha.org as writter, but we should update the homepage and the demo site links. The official demos sites should be http://demo.koha.org (in france it's demo.koha-fr.org, even if it's hosted by BibLibre), and demo OFFICIAL version, not your LEK.
We currently support dozens of libraries running on official Koha versions on their own servers and it is critical to their success that they benefit from the LibLime customer-sponsored contributions.
Critical to their success? But I predict a failure and a lot of pains to anyone choosing LEK. What is critical to the success for a library is to stay vendor independant. With LEK, the libraries won't be !
Q: Is LibLime Enterprise Koha truly open source both in the letter and spirit of the movement?
A: Our announcements are clear on this issue. From the press release "Just to make one thing crystal clear: All of LibLime's development efforts will be available to the library community under an open-source license," ... "These are process changes, not philosophical changes. As the leader in open-source solutions for libraries, LibLime is 100% committed to the open-source movement."
Q: Why has LibLime chosen to deploy LibLime Enterprise Koha as a Software as a Service offering only?
A: Our new cloud-computing platform makes the process of developing, upgrading and maintaining Koha a seamless and fully-automated process. We have not yet developed the mechanism for managing remote Koha installations outside of our platform. The requirements for keeping these off-platform installations in sync with the rest of our install base is not feasible. We are 100% committed to continuing to upgrade our Appliance customers(non-hosted) and to keep them in step with the latest community-released versions of Koha.
GPL don't require to publish the code for a hosted software. And your tools require to release LEK only hosted ! Thus, you can not publish your code and it's legal ! How lucky you are (irony) !
Thanks for your understanding.
Yes, I think I understand you. But i'm not happy with what I understand :( -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
Hi, I just got off the phone with Joshua Ferraro. My library is a LibLime customer, and we had some business to discuss. I took advantage of the opportunity to express the concern that I share with many others about LibLime making their code available to the community. He said, "We will not be making our git repo public as it contains customer-sensitive data." I asked him if I could quote him, and he said yes. So there it is. I also asked if all of the sponsored enhancements would be shared, or if a customer could withhold enhancements altogether. He said that because the code's under the GPL, it would have to be released eventually. Cheers, Daniel Grobani System Administrator John A. Graziano Memorial Library Samuel Merritt University http://www.samuelmerritt.edu/library Joshua Ferraro-3 wrote:
Hi folks,
I would like to further clarify LibLime's recent announcement about the LibLime Enterprise Koha platform and its implications for the greater Koha community, as well as LibLime customers.
First, we at LibLime apologize for what may have seemed like a surprise announcement. We have been working hard on creating a business model that will both ensure the success of our customers and the long-term viability of Koha. We hope that the discussion below in Q & A format will help promote better understanding about what we are doing, and that we can all move forward, wishing each other well.
Q: Is LibLime Enterprise Koha a 'Fork' of Koha?
A: LibLime Enterprise Koha is not a 'fork' of Koha. LibLime Enterprise Koha is a set of deployment and development procedures that allows us to provide our customers with ongoing updates to Koha on a realistic schedule.
This is a change in process for LibLime, but not a change in philosophy. Prior to this change, our development process began with contribution to the Koha community, often before a set of patches was even approved by the sponsoring customer. This real-time contribution process created enormous overhead, especially given the volume of development that LibLime is involved in (which historically and currently represents an order of magnitude more than the entire rest of the community combined). Our new approach moves the contribution phase of development to the end of the cycle, which allows us and our customers adequate time to vet the functionality and to ensure that it integrates seamlessly with the public Koha repository.
Q: Has LibLime withdrawn from the Koha community?
A: LibLime has not withdrawn, and does not intend to withdraw, from the Koha community. LibLime has invested significant resources into Koha development and community infrastructure and will continue to do so. LibLime will publish our LibLime Enterprise Koha enhancements. The integration process with the main Koha code repository will be a seamless one. We currently support dozens of libraries running on official Koha versions on their own servers and it is critical to their success that they benefit from the LibLime customer-sponsored contributions.
Q: Is LibLime Enterprise Koha truly open source both in the letter and spirit of the movement?
A: Our announcements are clear on this issue. From the press release "Just to make one thing crystal clear: All of LibLime's development efforts will be available to the library community under an open-source license," ... "These are process changes, not philosophical changes. As the leader in open-source solutions for libraries, LibLime is 100% committed to the open-source movement."
Q: Why has LibLime chosen to deploy LibLime Enterprise Koha as a Software as a Service offering only?
A: Our new cloud-computing platform makes the process of developing, upgrading and maintaining Koha a seamless and fully-automated process. We have not yet developed the mechanism for managing remote Koha installations outside of our platform. The requirements for keeping these off-platform installations in sync with the rest of our install base is not feasible. We are 100% committed to continuing to upgrade our Appliance customers(non-hosted) and to keep them in step with the latest community-released versions of Koha.
Thanks for your understanding.
Sincerely,
Josh
-- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE CEO migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
-- View this message in context: http://www.nabble.com/LibLime-Enterprise-Koha-Q-A-tp25461986p25480875.html Sent from the Koha - Discuss mailing list archive at Nabble.com.
That's too bad. I guess that's kind of seals it. Without an opportunity to merge mods more often there's really no practical way to avoid a fork. -reed On Thu, Sep 17, 2009 at 9:19 AM, Daniel Grobani <dgrobani@samuelmerritt.edu> wrote:
I took advantage of the opportunity to express the concern that I share with many others about LibLime making their code available to the community. He said, "We will not be making our git repo public as it contains customer-sensitive data." I asked him if I could quote him, and he said yes. So there it is.
Hi Josh, et al., On Wed, Sep 16, 2009 at 5:19 PM, Daniel Grobani <dgrobani@samuelmerritt.edu> wrote:
Hi,
I just got off the phone with Joshua Ferraro. My library is a LibLime customer, and we had some business to discuss.
I took advantage of the opportunity to express the concern that I share with many others about LibLime making their code available to the community. He said, "We will not be making our git repo public as it contains customer-sensitive data."
We are not asking that LL's customer's Koha dbs be made public... only that the code for the features that LL publicly obligated itself to provide such as those listed here: http://www.nabble.com/Additional-3.2-RFCs-td19448041.html#a19448041 and here: http://www.nabble.com/RFCs-for-3.2-tt17735030.html#a17735030 and here: http://www.nabble.com/RFC-3.2---hold-request-targeting-tt18989662.html#a1898... and here: http://www.nabble.com/RFC-3.2---hourly-circulation-policies-tt17735161.html#... and here: http://www.nabble.com/RFC-3.2---email-checkout-slips-tt17735195.html#a177351... and here: http://www.nabble.com/RFC-3.2---enhancements-to-notifications-and-messaging-... and... and... And BTW... what happened to the Joshua Ferraro seen in this quote: "It'd be cool if we could push reports upstream to the community as part of the http://contribs.koha.org site, with a new feature to allow you to find and add reports to your Koha system that others had created and pushed up ... Josh " taken from here: http://www.nabble.com/RFC-3.2-%3A-guided-reports-improved-tt18832709.html#a1... The operative phrase in that quote is: ..."push ...upstream to the community..." That is the Josh I'm familiar with. Josh: I'd say that if you (as representing LibLime) cannot make good on the above commitments (which we must remember were to be included in the 3.2 release), then you (and LibLime) have failed to honor your word. If this is true (and I truly hope you will prove it not to be) then this is a question of character. I would submit that whatever short-term gains LibLime stands to obtain by sacrificing its word will pale in comparison to the long-term losses LibLime will suffer in the loss of character in both the FOSS community and the business community. I would encourage you (LibLime) to invest the time it will take, even if it is "off the clock," to produce a non-proprietary copy of your git repo and make it public. This will speak *volumes* to both communities. Regards, Chris Christopher Nighswonger Faculty Member Network & Systems Director Foundations Bible College & Seminary www.foundations.edu www.fbcradio.org
Joshua Ferraro-3 wrote:
Hi folks,
I would like to further clarify LibLime's recent announcement about the LibLime Enterprise Koha platform and its implications for the greater Koha community, as well as LibLime customers.
First, we at LibLime apologize for what may have seemed like a surprise announcement. We have been working hard on creating a business model that will both ensure the success of our customers and the long-term viability of Koha. We hope that the discussion below in Q & A format will help promote better understanding about what we are doing, and that we can all move forward, wishing each other well.
Q: Is LibLime Enterprise Koha a 'Fork' of Koha?
A: LibLime Enterprise Koha is not a 'fork' of Koha. LibLime Enterprise Koha is a set of deployment and development procedures that allows us to provide our customers with ongoing updates to Koha on a realistic schedule.
This is a change in process for LibLime, but not a change in philosophy. Prior to this change, our development process began with contribution to the Koha community, often before a set of patches was even approved by the sponsoring customer. This real-time contribution process created enormous overhead, especially given the volume of development that LibLime is involved in (which historically and currently represents an order of magnitude more than the entire rest of the community combined). Our new approach moves the contribution phase of development to the end of the cycle, which allows us and our customers adequate time to vet the functionality and to ensure that it integrates seamlessly with the public Koha repository.
Q: Has LibLime withdrawn from the Koha community?
A: LibLime has not withdrawn, and does not intend to withdraw, from the Koha community. LibLime has invested significant resources into Koha development and community infrastructure and will continue to do so. LibLime will publish our LibLime Enterprise Koha enhancements. The integration process with the main Koha code repository will be a seamless one. We currently support dozens of libraries running on official Koha versions on their own servers and it is critical to their success that they benefit from the LibLime customer-sponsored contributions.
Q: Is LibLime Enterprise Koha truly open source both in the letter and spirit of the movement?
A: Our announcements are clear on this issue. From the press release "Just to make one thing crystal clear: All of LibLime's development efforts will be available to the library community under an open-source license," ... "These are process changes, not philosophical changes. As the leader in open-source solutions for libraries, LibLime is 100% committed to the open-source movement."
Q: Why has LibLime chosen to deploy LibLime Enterprise Koha as a Software as a Service offering only?
A: Our new cloud-computing platform makes the process of developing, upgrading and maintaining Koha a seamless and fully-automated process. We have not yet developed the mechanism for managing remote Koha installations outside of our platform. The requirements for keeping these off-platform installations in sync with the rest of our install base is not feasible. We are 100% committed to continuing to upgrade our Appliance customers(non-hosted) and to keep them in step with the latest community-released versions of Koha.
Thanks for your understanding.
Sincerely,
Josh
-- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE CEO migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
-- View this message in context: http://www.nabble.com/LibLime-Enterprise-Koha-Q-A-tp25461986p25480875.html Sent from the Koha - Discuss mailing list archive at Nabble.com.
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Daniel Grobani wrote:
[Josh] said, "We will not be making our git repo public as it contains customer-sensitive data." ... I also asked if all of the sponsored enhancements would be shared, or if a customer could withhold enhancements altogether. He said that because the code's under the GPL, it would have to be released eventually.
When, after his customers' social security numbers had been excised from the code? I think the statements Josh has been making just don't add up. He insists that LibLime is not forking Koha, but that's not consistent with his other statements. I asked on the LibLime-users list:
Will any contributions from the community be refused to LibLime customers?
Josh responded:
LibLime's goal is to include all quality contributions to Koha in LibLime Enterprise Koha, regardless of the source. Of course, contributions that do not meet our quality standards or that introduce bugs, will not be included.
And I asked:
Will Liblime work to fix bugs in community contributions which prevent them from being included?
If not, then LibLime Enterprise Koha is a fork of the official Koha. The two will continue to diverge until no community contribution to Koha will be able to be easily incorporated into LibLime's fork.
His response:
The best way to ensure that LibLime Enterprise Koha and the official Koha community codebase do not diverge is to encourage community contributors to put better controls in place for controlling the quality assurance process and to reject patches that introduce bugs.
I interpret this as meaning: If LibLime thinks a community-contributed, RM-approved patch is deemed "unstable," LibLime will reject it from LibLime Enterprise Koha. How is this not a fork? -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
Owen Leonard a écrit :
The best way to ensure that LibLime Enterprise Koha and the official Koha community codebase do not diverge is to encourage community contributors to put better controls in place for controlling the quality assurance process and to reject patches that introduce bugs.
I interpret this as meaning: If LibLime thinks a community-contributed, RM-approved patch is deemed "unstable," LibLime will reject it from LibLime Enterprise Koha.
I would just citate the linus law: http://en.wikipedia.org/wiki/Linus%27_Law
How is this not a fork?
well, evidence is sometime not easy to admit... -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
Reply inline: On Thu, September 17, 2009 01:51, Owen Leonard wrote: [...]
I asked on the LibLime-users list:
Will any contributions from the community be refused to LibLime customers?
Josh responded:
LibLime's goal is to include all quality contributions to Koha in LibLime Enterprise Koha, regardless of the source. Of course, contributions that do not meet our quality standards or that introduce bugs, will not be included.
And I asked:
Will Liblime work to fix bugs in community contributions which prevent them from being included?
If not, then LibLime Enterprise Koha is a fork of the official Koha. The two will continue to diverge until no community contribution to Koha will be able to be easily incorporated into LibLime's fork.
His response:
The best way to ensure that LibLime Enterprise Koha and the official Koha community codebase do not diverge is to encourage community contributors to put better controls in place for controlling the quality assurance process and to reject patches that introduce bugs.
I interpret this as meaning: If LibLime thinks a community-contributed, RM-approved patch is deemed "unstable," LibLime will reject it from LibLime Enterprise Koha.
How is this not a fork?
It is my understanding that at least at one time concern over code quality had motivated a degree of separateness from the community in LibLime code development. Accusations back and forth about code quality and contribution level do not help to encourage a spirit of cooperation. Concern about code quality is a serious issue but it needs cooperation to address well. Isolated development processes may protect against some types of bugs but make other types of bugs more likely and ensures that design issues are not as well considered as they would be with input from a wider range of ideas. All software has bugs and I know of severe bugs contributed to Koha by most everyone who has been contributing a significant amount of code. Some bugs are not necessarily obvious unless the code is available for inspection. Failing to expose code to the widest number of people merely ensures that fewer bugs will be caught and that they will persist longer. Free software is certainly about more than mere open source development methodology. Free software is about ensuring user freedom in software allowing the user to control the software being used instead of merely being subject to the software. User freedom is maximised when the user has the widest ability to modify and share code. Lack of code sharing restricts user freedom. [...] Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783
Daniel Grobani a écrit :
Hi,
Hi Daniel,
"We will not be making our git repo public as it contains customer-sensitive data." Just a short answer: That's a so poor, so illogic, so technically irrelevant, and Josh is a so smart developer, that I simply can't believe LL made it that way !
-- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
Reply inline: On Thu, September 17, 2009 07:44, paul POULAIN wrote:
Daniel Grobani a écrit :
Hi,
Hi Daniel,
"We will not be making our git repo public as it contains customer-sensitive data." Just a short answer: That's a so poor, so illogic, so technically irrelevant, and Josh is a so smart developer, that I simply can't believe LL made it that way !
I can believe that people do many poorly conceived things when they are in a hurry. I also know that Git is a very robust tool which can be used to manage much more than source code data. However, as we know that Joshua is cleverer than the statement implies we should encourage clarification of such an answer even if it is merely a quoted answer where he may have had more to say. We know that Joshua is clever enough to manage Git in a manner which would easily avoid including customer sensitive data in a publishing a LibLime Git repository.. I offer my assistance to Joshua if he has any difficulties in the matter just as I am confident that others better qualified to offer such assistance would offer assistance themselves. Despite some acrimony, I know that there is a Koha community which stands ready to help LibLime in what may be some real difficulties if LibLime is willing to accept that help. [...] Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783
Reply inline: On Thu, September 17, 2009 07:44, paul POULAIN wrote:
Daniel Grobani a écrit :
Hi,
Hi Daniel,
"We will not be making our git repo public as it contains customer-sensitive data." Just a short answer: That's a so poor, so illogic, so technically irrelevant, and Josh is a so smart developer, that I simply can't believe LL made it that way !
I can believe that people do many poorly conceived things when they are in a hurry. I also know that Git is a very robust tool which can be used to manage much more than source code data. However, as we know that Joshua is cleverer than the statement implies we should encourage clarification of such an answer even if it is merely a quoted answer where he may have had more to say. We know that Joshua is clever enough to manage Git in a manner which would easily avoid including customer sensitive data in a publishing a LibLime Git repository.. I offer my assistance to Joshua if he has any difficulties in the matter just as I am confident that others better qualified to offer such assistance would offer assistance themselves. Despite some acrimony, I know that there is a Koha community which stands ready to help LibLime in what may be some real difficulties if LibLime is willing to accept that help. [...] Thomas Dukleth Agogme 109 E 9th Street, 3D New York, NY 10003 USA http://www.agogme.com +1 212-674-3783
"Thomas Dukleth" <kohalist@agogme.com> wrote:
On Thu, September 17, 2009 07:44, paul POULAIN wrote:
Daniel Grobani a écrit :
"We will not be making our git repo public as it contains customer-sensitive data." Just a short answer: That's a so poor, so illogic, so technically irrelevant, and Josh is a so smart developer, that I simply can't believe LL made it that way !
I can believe that people do many poorly conceived things when they are in a hurry. I also know that Git is a very robust tool which can be used to manage much more than source code data.
Yes, this is a main reason for the difficulty of republishing private forks. Not only do you have to make sure that the git HEAD doesn't contain confidential data that was added in error, but also that the visible history doesn't show it. With things like Electronic Data Interchange and securing RFID terminals on private networks, and (not wishing to insult past helpers) with contractors who aren't familiar with the all-is-open FOSS/co-op way of working, it's disappointingly common for things like account details or encryption certificates to end up in the code. They shouldn't be there, but on a non-FOSS ILS, it probably wouldn't matter as long as they get cut out before the full release. The punishments for publishing personal data are scary enough that to be sure, I've now resorted to making patch files and applying those to the gitorious tree that chris has kindly made available to us. It's a damn slow process and we only had 3 workers on Koha at any time - I shudder to think how big a reconcilement Josh faces - but we are committed to making our Koha a proper public superset of the mainline and we will get there. I thought the US privacy laws were less severe than ours, but I guess companies are more litigious and would sue if LibLime published any account details. Even so, our fork was only a temporary convenience - which has actually turned out to be inconvenient enough that we'll not do it like that again - and we are committed to merging. It would be really good to see a similar commitment to merge with the mainline from LibLime and not just publish periodically. Then there are the foundation and asset management questions for LL... Regards, -- MJ Ray, member of www.software.coop Experts in web and GNU/Linux (TTLLP # in subject emails = copy to all workers unless asked.) Turo Technology LLP, reg'd in England+Wales, number OC303457 Reg. Office: 36 Orchard Cl., Kewstoke, Somerset, GB-BS22 9XY
MJ Ray a écrit :
"Thomas Dukleth" <kohalist@agogme.com> wrote:
On Thu, September 17, 2009 07:44, paul POULAIN wrote:
Daniel Grobani a écrit :
"We will not be making our git repo public as it contains customer-sensitive data."
Just a short answer: That's a so poor, so illogic, so technically irrelevant, and Josh is a so smart developer, that I simply can't believe LL made it that way !
I can believe that people do many poorly conceived things when they are in a hurry. I also know that Git is a very robust tool which can be used to manage much more than source code data.
Yes, this is a main reason for the difficulty of republishing private forks. Not only do you have to make sure that the git HEAD doesn't contain confidential data that was added in error, but also that the visible history doesn't show it.
A suggestion: git rebase -i => reorder your patches to put the offending patch on top git reset --hard => remove it from your git tree rm offendingfile.csv => remove the file definetly HTH (did I already say I love git ?) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
On Thu, Sep 17, 2009 at 3:44 AM, paul POULAIN <paul.poulain@biblibre.com>wrote:
"We will not be making our git repo public as it contains customer-sensitive data." Just a short answer: That's a so poor, so illogic, so technically irrelevant, and Josh is a so smart developer, that I simply can't believe LL made it that way !
Of course. In this case, the "sensitive data" just happens to be the customer-commissioned Koha code itself. Different terminology for the same excuse.
participants (16)
-
Brendan Gallagher -
Chris Cormack -
Chris Nighswonger -
Daniel Grobani -
Joann Ransom -
Joe Atzberger -
Joshua Ferraro -
Kyle Hall -
Liz Rea -
MJ Ray -
Owen Leonard -
paul POULAIN -
Piotr Wejman -
Reed Wade -
Thomas Dukleth -
Thomas Dukleth