KOHA version 3.0, my question is about the advantages of KOHA 4
It is a pleasure to find KOHA community greatly strengthened. Write to La Paz Bolivia, I have implemented KOHA version 3.0, my question is about the advantages of KOHA 4 and LibLime, which presents differences. Atte -- Christian Jhonny Calle Jahuira TUTOR ELEARNING - UMSA Consultor Sistemas de Informacion de Bibliotecas de la UMSA Email: christianjcj@gmail.com Cel: 73017301 - 65151595
my question is about the advantages of KOHA 4 and LibLime, which presents differences.
The advantage of using Koha (the latest version of which is 3.4.1) is that it's part of a real open source project backed by a community of developers from around the world. Koha will always be free software and its development will always be done out in the open. "Liblime Koha," which has been arbitrarily given the version number 4, is the product of a single company which is openly hostile to the Koha community. As far as I'm concerned that's all you need to know. No feature differences between the two would be enough for me to ever recommend "Liblime Koha" over the real thing. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
PS. It's Koha (as Owen wrote it) not KOHA (sorry pet peeve of mine) - it's a word and not an acronym - if you're interested in learning more about the origin of the name check this out: http://bywatersolutions.com/2010/10/15/what-is-a-koha/ Nicole On Fri, Jun 3, 2011 at 12:00 PM, Owen Leonard <oleonard@myacpl.org> wrote:
my question is about the advantages of KOHA 4 and LibLime, which presents differences.
The advantage of using Koha (the latest version of which is 3.4.1) is that it's part of a real open source project backed by a community of developers from around the world. Koha will always be free software and its development will always be done out in the open.
"Liblime Koha," which has been arbitrarily given the version number 4, is the product of a single company which is openly hostile to the Koha community.
As far as I'm concerned that's all you need to know. No feature differences between the two would be enough for me to ever recommend "Liblime Koha" over the real thing.
-- Owen
-- Web Developer Athens County Public Libraries http://www.myacpl.org _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
On Fri, Jun 3, 2011 at 12:00 PM, Owen Leonard <oleonard@myacpl.org> wrote:
my question is about the advantages of KOHA 4 and LibLime, which presents differences.
The advantage of using Koha (the latest version of which is 3.4.1) is that it's part of a real open source project backed by a community of developers from around the world. Koha will always be free software and its development will always be done out in the open.
Owen brings up the most important point here: Koha has a community around it, while LK only has LibLime. Anyone in the world can contribute to Koha, either with patches sent to the patches mailing list [1], with bug reports filed in the Bugzilla database [2], by sharing reports/jqueries/tips/tricks on either the discussion list [3], wiki [4] or newsletter [5], or by participation in IRC discussion [6]. LK has none of those community tools (at least not anywhere where I could find them!). A statistical work up of the two codebases has been done recently, which is interesting for what it's worth [7]. One can watch Koha's codebase grow daily [8]. LK, like it's predecessor Harley, seems to be a static release rather than a living, growing organism, though I've been told that LibLime does have versions 4.4 and 4.6 in use for their clients (though not released as open source at this time). As a Koha developer and officer, I'll readily admit my bias, but hopefully the links below, as well as other posts on this thread, can help folks make their own decisions. Cheers, -Ian 1. http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-patches 2. http://bugs.koha-community.org 3. http://lists.katipo.co.nz/mailman/listinfo/koha 4. http://wiki.koha-community.org 5. http://koha-community.org/category/koha-newsletter/ 6. http://stats.workbuffer.org/irclog/koha/ 7. http://blog.bigballofwax.co.nz/2011/05/24/i-love-pulling-statistics-out-of-g... 8. http://git.koha-community.org/gitweb/?p\x3dkoha.git;a\x3drss -- Ian Walls Lead Development Specialist ByWater Solutions ALA Booth 732 Phone # (888) 900-8944 http://bywatersolutions.com ian.walls@bywatersolutions.com Twitter: @sekjal
On 2011-06-4, at 4:00 AM, Owen Leonard wrote:
my question is about the advantages of KOHA 4 and LibLime, which presents differences.
as other people before have pointed out - there is *not* an official Koha 4.x release... yet ;) (Koha is currently still releasing on version 3.x) it's also very disrespectful to the Koha project (and confusing), for ptfs/liblime to claim their fork's release as 'Koha 4' https://github.com/liblime/LibLime-Koha/blob/4_02/INSTALL "Koha 4.2 - the next-generation release of the award-winning Koha open-source integrated library system." ... and then remove all Koha contributor names from the 'about' page (wtf?!?) https://github.com/liblime/LibLime-Koha/commit/80cccbd027a950152114a69e233f9... hope that helps, Mason
Greetings, Christian. Referring to the code bases, I don't know of a point-by-point feature comparison between the various forks. However, LibLime does provide feature notes for the recent 4.2 release, available at http://www.koha.org/library/resources/LibLimeKoha4.2ReleaseNotes.pdf. You can check out the code directly in our public Git repository at https://github.com/liblime/LibLime-Koha. Cheers, Clay 2011/6/3 Christian Calle Jahuira <christianjcj@gmail.com>
It is a pleasure to find KOHA community greatly strengthened.
Write to La Paz Bolivia, I have implemented KOHA version 3.0, my question is about the advantages of KOHA 4 and LibLime, which presents differences.
Atte
-- Christian Jhonny Calle Jahuira TUTOR ELEARNING - UMSA Consultor Sistemas de Informacion de Bibliotecas de la UMSA Email: christianjcj@gmail.com Cel: 73017301 - 65151595
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
2011/6/3 Clay Fouts <cfouts@liblime.com>:
Referring to the code bases, I don't know of a point-by-point feature comparison between the various forks.
Between your fork and Koha, you mean? No, but here's a notable single comparison: "Liblime Koha:" https://github.com/liblime/LibLime-Koha/blob/4_02/koha-tmpl/intranet-tmpl/pr... Koha: http://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=koha-tmpl/intranet... "Liblime Koha" is curiously missing the list of contributors to the "open source" software they're offering. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
On 2011-06-4, at 5:07 AM, Clay Fouts wrote:
Greetings, Christian.
Referring to the code bases, I don't know of a point-by-point feature comparison between the various forks.
slightly off-topic... ohloh.com has some pretty graph comparisons (code, commits, committers, languages, etc) between Koha and the ptfs/liblime fork, https://www.ohloh.net/p/koha https://www.ohloh.net/p/Koha-PTFS-Liblime
You can check out the code directly in our public Git repository at https://github.com/liblime/LibLime-Koha.
thats great, but how do people submit enhancements to the ptfs/liblime project? Mason
Github makes patch submission very easy. The typical process is to fork the repository, commit your changes to your own fork (often on a topic branch), then submit a pull request to the maintainer of the forked project. The web interface provides simple buttons for forking (e.g. the LK-4.2 fork link is https://github.com/liblime/LibLime-Koha/fork) and issuing pull requests. The maintainer receives notification of the pull request and can then opt to merge the new commits back into the original repository. The service offers a nice interface to the whole code management process and provides additional features for discussing patches, providing line-by-line commentary, basic issue tracking, docs wiki, and so on. They offer public repositories for free, so there's a very low barrier to entry for open source developers. Internally we have released LK-4.4 and 4.6 into production and are now working on development branch 4.7. These are not publicly accessible, and that makes development of larger features pretty tricky if you're working on the 4.2 release as your base. Anyone interested in creating a more involved feature and ensuring it can be easily ported to future releases should consult us for pointers as there are notable architectural and schema differences. Regards, Clay On Fri, Jun 3, 2011 at 6:53 PM, James, Mason <mason@kohaaloha.com> wrote:
On 2011-06-4, at 5:07 AM, Clay Fouts wrote:
Greetings, Christian.
Referring to the code bases, I don't know of a point-by-point feature comparison between the various forks.
slightly off-topic...
ohloh.com has some pretty graph comparisons (code, commits, committers, languages, etc) between Koha and the ptfs/liblime fork,
https://www.ohloh.net/p/koha https://www.ohloh.net/p/Koha-PTFS-Liblime
You can check out the code directly in our public Git repository at https://github.com/liblime/LibLime-Koha.
thats great, but how do people submit enhancements to the ptfs/liblime project?
Mason _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
2011/6/4 Clay Fouts <cfouts@liblime.com>:
Github makes patch submission very easy. The typical process is to fork the repository, commit your changes to your own fork (often on a topic branch), then submit a pull request to the maintainer of the forked project. The web interface provides simple buttons for forking (e.g. the LK-4.2 fork link is https://github.com/liblime/LibLime-Koha/fork) and issuing pull requests. The maintainer receives notification of the pull request and can then opt to merge the new commits back into the original repository. The service offers a nice interface to the whole code management process and provides additional features for discussing patches, providing line-by-line commentary, basic issue tracking, docs wiki, and so on. They offer public repositories for free, so there's a very low barrier to entry for open source developers.
Internally we have released LK-4.4 and 4.6 into production and are now working on development branch 4.7. These are not publicly accessible, and that makes development of larger features pretty tricky if you're working on the 4.2 release as your base. Anyone interested in creating a more involved feature and ensuring it can be easily ported to future releases should consult us for pointers as there are notable architectural and schema differences.
Right, perhaps we should move this off the Koha lists, Liblime run their own lists for their project. This discussion about how to contribute to the Liblime project is better there. Its fairly clear from Clays message, and comments on my blog etc that what Liblime is developing is not Koha, and has diverged significantly. So I say lets just keep discussion about Koha here, and unless the discussion turns to how to reconcile the fork with the Koha project, leave discussion of Liblime's Project for their own lists. We don't discuss Koha on the Evergreen lists, and OPALS don't discuss their project on the Koha lists. Liblime have their own project with their own lists, lets leave them to it and get back to focusing on Koha. Chris
On 2011-06-4, at 7:13 PM, Clay Fouts wrote:
Github makes patch submission very easy. The typical process is to fork the repository, commit your changes to your own fork (often on a topic branch), then submit a pull request to the maintainer of the forked project. The web interface provides simple buttons for forking (e.g. the LK-4.2 fork link is https://github.com/liblime/LibLime-Koha/fork) and issuing pull requests. The maintainer receives notification of the pull request and can then opt to merge the new commits back into the original repository.
The service offers a nice interface to the whole code management process and provides additional features for discussing patches, providing line-by-line commentary, basic issue tracking, docs wiki, and so on. They offer public repositories for free, so there's a very low barrier to entry for open source developers.
Internally we have released LK-4.4 and 4.6 into production and are now working on development branch 4.7. These are not publicly accessible, and that makes development of larger features pretty tricky if you're working on the 4.2 release as your base. Anyone interested in creating a more involved feature and ensuring it can be easily ported to future releases should consult us for pointers as there are notable architectural and schema differences.
Regards, Clay
thanks for that Clay, thats great info so, do PTFS/Liblime have any plans to submit their client-funded features/enhancements back into the Koha codebase... or not? Mason
We do not in general make an effort to coordinate our work with other code bases, nor attempt to port our code over to them. The source is however available for all to see. Upon release from the sponsoring customer, we publish the source code for anyone to work whichever pieces they want into whatever code base they manage. Clay On Sun, Jun 5, 2011 at 7:00 PM, James, Mason <mason@kohaaloha.com> wrote:
On 2011-06-4, at 7:13 PM, Clay Fouts wrote:
Github makes patch submission very easy. The typical process is to fork the repository, commit your changes to your own fork (often on a topic branch), then submit a pull request to the maintainer of the forked project. The web interface provides simple buttons for forking (e.g. the LK-4.2 fork link is https://github.com/liblime/LibLime-Koha/fork) and issuing pull requests. The maintainer receives notification of the pull request and can then opt to merge the new commits back into the original repository.
The service offers a nice interface to the whole code management process and provides additional features for discussing patches, providing line-by-line commentary, basic issue tracking, docs wiki, and so on. They offer public repositories for free, so there's a very low barrier to entry for open source developers.
Internally we have released LK-4.4 and 4.6 into production and are now working on development branch 4.7. These are not publicly accessible, and that makes development of larger features pretty tricky if you're working on the 4.2 release as your base. Anyone interested in creating a more involved feature and ensuring it can be easily ported to future releases should consult us for pointers as there are notable architectural and schema differences.
Regards, Clay
thanks for that Clay, thats great info
so, do PTFS/Liblime have any plans to submit their client-funded features/enhancements back into the Koha codebase... or not?
Mason
2011/6/6 Clay Fouts <cfouts@liblime.com>:
We do not in general make an effort to coordinate our work with other code bases, nor attempt to port our code over to them. The source is however available for all to see. Upon release from the sponsoring customer, we publish the source code for anyone to work whichever pieces they want into whatever code base they manage.
Cutting to the chase, your wordy explanation can be reduced to a one word policy: Non-cooperation. Wording it that way wastes less of our time on parsing the verbiage. Liblime's product is simply *NOT* Koha. Period. End of discussion. And I'm not sure we really want what they have at this point anyway. Now back to more productive work. Kind Regards, Chris
Each vendor has their own (sometimes very large) customizations that they may or may not port back into community code. The community RM may or may not accept these back ports even if effort is made to rebase them. Please point to the line distinguishing "Koha" from "not Koha". Is BibLibre's fork Koha? They have substantial, potentially irreconcilable differences that appear not to be destined for the community base and their extremely patient efforts to point this out and seek solution are met with little more than a dismissive that "well, that's your problem." Who is or isn't cooperating this case? Is Software Coop's fork Koha? I understand there are large differences that they are not paying to port back into the community base. I even recall seeing an announcement that someone was paying ByWater to do the work of porting the coop's EDI code back to community. Does this qualify as "cooperation"? How is this different from LibLime publishing its code so that any library is welcome to pay the vendor of their choosing to back port it to community? Would we receive the same praiseful press release if ByWater was getting paid to port our large-bib functionality into community code? The community had their opportunity to fork their project from the company that owns the trademark, website, etc. and call their software something different, much like LibreOffice and Jenkins chose to do when splitting from the Oracle-run projects. But that wasn't the choice that was made, so now we all get to have endless arguments and have libraries confused about what is or is not Koha. At the very least, LibLime when asked tries to be respectful of our differences and does not say "well, that's not really Koha." Regards, Clay On Mon, Jun 6, 2011 at 8:17 AM, Chris Nighswonger < cnighswonger@foundations.edu> wrote:
2011/6/6 Clay Fouts <cfouts@liblime.com>:
We do not in general make an effort to coordinate our work with other code bases, nor attempt to port our code over to them. The source is however available for all to see. Upon release from the sponsoring customer, we publish the source code for anyone to work whichever pieces they want into whatever code base they manage.
Cutting to the chase, your wordy explanation can be reduced to a one word policy: Non-cooperation.
Wording it that way wastes less of our time on parsing the verbiage.
Liblime's product is simply *NOT* Koha. Period. End of discussion. And I'm not sure we really want what they have at this point anyway.
Now back to more productive work.
Kind Regards, Chris
Clay - Please get your facts straight before you continue with this thread and us other companies names. Comment in-line. On Jun 6, 2011, at 9:05 AM, Clay Fouts wrote:
Each vendor has their own (sometimes very large) customizations that they may or may not port back into community code. The community RM may or may not accept these back ports even if effort is made to rebase them. Please point to the line distinguishing "Koha" from "not Koha".
Is BibLibre's fork Koha? They have substantial, potentially irreconcilable differences that appear not to be destined for the community base and their extremely patient efforts to point this out and seek solution are met with little more than a dismissive that "well, that's your problem." Who is or isn't cooperating this case?
Is Software Coop's fork Koha? I understand there are large differences that they are not paying to port back into the community base. I even recall seeing an announcement that someone was paying ByWater to do the work of porting the coop's EDI code back to community. Does this qualify as "cooperation"? How is this different from LibLime publishing its code so that any library is welcome to pay the vendor of their choosing to back port it to community? Would we receive the same praiseful press release if ByWater was getting paid to port our large-bib functionality into community code?
Software Coop is not paying ByWater Solutions to rebase EDI for Koha. This is a project that we are pursuing and we are using our own money to fund for our time to rebase this code. As part of our company we spend the time to rebase code/ submit bugfixes, and pay for our employees to work on community code and documentation (manual) that is not directly sponsored by a customer. This is all meant for the best interests in the project as a whole. Hopefully that makes sense - if not, you are welcome to give me a phone call whenever you want. -Brendan ByWater Solutions CEO
The community had their opportunity to fork their project from the company that owns the trademark, website, etc. and call their software something different, much like LibreOffice and Jenkins chose to do when splitting from the Oracle-run projects. But that wasn't the choice that was made, so now we all get to have endless arguments and have libraries confused about what is or is not Koha.
At the very least, LibLime when asked tries to be respectful of our differences and does not say "well, that's not really Koha."
Regards, Clay
On Mon, Jun 6, 2011 at 8:17 AM, Chris Nighswonger <cnighswonger@foundations.edu> wrote: 2011/6/6 Clay Fouts <cfouts@liblime.com>:
We do not in general make an effort to coordinate our work with other code bases, nor attempt to port our code over to them. The source is however available for all to see. Upon release from the sponsoring customer, we publish the source code for anyone to work whichever pieces they want into whatever code base they manage.
Cutting to the chase, your wordy explanation can be reduced to a one word policy: Non-cooperation.
Wording it that way wastes less of our time on parsing the verbiage.
Liblime's product is simply *NOT* Koha. Period. End of discussion. And I'm not sure we really want what they have at this point anyway.
Now back to more productive work.
Kind Regards, Chris
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
I did not say that Software Coop was paying for it. My whole point was that they were *not* paying for it. I stated that someone was paying ByWater to port it, and I now understand that that someone is ByWater itself, not a customer. I stand corrected on that point. Clay On Mon, Jun 6, 2011 at 9:50 AM, Brendan A. Gallagher < info@bywatersolutions.com> wrote:
Clay -
Please get your facts straight before you continue with this thread and us other companies names. Comment in-line.
On Jun 6, 2011, at 9:05 AM, Clay Fouts wrote:
Each vendor has their own (sometimes very large) customizations that they may or may not port back into community code. The community RM may or may not accept these back ports even if effort is made to rebase them. Please point to the line distinguishing "Koha" from "not Koha".
Is BibLibre's fork Koha? They have substantial, potentially irreconcilable differences that appear not to be destined for the community base and their extremely patient efforts to point this out and seek solution are met with little more than a dismissive that "well, that's your problem." Who is or isn't cooperating this case?
Is Software Coop's fork Koha? I understand there are large differences that they are not paying to port back into the community base. I even recall seeing an announcement that someone was paying ByWater to do the work of porting the coop's EDI code back to community. Does this qualify as "cooperation"? How is this different from LibLime publishing its code so that any library is welcome to pay the vendor of their choosing to back port it to community? Would we receive the same praiseful press release if ByWater was getting paid to port our large-bib functionality into community code?
Software Coop is not paying ByWater Solutions to rebase EDI for Koha. This is a project that we are pursuing and we are using our own money to fund for our time to rebase this code. As part of our company we spend the time to rebase code/ submit bugfixes, and pay for our employees to work on community code and documentation (manual) that is not directly sponsored by a customer. This is all meant for the best interests in the project as a whole.
Hopefully that makes sense - if not, you are welcome to give me a phone call whenever you want.
-Brendan ByWater Solutions CEO
The community had their opportunity to fork their project from the company that owns the trademark, website, etc. and call their software something different, much like LibreOffice and Jenkins chose to do when splitting from the Oracle-run projects. But that wasn't the choice that was made, so now we all get to have endless arguments and have libraries confused about what is or is not Koha.
At the very least, LibLime when asked tries to be respectful of our differences and does not say "well, that's not really Koha."
Regards, Clay
On Mon, Jun 6, 2011 at 8:17 AM, Chris Nighswonger < cnighswonger@foundations.edu> wrote:
2011/6/6 Clay Fouts <cfouts@liblime.com>:
We do not in general make an effort to coordinate our work with other code bases, nor attempt to port our code over to them. The source is however available for all to see. Upon release from the sponsoring customer, we publish the source code for anyone to work whichever pieces they want into whatever code base they manage.
Cutting to the chase, your wordy explanation can be reduced to a one word policy: Non-cooperation.
Wording it that way wastes less of our time on parsing the verbiage.
Liblime's product is simply *NOT* Koha. Period. End of discussion. And I'm not sure we really want what they have at this point anyway.
Now back to more productive work.
Kind Regards, Chris
_______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Brendan A. Gallagher wrote:
Please get your facts straight before you continue with this thread and us other companies names. Comment in-line.
Yes, I agree with that sentiment. Liblime workers appearing to actively fib about other community participants is a new step back.
On Jun 6, 2011, at 9:05 AM, Clay Fouts wrote:
Is Software Coop's fork Koha?
No, and we don't market it as such. (It's software.coop, by the way.) All but one of our libraries are on Koha releases available from koha-community.org and all patches we create are sent back, but those have been fairly small and sporadic since then. The release management seems much better in 3.2 and 3.4. For anyone new to this topic, that fork is a single-library variant of Koha which I feel Liblime forced us into a few years ago. The 3.0 release manager (Josh, then owner of Liblime) refused to hold back from adopting a feature in one of the template modules that: 1. was not portable; 2. Liblime had requested; 3. was not packaged for mainstream operating systems yet; and 4. did not compile on that library's servers at that time. Remember that Josh had announced Koha 3.0 would be released at the end of 2006, then in July 2008, he presented us with the prospect that a library which had patiently helped us to develop 3.0 wouldn't be able to use it when it was released! The co-op's core mission is "to provide computer-related services" so we did what we had to do to serve that library. The main bit of the thread provoking the fork starts at http://lists.koha-community.org/pipermail/koha-patches/2008-July/007016.html tl;dr where I disclose that we've forked for the one library is http://lists.koha-community.org/pipermail/koha-patches/2008-August/007309.ht...
I understand there are large differences that they are not paying to port back into the community base.
What gave you that idea? The co-op is using our own money to fund porting them back (for various reasons rooted in government cuts IMO, the original project won't complete any time soon), so it's taking far longer than I would like. I shudder to think of the cost that this fork has incurred.
I even recall seeing an announcement that someone was paying ByWater to do the work of porting the coop's EDI code back to community. Does this qualify as "cooperation"?
That EDI code was developed for the same one library which is why it's based on the fork. Bywater have agreed to help us with porting this back sooner and we really appreciate that, but I don't remember any announcement about someone paying them to do it. Please post links, like I did above, so anyone can see for themselves.
How is this different from LibLime publishing its code so that any library is welcome to pay the vendor of their choosing to back port it to community?
Key differences: 1. the fork exists mainly because of Liblime's 3.0 release manager; 2. it's used at one library and we've been quite open about that; 3. we still support the community, on IRC, web, in meetings, and so on; 4. we have never tried to pass the fork off as Koha or booted the community out of resources they developed; 5. despite the massive cost, we will port the key features and not publish a tangled mess as abandonware for the community to sort out; 6. we have shared it with other Koha developers, both at Kohacon10 and otherwise; 7. we normally sell the proper Koha releases.
Software Coop is not paying ByWater Solutions to rebase EDI for Koha. This is a project that we are pursuing and we are using our own money to fund for our time to rebase this code. [...]
Thanks to Bywater, once again.
Hopefully that makes sense - if not, you are welcome to give me a phone call whenever you want.
Similarly, anyone is welcome to call the co-op - we now have local access numbers in over 35 countries, linked on http://www.software.coop/contact/ Hope that clarifies, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. Webmaster, Debian Developer, Past Koha RM, statistician, former lecturer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for various work through http://www.software.coop/
"1. the fork exists mainly because of Liblime's 3.0 release manager;" Back to "Josh made me do it!" chorus... Five months of lead time is not exactly a last minute change. But I suppose that's as good of excuse as any. I stand corrected in regards to you passing off your fork as "Koha". So then why does so little of your work show up in the community repository? Does software.coop just not do much software development? Clay On Tue, Jun 7, 2011 at 5:28 AM, MJ Ray <mjr@phonecoop.coop> wrote:
Brendan A. Gallagher wrote:
Please get your facts straight before you continue with this thread and us other companies names. Comment in-line.
Yes, I agree with that sentiment. Liblime workers appearing to actively fib about other community participants is a new step back.
On Jun 6, 2011, at 9:05 AM, Clay Fouts wrote:
Is Software Coop's fork Koha?
No, and we don't market it as such. (It's software.coop, by the way.)
All but one of our libraries are on Koha releases available from koha-community.org and all patches we create are sent back, but those have been fairly small and sporadic since then. The release management seems much better in 3.2 and 3.4.
For anyone new to this topic, that fork is a single-library variant of Koha which I feel Liblime forced us into a few years ago. The 3.0 release manager (Josh, then owner of Liblime) refused to hold back from adopting a feature in one of the template modules that:
1. was not portable; 2. Liblime had requested; 3. was not packaged for mainstream operating systems yet; and 4. did not compile on that library's servers at that time.
Remember that Josh had announced Koha 3.0 would be released at the end of 2006, then in July 2008, he presented us with the prospect that a library which had patiently helped us to develop 3.0 wouldn't be able to use it when it was released! The co-op's core mission is "to provide computer-related services" so we did what we had to do to serve that library.
The main bit of the thread provoking the fork starts at
http://lists.koha-community.org/pipermail/koha-patches/2008-July/007016.html
tl;dr where I disclose that we've forked for the one library is
http://lists.koha-community.org/pipermail/koha-patches/2008-August/007309.ht...
I understand there are large differences that they are not paying to port back into the community base.
What gave you that idea? The co-op is using our own money to fund porting them back (for various reasons rooted in government cuts IMO, the original project won't complete any time soon), so it's taking far longer than I would like. I shudder to think of the cost that this fork has incurred.
I even recall seeing an announcement that someone was paying ByWater to do the work of porting the coop's EDI code back to community. Does this qualify as "cooperation"?
That EDI code was developed for the same one library which is why it's based on the fork. Bywater have agreed to help us with porting this back sooner and we really appreciate that, but I don't remember any announcement about someone paying them to do it. Please post links, like I did above, so anyone can see for themselves.
How is this different from LibLime publishing its code so that any library is welcome to pay the vendor of their choosing to back port it to community?
Key differences:
1. the fork exists mainly because of Liblime's 3.0 release manager;
2. it's used at one library and we've been quite open about that;
3. we still support the community, on IRC, web, in meetings, and so on;
4. we have never tried to pass the fork off as Koha or booted the community out of resources they developed;
5. despite the massive cost, we will port the key features and not publish a tangled mess as abandonware for the community to sort out;
6. we have shared it with other Koha developers, both at Kohacon10 and otherwise;
7. we normally sell the proper Koha releases.
Software Coop is not paying ByWater Solutions to rebase EDI for Koha. This is a project that we are pursuing and we are using our own money to fund for our time to rebase this code. [...]
Thanks to Bywater, once again.
Hopefully that makes sense - if not, you are welcome to give me a phone call whenever you want.
Similarly, anyone is welcome to call the co-op - we now have local access numbers in over 35 countries, linked on http://www.software.coop/contact/
Hope that clarifies, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. Webmaster, Debian Developer, Past Koha RM, statistician, former lecturer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for various work through http://www.software.coop/ _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Clay Fouts wrote:
"1. the fork exists mainly because of Liblime's 3.0 release manager;"
Back to "Josh made me do it!" chorus...
Yeah, well, truth doesn't change over time. I posted the links for all to read the actual exchange as it happened.
Five months of lead time is not exactly a last minute change. But I suppose that's as good of excuse as any.
It wasn't an simple bug to identify, as the somewhat off-beam suggestions from @liblime in that thread hopefully illustrate. Not an excuse, just an explanation. Interesting that you suggest forks need excusing: I guess PTFS knows the Liblime forks are a fankle.
I stand corrected in regards to you passing off your fork as "Koha". So then why does so little of your work show up in the community repository? Does software.coop just not do much software development?
We're not doing as much Koha development as I'd like just now. We're doing more development on other things, some of which support our Koha deployments (like the git-bz patch I published this week, for example), plus one or two that don't. The bulk of our Koha development is in reconciling that fork, so some day soon there should be a couple of surges and we'll be basically back on track, working on new stuff for the mainline again at last. Other than that, we work on the various websites and give some support on IRC and mailing lists, as well as serve our own libraries. And how about PTFS? Why's it taking so long to reconcile the Limlibe fork? Does PTFS just not do much software development? -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. http://koha-community.org supporter, web and LMS developer, statistician. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for Koha work http://www.software.coop/products/koha
I think it's time for this thread to end. No one is going to convince Clay that PTFS is doing it wrong, and Clay isn't going to convince the rest of us that PTFS isn't. This list is for discussing Koha, and 99% of us know what that means perfectly well. I suggest anyone still interested in this argument should take it off-list, IMO. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
On Mon, Jun 6, 2011 at 12:05 PM, Clay Fouts <cfouts@liblime.com> wrote:
Each vendor has their own (sometimes very large) customizations that they may or may not port back into community code. The community RM may or may not accept these back ports even if effort is made to rebase them. Please point to the line distinguishing "Koha" from "not Koha".
That's easy: the point at which the vendor (whomever they may be) chooses to fork from Koha. At that point, the software the vendor is servicing, maintaining, your-term-goes-here, ceases to be Koha. It may be said to be based upon Koha, but it is not Koha.
Is BibLibre's fork Koha? They have substantial, potentially irreconcilable differences that appear not to be destined for the community base and their extremely patient efforts to point this out and seek solution are met with little more than a dismissive that "well, that's your problem." Who is or isn't cooperating this case? Is Software Coop's fork Koha? I understand there are large differences that they are not paying to port back into the community base. I even recall seeing an announcement that someone was paying ByWater to do the work of porting the coop's EDI code back to community. Does this qualify as "cooperation"? How is this different from LibLime publishing its code so that any library is welcome to pay the vendor of their choosing to back port it to community? Would we receive the same praiseful press release if ByWater was getting paid to port our large-bib functionality into community code?
By definition a fork is not the same as the base from which it was forked. A given instance of code is only a true fork once there is a delta between it and the source from which it was cloned. Otherwise it is a clone rather than a fork. So, by definition any repo, installation, etc. which has a delta over the main repo is a fork. Since we live in a world where there must be some objective standard against which to make accurate comparisons, we must decide on that standard. In the Koha community that standard has long been the code base in the main repo. So every fork is by definition only as nearly "Koha" as it conforms to that standard. Thus, the larger the delta between the fork and the main repo, the less the fork can be said to be "Koha." Its an inverse relationship if that is clearer. At this point in history, LibLime's fork has a pretty large delta and so is less "Koha" than other forks.
The community had their opportunity to fork their project from the company that owns the trademark, website, etc. and call their software something different, much like LibreOffice and Jenkins chose to do when splitting from the Oracle-run projects. But that wasn't the choice that was made, so now we all get to have endless arguments and have libraries confused about what is or is not Koha.
Liblime only owns the US trademark usage of the name "Koha," and last I looked, the US does not dictate world trademark law. Koha is much bigger than LibLime (as much as LibLime might pretend otherwise). So just as you are free to have your opinion, the Koha community has their opinion: There is no confusion to those in the know. The Koha community produces and holds the standard against which all other things calling themselves Koha are judged.
At the very least, LibLime when asked tries to be respectful of our differences and does not say "well, that's not really Koha."
I'd say that LibLime is simply acceding to the facts of reality when they refrain from making such claims. They are certainly not doing the community any favors. Kind Regards, Chris
On Mon, Jun 6, 2011 at 10:48 AM, Chris Nighswonger < cnighswonger@foundations.edu> wrote:
standard. In the Koha community that standard has long been the code
base in the main repo. So every fork is by definition only as nearly
"Koha" as it conforms to that standard. Thus, the larger the delta between the fork and the main repo, the less the fork can be said to be "Koha." Its an inverse relationship if that is clearer. At this point in history, LibLime's fork has a pretty large delta and so is less "Koha" than other forks.
You speak like you haven't looked at the BibLibre diffs. I don't know that they're at any less of a delta than LibLime, and it's only getting larger. They are a very productive group. Where is your indignation when they call their product Koha? Software Coop, who apparently has no ambition to back port their own code, sells "Koha" support. Do you tell people that their software isn't really Koha? These folks are obviously selling work that differs remarkably from "Koha" as you've defined it, and to my knowledge they don't even differentiate it with a "BibLibre Koha" or a "Software Coop" Koha the way that LibLime has chosen to do. You can be chafed at the fact that LibLime took liberties that you don't like with the koha.org website, and I can accept and empathize with that. However, your contention that LibLime's code "isn't Koha" and somehow these other projects are is rather incoherent.
Liblime only owns the US trademark usage of the name "Koha," and last I looked, the US does not dictate world trademark law. Koha is much bigger than LibLime (as much as LibLime might pretend otherwise). So just as you are free to have your opinion, the Koha community has their opinion: There is no confusion to those in the know. The Koha community produces and holds the standard against which all other things calling themselves Koha are judged.
The frequency with which we hear the phrase "New Zealand Koha" at conventions suggests the confusion may be deeper and more widespread than you have led yourself to believe. Regards, Clay
On 2011-06-7, at 6:19 AM, Clay Fouts wrote:
On Mon, Jun 6, 2011 at 10:48 AM, Chris Nighswonger <cnighswonger@foundations.edu> wrote: standard. In the Koha community that standard has long been the code base in the main repo. So every fork is by definition only as nearly "Koha" as it conforms to that standard. Thus, the larger the delta between the fork and the main repo, the less the fork can be said to be "Koha." Its an inverse relationship if that is clearer. At this point in history, LibLime's fork has a pretty large delta and so is less "Koha" than other forks.
You speak like you haven't looked at the BibLibre diffs. I don't know that they're at any less of a delta than LibLime, and it's only getting larger. They are a very productive group. Where is your indignation when they call their product Koha? Software Coop, who apparently has no ambition to back port their own code, sells "Koha" support. Do you tell people that their software isn't really Koha?
These folks are obviously selling work that differs remarkably from "Koha" as you've defined it, and to my knowledge they don't even differentiate it with a "BibLibre Koha" or a "Software Coop" Koha the way that LibLime has chosen to do.
the big difference is that Biblibre, software-coop, (and all other Koha support companies) do *not* make their own Koha releases, unlike PTFS/Liblime BL and SW-COOP understand that having many company-releases of many Koha-forks is harmful to the reputation of the Koha project, so they respectfully choose not to do that... (a subtle point that only PTFS/Liblime fail to understand) ... instead they continue to invest their energy submitting their enhancements and bug-fixes into the Koha codebase PTFS/Liblime is the *only* company that continues to release its own 'Koha', and the only company to renege on it commitment to integrate its enhancements back to the Koha codebase PTFS/Liblime seem to have missed the fundamental point of participating in the Koha project.
The frequency with which we hear the phrase "New Zealand Koha" at conventions suggests the confusion may be deeper and more widespread than you have led yourself to believe.
Clay, i think that confusion exists only around conversations with PTFS/Liblime staff, at those conventions ;) Mason
On Mon, Jun 6, 2011 at 5:19 PM, James, Mason <mason@kohaaloha.com> wrote:
the big difference is that Biblibre, software-coop, (and all other Koha support companies) do *not* make their own Koha releases, unlike PTFS/Liblime
BL and SW-COOP understand that having many company-releases of many Koha-forks is harmful to the reputation of the Koha project, so they respectfully choose not to do that... (a subtle point that only PTFS/Liblime fail to understand)
There are a large number of successful open source software projects that defy this supposition. Forks are a vital part of the open source ecosystem that provide competitive feedback into the software development process. PTFS/Liblime is the *only* company that continues to release its own 'Koha',
and the only company to renege on it commitment to integrate its enhancements back to the Koha codebase
PTFS/Liblime seem to have missed the fundamental point of participating in the Koha project.
I think it's fair to say there's disagreement on what the fundamental point of participating in the Koha project is. Regards, Clay
On Mon, Jun 6, 2011 at 2:19 PM, Clay Fouts <cfouts@liblime.com> wrote:
On Mon, Jun 6, 2011 at 10:48 AM, Chris Nighswonger <cnighswonger@foundations.edu> wrote:
standard. In the Koha community that standard has long been the code
base in the main repo. So every fork is by definition only as nearly "Koha" as it conforms to that standard. Thus, the larger the delta between the fork and the main repo, the less the fork can be said to be "Koha." Its an inverse relationship if that is clearer. At this point in history, LibLime's fork has a pretty large delta and so is less "Koha" than other forks.
You speak like you haven't looked at the BibLibre diffs. I don't know that they're at any less of a delta than LibLime, and it's only getting larger.
Rather the contrary, I am familiar with the size of the delta between BL's repo and the main repo. However, (as others have ably pointed out to you) that delta is rapidly shrinking to BL's credit. and it appears from the remainder of your statement that it is you who have not taken time to accurately access those diffs.
They are a very productive group. Where is your indignation when they call their product Koha? Software Coop, who apparently has no ambition to back port their own code, sells "Koha" support. Do you tell people that their software isn't really Koha? These folks are obviously selling work that differs remarkably from "Koha" as you've defined it, and to my knowledge they don't even differentiate it with a "BibLibre Koha" or a "Software Coop" Koha the way that LibLime has chosen to do.
Again, as others have pointed out, no one apart from LL/PTFS attempts to "release" some "other" product which they call Koha and at a minimum imply is an "official" release, trying to best the true Koha by advancing a major version number in that "other" product.
You can be chafed at the fact that LibLime took liberties that you don't like with the koha.org website, and I can accept and empathize with that. However, your contention that LibLime's code "isn't Koha" and somehow these other projects are is rather incoherent.
It appears that others on the list had no problem understanding my train of thought. Perhaps the problem here is not so much with my contention being incoherent as with your corporate enforced presupposition preventing your own coherent understanding of my contention. <snip>
The frequency with which we hear the phrase "New Zealand Koha" at conventions suggests the confusion may be deeper and more widespread than you have led yourself to believe.
Since I've never heard anyone refer to "New Zealand Koha," I would have to say that you must move in a very limited circle at these conventions. In practice, what is said at conventions usually ends up on a list or blog somewhere, so I must beg to be pointed to a source to support the assertion that this title is applied at all, much less with "frequency." And finally, at least I can speak what I believe without fear of losing my job. I think that not many have that privilege, and so their judgment tends to be clouded by pecuniary interests of some sort or at a minimum they speak with a conflict of interest. If that steps on some toes, so be it, but I believe it places those who occupy such ground at the unique advantage of a rather more objective view of the facts. If you disagree, that's certainly ok. Many a pilot has run his plane into the ground because he would not yield to the more objective view of the controller in the tower. I suppose we'll just have to sit it out and see who's plane ends up nose first in the ground won't we? Kind Regards, Chris
Le 06/06/2011 18:05, Clay Fouts a écrit : > Each vendor has their own (sometimes very large) customizations that > they may or may not port back into community code. The community RM > may or may not accept these back ports even if effort is made to > rebase them. Please point to the line distinguishing "Koha" from "not > Koha". Well, I think we are mixing 2 things : * local & specific customizations * fork a local and specific customization: it occur very often. For example, one of our customer has very long barcodes, and the barcode length in the database is not enough for them. it's specific to the customer, and has nothing to do with a public version. Sometimes, it's not that small (even if it's local). For example, for Aix-Marseille universities, we changed the circulation (check-out) workflow to query a NFC reader& database. The NFC card & database is responsible to say if a card is valid and fill the members table in Koha database. This is OpenSource (GPL), available on our public git repo, but won't be submitted to the community, it's useless unless you've this exact technology. I agree it can be worth for a library using the same NFC technology and we could have announced what we made more widely. Our fault, nobody's perfect (announcement : if you've a 'horoquartz' NFC technology, you can drop me a mail ;-) ) a fork. Do we have a fork ? Frankly, yes, but 1- we didn't wanted this to happen, 2- we do all what we can to fix this (yes we consider it's a "bug"). Reminder about the history : Koha 3.2 has been delayed due to events we all know here (for newbies, see : http://lists.katipo.co.nz/pipermail/koha/2011-February/027657.html), thus many feature we have developed have needed too much time to reach master (and had to be splitted/merged/...) I'm on my way to write a mail on our blog to detail how it happens, why we consider it a bug (and want to fix it), and what's the strategy to avoid it to happen again. In a few word: * we deploy only community version * if you sponsor a feature 2 options : you sponsor and use it live when it's in master, you sponsor, go live immediately. BUT if it's not included in master, then you'll have either to choose to switch back to community version (and forget you stuff), wait until it's in master, sign a specific contract for support from BibLibre (or someone else) to have your nice-feature-not-in-master rebased regularly vs master. * there are only a few things in "3.2 biblibre" that are not in 3.4, and everything will be in 3.6. > Is BibLibre's fork Koha? They have substantial, potentially > irreconcilable differences that appear not to be destined for the > community base and their extremely patient efforts to point this out > and seek solution are met with little more than a dismissive that > "well, that's your problem." Who is or isn't cooperating this case? Well, you're not completely wrong. I'm sometimes quite upset by "community". And I'm sure "community" is sometimes upset by me too ;-) . But I still think it's better to have strong discussions and arguments than doing our way without "the community". Hope that explains -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
Hello, Paul. What you describe here is an insightful analysis followed up with a perfectly valid decision that embodies that priorities you've set for your business in order to benefit your customers. There is a value in seeking to keep in sync with the git.koha-community.org repo, and there is value in diverging from it. It's a matter of personal and business priorities which path to take, and I respect everyone to make that decision for themselves. Cheers, Clay On Tue, Jun 7, 2011 at 6:38 AM, Paul Poulain <paul.poulain@biblibre.com>wrote: > Le 06/06/2011 18:05, Clay Fouts a écrit : > > Each vendor has their own (sometimes very large) customizations that > > they may or may not port back into community code. The community RM > > may or may not accept these back ports even if effort is made to > > rebase them. Please point to the line distinguishing "Koha" from "not > > Koha". > Well, I think we are mixing 2 things : > * local & specific customizations > * fork > > a local and specific customization: it occur very often. For example, > one of our customer has very long barcodes, and the barcode length in > the database is not enough for them. it's specific to the customer, and > has nothing to do with a public version. Sometimes, it's not that small > (even if it's local). For example, for Aix-Marseille universities, we > changed the circulation (check-out) workflow to query a NFC reader& > database. The NFC card & database is responsible to say if a card is > valid and fill the members table in Koha database. This is OpenSource > (GPL), available on our public git repo, but won't be submitted to the > community, it's useless unless you've this exact technology. I agree it > can be worth for a library using the same NFC technology and we could > have announced what we made more widely. Our fault, nobody's perfect > (announcement : if you've a 'horoquartz' NFC technology, you can drop me > a mail ;-) ) > > a fork. Do we have a fork ? Frankly, yes, but 1- we didn't wanted this > to happen, 2- we do all what we can to fix this (yes we consider it's a > "bug"). Reminder about the history : Koha 3.2 has been delayed due to > events we all know here (for newbies, see : > http://lists.katipo.co.nz/pipermail/koha/2011-February/027657.html), > thus many feature we have developed have needed too much time to reach > master (and had to be splitted/merged/...) > > I'm on my way to write a mail on our blog to detail how it happens, why > we consider it a bug (and want to fix it), and what's the strategy to > avoid it to happen again. > In a few word: > * we deploy only community version > * if you sponsor a feature 2 options : you sponsor and use it live when > it's in master, you sponsor, go live immediately. BUT if it's not > included in master, then you'll have either to choose to switch back to > community version (and forget you stuff), wait until it's in master, > sign a specific contract for support from BibLibre (or someone else) to > have your nice-feature-not-in-master rebased regularly vs master. > * there are only a few things in "3.2 biblibre" that are not in 3.4, and > everything will be in 3.6. > > > Is BibLibre's fork Koha? They have substantial, potentially > > irreconcilable differences that appear not to be destined for the > > community base and their extremely patient efforts to point this out > > and seek solution are met with little more than a dismissive that > > "well, that's your problem." Who is or isn't cooperating this case? > Well, you're not completely wrong. I'm sometimes quite upset by > "community". And I'm sure "community" is sometimes upset by me too ;-) . > But I still think it's better to have strong discussions and arguments > than doing our way without "the community". > > Hope that explains > > -- > Paul POULAIN > http://www.biblibre.com > Expert en Logiciels Libres pour l'info-doc > Tel : (33) 4 91 81 35 08 > > _______________________________________________ > Koha-devel mailing list > Koha-devel@lists.koha-community.org > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > website : http://www.koha-community.org/ > git : http://git.koha-community.org/ > bugs : http://bugs.koha-community.org/ >
Estimates This is a topic which I fully understand what is happening with the versions, and what I personally favor is changing URL and the business sense behind that there Koha, Koha we adopt in our University and thanks to community and (http://koha-community.org/) achieves important objectives. I do not think there is another alternative as this community that we are the programmers who love freedom. Never fails KOHA (http://koha-community.org/) from Bolivia. Thanks. Christian Jhonny Calle Jahuira TUTOR ELEARNING - UMSA Consultor Sistemas de Informacion de Bibliotecas de la UMSA Email: ccalle@umsa.bo Cel: 73017301 On Tue, 7 Jun 2011 13:34:25 -0700, Clay Fouts <cfouts@liblime.com> wrote: > Hello, Paul. > > What you describe here is an insightful analysis followed up with a > perfectly valid decision that embodies that priorities you've set for > your business in order to benefit your customers. There is a value in > seeking to keep in sync with the git.koha-community.org [1] repo, and > there is value in diverging from it. It's a matter of personal and > business priorities which path to take, and I respect everyone to make > that decision for themselves. > > Cheers, > Clay > > On Tue, Jun 7, 2011 at 6:38 AM, Paul Poulain wrote: > Le 06/06/2011 18:05, Clay Fouts a écrit : > >> Each vendor has their own (sometimes very large) customizations > that > > they may or may not port back into community code. The community > RM > > may or may not accept these back ports even if effort is made to > > rebase them. Please point to the line distinguishing "Koha" from > "not > > Koha". > Well, I think we are mixing 2 things : > * local & specific customizations > * fork > > a local and specific customization: it occur very often. For > example, > one of our customer has very long barcodes, and the barcode length > in > the database is not enough for them. it's specific to the customer, > and > has nothing to do with a public version. Sometimes, it's not that > small > (even if it's local). For example, for Aix-Marseille universities, > we > changed the circulation (check-out) workflow to query a NFC reader& > database. The NFC card & database is responsible to say if a card is > valid and fill the members table in Koha database. This is > OpenSource > (GPL), available on our public git repo, but won't be submitted to > the > community, it's useless unless you've this exact technology. I agree > it > can be worth for a library using the same NFC technology and we > could > have announced what we made more widely. Our fault, nobody's perfect > (announcement : if you've a 'horoquartz' NFC technology, you can > drop me > a mail ;-) ) > > a fork. Do we have a fork ? Frankly, yes, but 1- we didn't wanted > this > to happen, 2- we do all what we can to fix this (yes we consider > it's a > "bug"). Reminder about the history : Koha 3.2 has been delayed due > to > events we all know here (for newbies, see : > http://lists.katipo.co.nz/pipermail/koha/2011-February/027657.html > [3]), > thus many feature we have developed have needed too much time to > reach > master (and had to be splitted/merged/...) > > I'm on my way to write a mail on our blog to detail how it happens, > why > we consider it a bug (and want to fix it), and what's the strategy > to > avoid it to happen again. > In a few word: > * we deploy only community version > * if you sponsor a feature 2 options : you sponsor and use it live > when > it's in master, you sponsor, go live immediately. BUT if it's not > included in master, then you'll have either to choose to switch back > to > community version (and forget you stuff), wait until it's in master, > sign a specific contract for support from BibLibre (or someone else) > to > have your nice-feature-not-in-master rebased regularly vs master. > * there are only a few things in "3.2 biblibre" that are not in 3.4, > and > everything will be in 3.6. > > > Is BibLibre's fork Koha? They have substantial, potentially > > irreconcilable differences that appear not to be destined for the > > community base and their extremely patient efforts to point this > out > > and seek solution are met with little more than a dismissive that > > "well, that's your problem." Who is or isn't cooperating this > case? > Well, you're not completely wrong. I'm sometimes quite upset by > "community". And I'm sure "community" is sometimes upset by me too > ;-) . > But I still think it's better to have strong discussions and > arguments > than doing our way without "the community". > > Hope that explains > > -- > Paul POULAIN > http://www.biblibre.com [4] > Expert en Logiciels Libres pour l'info-doc > Tel : (33) 4 91 81 35 08 > > _______________________________________________ > Koha-devel mailing list > Koha-devel@lists.koha-community.org [5] > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > [6] > website : http://www.koha-community.org/ [7] > git : http://git.koha-community.org/ [8] > bugs : http://bugs.koha-community.org/ [9] > > > > Links: > ------ > [1] http://git.koha-community.org > [2] mailto:paul.poulain@biblibre.com > [3] > http://lists.katipo.co.nz/pipermail/koha/2011-February/027657.html > [4] http://www.biblibre.com > [5] mailto:Koha-devel@lists.koha-community.org > [6] > http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel > [7] http://www.koha-community.org/ > [8] http://git.koha-community.org/ > [9] http://bugs.koha-community.org/ -- Atte -- Christian Jhonny Calle Jahuira TUTOR ELEARNING - UMSA Consultor Sistemas de Informacion de Bibliotecas de la UMSA Email: ccalle@umsa.bo Cel: 73017301
Christian Calle Jahuira wrote:
Write to La Paz Bolivia, I have implemented KOHA version 3.0, my question is about the advantages of KOHA 4 and LibLime, which presents differences.
The latest version is Koha 3.4. There is no Koha 4 yet. LibLime is trying to pass off their LMS as Koha, but it is not Koha. Do not be tricked! Koha would not delete its contibutor credits. As I understand it, LibLime 4.2 is actually a fork around Koha 3.0, which was the last version release-managed by someone from LibLime (oh the pain) and was end-of-lifed by koha-community last month, as in http://lists.koha-community.org/pipermail/koha-devel/2011-May/035542.html Also, I think that the public LibLime 4.2 is not current, with their customers using later versions. So their public version is already obsolete by its publisher and based on a now-unsupported community release, so why would anyone use it unless forced or daft? This seems like a repeat of the trick when LibLime started selling "Enterprise Koha" - and where is that now? ;-) Koha 3.4 is clearly the place to be. The big feature there is the improved template system, but since 3.0, the acquisitions module is significantly revamped, the system preferences editor is easier to use, there's bulk item editing, better reports, serials and cataloguing, more connections to other systems, more localisaton, tons of small bugs fixed and more that you can find in the release notes. Hope that informs, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. Webmaster, Debian Developer, Past Koha RM, statistician, former lecturer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for various work through http://www.software.coop/
Juste for information : The demo form LibLime website provides the revision number in "About" module : * Koha version: 3.01.00.039 with LibLime Enterprise Koha build: 4.0600001* On Mon, Jun 6, 2011 at 11:17 AM, MJ Ray <mjr@phonecoop.coop> wrote:
Christian Calle Jahuira wrote:
Write to La Paz Bolivia, I have implemented KOHA version 3.0, my question is about the advantages of KOHA 4 and LibLime, which presents differences.
The latest version is Koha 3.4. There is no Koha 4 yet. LibLime is trying to pass off their LMS as Koha, but it is not Koha. Do not be tricked! Koha would not delete its contibutor credits.
As I understand it, LibLime 4.2 is actually a fork around Koha 3.0, which was the last version release-managed by someone from LibLime (oh the pain) and was end-of-lifed by koha-community last month, as in http://lists.koha-community.org/pipermail/koha-devel/2011-May/035542.html
Also, I think that the public LibLime 4.2 is not current, with their customers using later versions. So their public version is already obsolete by its publisher and based on a now-unsupported community release, so why would anyone use it unless forced or daft?
This seems like a repeat of the trick when LibLime started selling "Enterprise Koha" - and where is that now? ;-)
Koha 3.4 is clearly the place to be. The big feature there is the improved template system, but since 3.0, the acquisitions module is significantly revamped, the system preferences editor is easier to use, there's bulk item editing, better reports, serials and cataloguing, more connections to other systems, more localisaton, tons of small bugs fixed and more that you can find in the release notes.
Hope that informs, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. Webmaster, Debian Developer, Past Koha RM, statistician, former lecturer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for various work through http://www.software.coop/ _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
-- Fridolyn SOMERS ICT engineer PROGILONE - Lyon - France fridolyn.somers@gmail.com
Why would anyone use it? I've given a link to the current release notes that document the features that are unique to our fork. There are release notes for previous version, as well. We don't develop features for the fun of it (usually); we develop features that libraries want and that don't yet exist. Just as a brief example, many libraries have records that hundreds or even a thousand items. Koha 3.4 can't handle those. LibLime Koha 4.2 can. LibLime Academic Koha (née LibLime Enterprise Koha) is still very actively developed and updated with regular time-based releases that offer new features like improved search syntax, browse searching, and real authority control. I'm not sure exactly what you're alluding to by citing it, but it continues to grow in both feature set and user base. Clay On Mon, Jun 6, 2011 at 2:17 AM, MJ Ray <mjr@phonecoop.coop> wrote:
Christian Calle Jahuira wrote:
Write to La Paz Bolivia, I have implemented KOHA version 3.0, my question is about the advantages of KOHA 4 and LibLime, which presents differences.
The latest version is Koha 3.4. There is no Koha 4 yet. LibLime is trying to pass off their LMS as Koha, but it is not Koha. Do not be tricked! Koha would not delete its contibutor credits.
As I understand it, LibLime 4.2 is actually a fork around Koha 3.0, which was the last version release-managed by someone from LibLime (oh the pain) and was end-of-lifed by koha-community last month, as in http://lists.koha-community.org/pipermail/koha-devel/2011-May/035542.html
Also, I think that the public LibLime 4.2 is not current, with their customers using later versions. So their public version is already obsolete by its publisher and based on a now-unsupported community release, so why would anyone use it unless forced or daft?
This seems like a repeat of the trick when LibLime started selling "Enterprise Koha" - and where is that now? ;-)
Koha 3.4 is clearly the place to be. The big feature there is the improved template system, but since 3.0, the acquisitions module is significantly revamped, the system preferences editor is easier to use, there's bulk item editing, better reports, serials and cataloguing, more connections to other systems, more localisaton, tons of small bugs fixed and more that you can find in the release notes.
Hope that informs, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. Webmaster, Debian Developer, Past Koha RM, statistician, former lecturer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for various work through http://www.software.coop/ _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
Clay Fouts wrote:
Why would anyone use it? I've given a link to the current release notes that document the features that are unique to our fork. There are release notes for previous version, as well. We don't develop features for the fun of it (usually); we develop features that libraries want and that don't yet exist.
That's not a reason in favour of Liblime 4.2. Most Koha developers develop features that libraries request - and then submit them promptly to the community, unlike Liblime. A couple of firms even develop features to provide a service to libraries as our basic missions, rather than to provide a profit to external investors in a company that bought a business that bought a business.
Just as a brief example, many libraries have records that hundreds or even a thousand items. Koha 3.4 can't handle those. LibLime [...] 4.2 can.
Actually, you're mistaken: Koha 3.4 can handle those. The underlying structural bug released by the 3.0 release manager (from Liblime) has been fixed in 3.4. There are some consequences, but there are other capacity-improvement patches and branches to cure them linked from the wiki if anyone wants them before they are included in a future Koha release. So that isn't a reason for a library to be cut off from the global community by using the already-obsolete Liblime 4.2. Hope that informs, -- MJ Ray (slef), member of www.software.coop, a for-more-than-profit co-op. Webmaster, Debian Developer, Past Koha RM, statistician, former lecturer. In My Opinion Only: see http://mjr.towers.org.uk/email.html Available for hire for various work through http://www.software.coop/
On Tue, Jun 7, 2011 at 4:26 AM, MJ Ray <mjr@phonecoop.coop> wrote:
That's not a reason in favour of Liblime 4.2. Most Koha developers develop features that libraries request - and then submit them promptly to the community, unlike Liblime.
This is particularly dense, MJ. The features present in LK4.2 are already paid for. A library using it would not have to pay LibLime or anyone else in order to be able to take advantage of them.
A couple of firms even develop features to provide a service to libraries as our basic missions, rather than to provide a profit to external investors in a company that bought a business that bought a business.
... and now the sermon. And who *sold* that original business?
Actually, you're mistaken: Koha 3.4 can handle those.
Glad to be mistaken, then. It's a feature that a lot of libraries need.
The underlying structural bug released by the 3.0 release manager (from Liblime) has been fixed in 3.4. There are some consequences, but there are other capacity-improvement patches and branches to cure them linked from the wiki if anyone wants them before they are included in a future Koha release.
The resounding chorus in all of your messages seems to be "It's Josh's fault!"
So that isn't a reason for a library to be cut off from the global community by using the already-obsolete Liblime 4.2.
This is FUD, pure and simple. Is community Koha 3.2 "already-obsolete" because it's not the most current version? We've already pushed out two sets of updates since the initial 4.2 release. Regards, Clay
participants (13)
-
Brendan A. Gallagher -
ccalle -
Chris Cormack -
Chris Nighswonger -
Christian Calle Jahuira -
Clay Fouts -
Fridolyn SOMERS -
Ian Walls -
James, Mason -
MJ Ray -
Nicole Engard -
Owen Leonard -
Paul Poulain