Re: [Koha] Koha releases
Owen Leonard <oleonard@myacpl.org> wrote:
I certainly hope PTFS will not release an update to Harley. I would hope their efforts are being put into integrating it into the real Koha instead.
A few days ago, at the Liblime Users Group meeting held at the ALA conference, customers were told that LibLime plans to merge Harley and LEK (Liblime Enterprise Koha) at some point in the future. I don't recall hearing any specific timeline for that. Liblime also displayed a policy document regarding code release of their software. I think they said it was on their website, but I can't find it right now. I just emailed them for a link or copy of it, but for now I'll give you a summary based on my memory of what was shown.. AIR, the policy says that sponsored software featureswill go through a testing cycle with the sponsoring organization, then will be released to other Liblime customers for six months. After that, the code will be released to the larger Koha world. As I understand it, most of the enhancements sponsored by one of the customer groups (the group sponsoring most of LEK features, I think) are currently contractually defined as a single project rather than individual enhancements. So until the full "bundle" of enhancements goes through the full process of testing and deployment to the other LEK customers, no part of it will be released. After the "Phase I" project is finished, which is scheduled for the end of 2010, then those enhancements will be released to other LEK users, so if there is a release of that code, it is unlikely to be prior to the middle or end of 2011. That date assumes that the project finishes on time. I believe the original date for the end of Phase one was summer, 2009, so this schedule may be overly optimistic. Since the "phase I" includes a large number of features, I asked in the meeting how long they thought it would take for those to be integrated into the official community version of Koha. The estimate I was given was four to five years. I must admit I don't really fully understand the process in which sponsored enhancements are integrated into the official Koha software. Is an evaluation done for sponsored features before they are integrated into the software? I would think the programmers involved in each release would want to evaluate them to see whether they in fact are improvements over the either the current software or whether another feature supplied by a different support vendor may accomplish the same functionality in a better way. If such evaluation is done, who does it? We have had at least one instance when we were told that a feature of official Koha would have to be sacrificed in order for a LEK feature to work correctly. I don't know whether that is going to be a common issue, but I assume that within the official Koha project, there is some decision-making protocol for deciding whether a new feature is worth more than the existing feature that it disables or worth integrating at all if there is an existing feature developed elsewhere that adds the same functionality. -- Stacy Pober Information Alchemist Manhattan College Library Riverdale, NY 10471 stacy.pober@manhattan.edu
Hi Stacy On 2 July 2010 19:46, Stacy Pober <stacy.pober@manhattan.edu> wrote:
Owen Leonard <oleonard@myacpl.org> wrote:
I certainly hope PTFS will not release an update to Harley. I would hope their efforts are being put into integrating it into the real Koha instead.
A few days ago, at the Liblime Users Group meeting held at the ALA conference, customers were told that LibLime plans to merge Harley and LEK (Liblime Enterprise Koha) at some point in the future. I don't recall hearing any specific timeline for that.
Liblime also displayed a policy document regarding code release of their software. I think they said it was on their website, but I can't find it right now. I just emailed them for a link or copy of it, but for now I'll give you a summary based on my memory of what was shown.. AIR, the policy says that sponsored software featureswill go through a testing cycle with the sponsoring organization, then will be released to other Liblime customers for six months. After that, the code will be released to the larger Koha world.
As I understand it, most of the enhancements sponsored by one of the customer groups (the group sponsoring most of LEK features, I think) are currently contractually defined as a single project rather than individual enhancements. So until the full "bundle" of enhancements goes through the full process of testing and deployment to the other LEK customers, no part of it will be released. After the "Phase I" project is finished, which is scheduled for the end of 2010, then those enhancements will be released to other LEK users, so if there is a release of that code, it is unlikely to be prior to the middle or end of 2011. That date assumes that the project finishes on time. I believe the original date for the end of Phase one was summer, 2009, so this schedule may be overly optimistic.
Since the "phase I" includes a large number of features, I asked in the meeting how long they thought it would take for those to be integrated into the official community version of Koha. The estimate I was given was four to five years.
I must admit I don't really fully understand the process in which sponsored enhancements are integrated into the official Koha software. Is an evaluation done for sponsored features before they are integrated into the software? I would think the programmers involved in each release would want to evaluate them to see whether they in fact are improvements over the either the current software or whether another feature supplied by a different support vendor may accomplish the same functionality in a better way. If such evaluation is done, who does it?
One quick bit, almost every single bit of Koha has been paid for by some client along the way, there is very little that isn't sponsored, so this isn't some new thing. How it had worked for the 9 year previous to the LEK fork, and how it still works for everyone else is that features or bugfixes are sent as patches when they are ready. And it is the Release Managers job, often in consultation with others to decide whether the patches are accepted and pushed up. Before the work is done, a bug is logged in bugzilla and if it is a feature an RFC (request for comments) document is put up on the wiki for others to comment on. This usually stops duplicated effort. The community elects a release manager after each release, for the 3.4 release, I was elected Release Manager. Colin Campbell from PTFS Europe was elected QA Manager, his job is to check for code quality and whether the code adheres to the coding guidelines. Chris Nighswonger was elected release maintainer, he will be looking after 3.2.x making 3.2.1, 3.2.2 releases etc as they are needed. We then have Calyx,Jesse Weaver and Henri Damien being bug wrangler, keeping an eye on bugzilla closing bugs, making sure patches aren't missed etc. Everything is done in public on mailing lists or publicly logged irc channels and all the developers bar PTFS/Liblime develop publicly also, so even if the patches aren't ready to be sent their public repositories are there for anyone to look at/test. Developments from most vendors are sent as patches as they are completed, this stops the need for spending huge amounts of time integrating code that is based on something that existed 5 years ago instead of something that exists now. Integration is made much easier and less error prone if people keep their repositories up to date with the master branch and don't let patches get out of date. Certainly if no help is forthcoming from the developers who wrote the code when it is finally made public integration is made much harder. The theme we have for the developer conference after Kohacon10 this year is distributed development, and how to maximise the benefits of this for all. I hope PTFS will send some developers, we have developers from France, Norway, Germany, Taiwan, Australia, NZ and the US coming along.
We have had at least one instance when we were told that a feature of official Koha would have to be sacrificed in order for a LEK feature to work correctly. I don't know whether that is going to be a common issue, but I assume that within the official Koha project, there is some decision-making protocol for deciding whether a new feature is worth more than the existing feature that it disables or worth integrating at all if there is an existing feature developed elsewhere that adds the same functionality.
A feature that broke an existing feature would not be accepted, the developers submitting it would be asked to fix it so that it didn't. Chris
Le 02/07/2010 09:46, Stacy Pober a écrit :
AIR, the policy says that sponsored software featureswill go through a testing cycle with the sponsoring organization, then will be released to other Liblime customers for six months. After that, the code will be released to the larger Koha world.
BibLibre devs are fully & always available. I have recently explained on koha-dev mailing list that we face big problems to merge our code into main repo. I can't imagine it will be possible to merge after : time to develop + time to validate by the sponsoring org + 6 months ... (not counting features that will have been developed in // by the community version, just speaking of the technical pain !) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
I think this gets at the crux of the problem that the community has been dealing with for some time. As I understand it, Liblime's customer insisted on development somewhat off the grid so they were sure to get *their* deliverable. So the farther away their development got from the community version (and no one in the community had any way of knowing what was in that other version), the bigger the hurdle has become for integration. One *could* blame the situation on the customer... I hope that after KohaCon, a clear procedure is established that guides developers and people who contract with developers to ensure that development contracts include re-integration of the contracted code into the community version.This "development in the dark" approach has resulted in lots of good enhancements AND new features that are based on very old code making them nearly impossible to integrate into the community version. And there are conflicts between features because the 'has been dumped at the door of the rest of the community to resolve.This in turns slows down everything else. Part of the reason 3.2 has been delayed has to do with this very issue....trying to integrate as much of the Liblime/PTFS code that was based on an older version of Koha. I believe it should be the job of the developer to ensure their code is based on the current version of the product and not leave it to the rest of the community's developers to wrestle with. If it is the job of the developer to do that, they will ensure that this process is written into contracts with customers. Then, when customers insist on developing huge blocks of code (multiple new features), they will know what that means --- a much bigger cost to them because of the gargantuan effort involved in getting their final product back into the community version. The customer must also be made to understand that the "code in the dark and don't share 'til it's all done" approach -- that takes months, if not years -- is not only more expensive (assuming we expect the customer to pay for the ultimate re-integration of the code) but it is likely that they will not get the same product in the end because of the inevitable conflicts. I doubt that the client WANTS to stand alone on their own unique version of Koha. I doubt those conflicting features were so important that they were worth not having access to the rest of the community's contributions? I suspect if the features had been developed as Paul described (in the RFC light of day) they would have resulted in conflicts. In other words, if the process hadn't been in the dark, the client probably could have had their cake and eat it too. Maybe even eating it right now. Lori Ayre On Fri, Jul 2, 2010 at 6:33 AM, Paul Poulain <paul.poulain@biblibre.com>wrote:
Le 02/07/2010 09:46, Stacy Pober a écrit :
AIR, the policy says that sponsored software featureswill go through a testing cycle with the sponsoring organization, then will be released to other Liblime customers for six months. After that, the code will be released to the larger Koha world.
BibLibre devs are fully & always available. I have recently explained on koha-dev mailing list that we face big problems to merge our code into main repo.
I can't imagine it will be possible to merge after : time to develop + time to validate by the sponsoring org + 6 months ... (not counting features that will have been developed in // by the community version, just speaking of the technical pain !)
-- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Le 02/07/2010 16:10, Lori Bowen Ayre a écrit :
In other words, if the process hadn't been in the dark, the client probably could have had their cake and eat it too. Maybe even eating it right now.
That's why I suggested something like 2 months ago, to have "time based releases" and not "feature based releases". As sponsoring libraries want some feature on a given date. So the sponsored company developing can deal easier with the release cycles community / company-sponsoring. chris C. is fully on this line (was it me that suggested that, or he ? not sure... well, he spoke 1st of "frequent releases", I spoke 1st of "release by date". Probably the same idea...) -- Paul POULAIN http://www.biblibre.com Expert en Logiciels Libres pour l'info-doc Tel : (33) 4 91 81 35 08
2010/7/2 Lori Bowen Ayre <lori.ayre@galecia.com>:
I hope that after KohaCon, a clear procedure is established that guides developers and people who contract with developers to ensure that development contracts include re-integration of the contracted code into the community version.
The clear procedure is already there for developers: Developers can choose to code in the open or not. Most have chosen to participate openly. What I think is missing is education for current and potential users of Koha explaining why using a fork of Koha isn't necessarily in their best interests. I think most LEK/Harley users don't even realize that what they're getting *is* a fork and not Koha at all.
Part of the reason 3.2 has been delayed has to do with this very issue....trying to integrate as much of the Liblime/PTFS code that was based on an older version of Koha.
I don't think anyone is letting the "release" of PTFS's Harley slow down the release of 3.2. 3.2 is moving ahead at the pace required for it to be polished without worrying about Harley.
I believe it should be the job of the developer to ensure their code is based on the current version of the product and not leave it to the rest of the community's developers to wrestle with.
I think an ethical developer will keep their work open, and a self-interested customer must demand that their developers do so. The problem comes when companies decide that it is in their own best interest to ignore this process and then convince their customers that they're doing so in the customers' best interests. Maybe it is, maybe it isn't. But the customers need to understand that the product they're getting isn't Koha, and it isn't open source. -- Owen -- Web Developer Athens County Public Libraries http://www.myacpl.org
2010/7/2 Lori Bowen Ayre <lori.ayre@galecia.com>:
contracts with customers. Then, when customers insist on developing huge blocks of code (multiple new features), they will know what that means --- a much bigger cost to them because of the gargantuan effort involved in getting their final product back into the community version.
I agree with what everyone before me has said, the process is in place, it has been in place for years and has worked pretty darn well. What I want us all to agree on here and now is that there is no "community version" - there is Koha. Koha is the official release of the software and it is developed by a community of developers and users worldwide, but it's not the "community version" versus "those other versions" - it's Koha and "not yet Koha" ("not yet" because the code hasn't been integrated into the official product yet). I think this is part of why users/librarians are so confused. They are told there is a "community version" and then a "version from your vendor" implying that one is better than and one is less than. The fact is that it's all software that serves a purpose and I won't debate which is better - I just don't really want to talk about the official version of the software - Koha - as the "community version" anymore. Just my 2 cents. Thanks Nicole C. Engard
Thanks for the clarification Nicole. I would further say that "Harley" is a trunk <http://en.wikipedia.org/wiki/Trunk_%28software%29> not a fork (as was once explained to me by an Evergreen developer). "Harley" is temporary, while Koha is permanent. I don't think my vendor has implied that "Harley" is better. They have said that it has features that are not yet in Koha. I would venture to say that we librarians are struggling with this new terminology but we are trying our best to understand. Vicki On Fri, Jul 2, 2010 at 10:17 AM, Nicole Engard <nengard@gmail.com> wrote:
2010/7/2 Lori Bowen Ayre <lori.ayre@galecia.com>:
contracts with customers. Then, when customers insist on developing huge blocks of code (multiple new features), they will know what that means --- a much bigger cost to them because of the gargantuan effort involved in getting their final product back into the community version.
I agree with what everyone before me has said, the process is in place, it has been in place for years and has worked pretty darn well. What I want us all to agree on here and now is that there is no "community version" - there is Koha. Koha is the official release of the software and it is developed by a community of developers and users worldwide, but it's not the "community version" versus "those other versions" - it's Koha and "not yet Koha" ("not yet" because the code hasn't been integrated into the official product yet).
I think this is part of why users/librarians are so confused. They are told there is a "community version" and then a "version from your vendor" implying that one is better than and one is less than. The fact is that it's all software that serves a purpose and I won't debate which is better - I just don't really want to talk about the official version of the software - Koha - as the "community version" anymore.
Just my 2 cents.
Thanks Nicole C. Engard _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
-- Vicki Teal Lovely Helping our 52 member libraries provide the best possible service to the public. ILS Project Manager South Central Library System Madison, WI vtl@scls.lib.wi.us (608)242-4713
Hmm. Here's a random thought: If we take community out of Koha, will the software end up, as in Linux, as Koha, Offical Koha, Harley Koha (example only), Liblime Koha (example only), PTFS Koha (example only), etc.? E.g. Will people start asking of Koha, which distro are you using? Which flavor of Koha do you like best? Gary +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Gary L. Harris, M.L.S. M.A. Director, Technical Services Bureau New Mexico State Library 1209 Camino Carlos Rey Santa Fe, NM 87507 (505) 476-9730 gary.harris@state.nm.us http://www.nmstatelibrary.org <http://www.nmstatelibrary.org/> "You never change things by fighting the existing reality. To change something, build a new model that makes the existing model obsolete." -- Buckminster Fuller ________________________________ From: koha-bounces@lists.katipo.co.nz [mailto:koha-bounces@lists.katipo.co.nz] On Behalf Of vtl@scls.lib.wi.us Sent: Friday, July 02, 2010 10:21 AM To: Nicole Engard Cc: koha Subject: Re: [Koha] Koha releases Thanks for the clarification Nicole. I would further say that "Harley" is a trunk <http://en.wikipedia.org/wiki/Trunk_%28software%29> not a fork (as was once explained to me by an Evergreen developer). "Harley" is temporary, while Koha is permanent. I don't think my vendor has implied that "Harley" is better. They have said that it has features that are not yet in Koha. I would venture to say that we librarians are struggling with this new terminology but we are trying our best to understand. Vicki On Fri, Jul 2, 2010 at 10:17 AM, Nicole Engard <nengard@gmail.com> wrote: 2010/7/2 Lori Bowen Ayre <lori.ayre@galecia.com>: > contracts with customers. Then, when customers insist on developing huge > blocks of code (multiple new features), they will know what that means --- a > much bigger cost to them because of the gargantuan effort involved in > getting their final product back into the community version. I agree with what everyone before me has said, the process is in place, it has been in place for years and has worked pretty darn well. What I want us all to agree on here and now is that there is no "community version" - there is Koha. Koha is the official release of the software and it is developed by a community of developers and users worldwide, but it's not the "community version" versus "those other versions" - it's Koha and "not yet Koha" ("not yet" because the code hasn't been integrated into the official product yet). I think this is part of why users/librarians are so confused. They are told there is a "community version" and then a "version from your vendor" implying that one is better than and one is less than. The fact is that it's all software that serves a purpose and I won't debate which is better - I just don't really want to talk about the official version of the software - Koha - as the "community version" anymore. Just my 2 cents. Thanks Nicole C. Engard _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha -- Vicki Teal Lovely Helping our 52 member libraries provide the best possible service to the public. ILS Project Manager South Central Library System Madison, WI vtl@scls.lib.wi.us (608)242-4713 Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System.
If we had 20x more developers involved in Koha, the idea of different Koha flavors might not be so disturbing but the community is so small that I think we all benefit from sticking to vanilla. ;) Lori 2010/7/2 Harris, Gary, DCA <Gary.Harris@state.nm.us>
Hmm. Here's a random thought: If we take community out of Koha, will the software end up, as in Linux, as Koha, Offical Koha, Harley Koha (example only), Liblime Koha (example only), PTFS Koha (example only), etc.? E.g. Will people start asking of Koha, which distro are you using? Which flavor of Koha do you like best?
Gary +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Gary L. Harris, M.L.S. M.A. Director, Technical Services Bureau New Mexico State Library 1209 Camino Carlos Rey Santa Fe, NM 87507 (505) 476-9730 gary.harris@state.nm.us http://www.nmstatelibrary.org
"You never change things by fighting the existing reality. To change something, build a new model that makes the existing model obsolete." -- Buckminster Fuller ------------------------------ *From:* koha-bounces@lists.katipo.co.nz [mailto: koha-bounces@lists.katipo.co.nz] *On Behalf Of *vtl@scls.lib.wi.us *Sent:* Friday, July 02, 2010 10:21 AM *To:* Nicole Engard *Cc:* koha
*Subject:* Re: [Koha] Koha releases
Thanks for the clarification Nicole. I would further say that "Harley" is a trunk <http://en.wikipedia.org/wiki/Trunk_%28software%29> not a fork (as was once explained to me by an Evergreen developer). "Harley" is temporary, while Koha is permanent. I don't think my vendor has implied that "Harley" is better. They have said that it has features that are not yet in Koha.
I would venture to say that we librarians are struggling with this new terminology but we are trying our best to understand.
Vicki
On Fri, Jul 2, 2010 at 10:17 AM, Nicole Engard <nengard@gmail.com> wrote:
2010/7/2 Lori Bowen Ayre <lori.ayre@galecia.com>:
contracts with customers. Then, when customers insist on developing huge blocks of code (multiple new features), they will know what that means --- a much bigger cost to them because of the gargantuan effort involved in getting their final product back into the community version.
I agree with what everyone before me has said, the process is in place, it has been in place for years and has worked pretty darn well. What I want us all to agree on here and now is that there is no "community version" - there is Koha. Koha is the official release of the software and it is developed by a community of developers and users worldwide, but it's not the "community version" versus "those other versions" - it's Koha and "not yet Koha" ("not yet" because the code hasn't been integrated into the official product yet).
I think this is part of why users/librarians are so confused. They are told there is a "community version" and then a "version from your vendor" implying that one is better than and one is less than. The fact is that it's all software that serves a purpose and I won't debate which is better - I just don't really want to talk about the official version of the software - Koha - as the "community version" anymore.
Just my 2 cents.
Thanks Nicole C. Engard _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
-- Vicki Teal Lovely
Helping our 52 member libraries provide the best possible service to the public.
ILS Project Manager South Central Library System Madison, WI vtl@scls.lib.wi.us (608)242-4713
Confidentiality Notice: This e-mail, including all attachments is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure or distribution is prohibited unless specifically provided under the New Mexico Inspection of Public Records Act. If you are not the intended recipient, please contact the sender and destroy all copies of this message. -- This email has been scanned by the Sybari - Antigen Email System.
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Paul Poulain wrote:
I can't imagine it will be possible to merge after : time to develop + time to validate by the sponsoring org + 6 months ... (not counting features that will have been developed in // by the community version, just speaking of the technical pain !)
It sounds like the "Sell It, Free It" business model from http://www.sanisoft.com/openmodel/ Sometimes that's less politely called ransomware. It'll be possible to merge, just a lot more painful than necessary and I'd expect it to cause problems for both the community and the developer's customers if the merge doesn't go cleanly. I hope that this will provoke customers to buy elsewhere, from Support Sellers, Service Enablers and Accessorisers, and avoid that unnecessary merge pain, but they've already seemed more masochistic than I expected. Regards, -- MJ Ray (slef) Webmaster and developer for hire at | software www.software.coop http://mjr.towers.org.uk | .... co IMO only: see http://mjr.towers.org.uk/email.html | .... op
It's a bit anti-optimal (for everyone) to let your feature mods age for 6-12 (or more) months. But it also depends on the next step. Is PTFS/LL going to submit them to the current release manager as patches against a recent Koha release or just make some random code available someplace that implements those features in some old or private version of Koha and call it done? Unless it's delivered in a useful way then entities hiring PTFS/LL to perform development work are funding features that are only ever going to usable by current PTFS/LL customers. Even the funder loses the ability to use those features unless they keep buying maintenance services so they have access to the private code (I would expect). Lot's of speculation--as always it would be sweet to hear from them. Maybe after the americaland holiday. For those new to software development, a question to ask anyone you hire to add features to Koha would be "When could I expect this to be in an official Koha public release?" Things like the Harley tar file are nice (and way better than nothing) but are missing the work of taking the code that next critical step and instead depend on the chance that others will pick out those features of interest and perform the additional work. (PTFS/LL, please join this conversation so that we're not just speculating on what your future actions might be.) -reed
Thanks Reed. This is a good explanation of the issues. Vicki On Sat, Jul 3, 2010 at 8:00 AM, Reed Wade <reed@catalyst.net.nz> wrote:
It's a bit anti-optimal (for everyone) to let your feature mods age for 6-12 (or more) months. But it also depends on the next step. Is PTFS/LL going to submit them to the current release manager as patches against a recent Koha release or just make some random code available someplace that implements those features in some old or private version of Koha and call it done?
Unless it's delivered in a useful way then entities hiring PTFS/LL to perform development work are funding features that are only ever going to usable by current PTFS/LL customers. Even the funder loses the ability to use those features unless they keep buying maintenance services so they have access to the private code (I would expect).
Lot's of speculation--as always it would be sweet to hear from them. Maybe after the americaland holiday.
For those new to software development, a question to ask anyone you hire to add features to Koha would be "When could I expect this to be in an official Koha public release?" Things like the Harley tar file are nice (and way better than nothing) but are missing the work of taking the code that next critical step and instead depend on the chance that others will pick out those features of interest and perform the additional work.
(PTFS/LL, please join this conversation so that we're not just speculating on what your future actions might be.)
-reed _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
-- Vicki Teal Lovely Helping our 52 member libraries provide the best possible service to the public. ILS Project Manager South Central Library System Madison, WI vtl@scls.lib.wi.us (608)242-4713
Reed, This is exactly what I was trying to get at and I think what I've come away with -- after sorting through all this -- is that it requires educating the clients of companies doing development. We (clients) must insist on more than features we want developed. We need to also ensure that they will be developed according to the Koha community norms; namely, in such a way as to ensure that the resulting product benefits everyone and doesn't lock me (client) into a single vendor for support and further development. Lori On Sat, Jul 3, 2010 at 6:00 AM, Reed Wade <reed@catalyst.net.nz> wrote:
It's a bit anti-optimal (for everyone) to let your feature mods age for 6-12 (or more) months. But it also depends on the next step. Is PTFS/LL going to submit them to the current release manager as patches against a recent Koha release or just make some random code available someplace that implements those features in some old or private version of Koha and call it done?
Unless it's delivered in a useful way then entities hiring PTFS/LL to perform development work are funding features that are only ever going to usable by current PTFS/LL customers. Even the funder loses the ability to use those features unless they keep buying maintenance services so they have access to the private code (I would expect).
Lot's of speculation--as always it would be sweet to hear from them. Maybe after the americaland holiday.
For those new to software development, a question to ask anyone you hire to add features to Koha would be "When could I expect this to be in an official Koha public release?" Things like the Harley tar file are nice (and way better than nothing) but are missing the work of taking the code that next critical step and instead depend on the chance that others will pick out those features of interest and perform the additional work.
(PTFS/LL, please join this conversation so that we're not just speculating on what your future actions might be.)
-reed _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
2010/7/4 Lori Bowen Ayre <lori.ayre@galecia.com>:
Reed, This is exactly what I was trying to get at and I think what I've come away with -- after sorting through all this -- is that it requires educating the clients of companies doing development. We (clients) must insist on more than features we want developed. We need to also ensure that they will be developed according to the Koha community norms; namely, in such a way as to ensure that the resulting product benefits everyone and doesn't lock me (client) into a single vendor for support and further development. Lori
Hi Lori et al It's funny you should mention that, now that we have all the speakers confirmed for Kohacon10, I can let people know that on 2.15pm on the 27th, we have a group discussion scheduled to talk about just that. "Support Checklist Discussion" " There are many Koha service providers, with various offerings, from installation help, training, custom development work, general support, to full-blown hosting. Over the years, many providers and customers have gained much experience with what works and what does not. A checklist of best practices for Koha service providers and their customers would help everyone. For providers, it would suggest ways they might improve their business. For customers, what they might look for when choosing a provider. A good way to kick-off such a list would be to have a group discussion when a lot of the people involved, from all sides, are in the same room. Someone needs to write down the important points, and probably there should be a moderator to keep the discussion on track. The result would be put on the Koha wiki, with invitatations on Koha mailing lists and other fora for all to discuss and improve it." There are also some other fantastic talks lined up, we are just collecting bios etc and then the full programme will be published. Chris
Since the "phase I" includes a large number of features, I asked in the meeting how long they thought it would take for those to be integrated into the official community version of Koha. The estimate I was given was four to five years.
I was at this same meeting and I do not recall that LibLime said that it would take four to five years for "phase I" features to be released to community. It really is up to the library sponsoring the development, but I believe the plan is that the "phase I" LLEK development will be released to community in the next year. I would like to point out that this is just the practice of one LibLime customer. Most other customers will want their projects released much more dynamically. My organization, the South Central Library System, has nearly 100 feature development projects slated to be completed by LibLime by the end of 2010. Some will be finished sooner than others. So, based on the 6 month test period, some features could be ready for contribution to community Koha as soon as early 2011; hopefully in time to be integrated into Koha v.3.4.
-- Stacy Pober Information Alchemist Manhattan College Library Riverdale, NY 10471 stacy.pober@manhattan.edu _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
-- Vicki Teal Lovely Helping our 52 member libraries provide the best possible service to the public. ILS Project Manager South Central Library System Madison, WI vtl@scls.lib.wi.us (608)242-4713
I should also add that we have elected to have our development done as part of the "Harley" enterprise version rather than LLEK. The primary reason for doing so is that "Harley" is based off of community Koha from last October, which as I understand is more recent than when LLEK was last based. SCLS is fully committed to being a part of community Koha and we have no doubt that LibLime will make this happen. Having said that, it is not going to be easy due to the LLEK fork and the work that will be necessary to integrate it. I'm sure that the community and LibLime will rally together to make this happen. None of us can afford to waste development money by not sharing the development. Sharing development is why we all chose Koha to begin with. There are enough brilliant minds in this community to figure out how to proceed from here on out. We just need to get past the politics and get practical. Vicki On Fri, Jul 2, 2010 at 10:15 AM, vtl@scls.lib.wi.us <vtl@scls.lib.wi.us>wrote:
Since the "phase I" includes a large number of features, I asked in
the meeting how long they thought it would take for those to be integrated into the official community version of Koha. The estimate I was given was four to five years.
I was at this same meeting and I do not recall that LibLime said that it would take four to five years for "phase I" features to be released to community. It really is up to the library sponsoring the development, but I believe the plan is that the "phase I" LLEK development will be released to community in the next year.
I would like to point out that this is just the practice of one LibLime customer. Most other customers will want their projects released much more dynamically. My organization, the South Central Library System, has nearly 100 feature development projects slated to be completed by LibLime by the end of 2010. Some will be finished sooner than others. So, based on the 6 month test period, some features could be ready for contribution to community Koha as soon as early 2011; hopefully in time to be integrated into Koha v.3.4.
--
Stacy Pober Information Alchemist Manhattan College Library Riverdale, NY 10471 stacy.pober@manhattan.edu _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
-- Vicki Teal Lovely
Helping our 52 member libraries provide the best possible service to the public.
ILS Project Manager South Central Library System Madison, WI vtl@scls.lib.wi.us (608)242-4713
-- Vicki Teal Lovely Helping our 52 member libraries provide the best possible service to the public. ILS Project Manager South Central Library System Madison, WI vtl@scls.lib.wi.us (608)242-4713
participants (10)
-
Chris Cormack -
Harris, Gary, DCA -
Lori Bowen Ayre -
MJ Ray -
Nicole Engard -
Owen Leonard -
Paul Poulain -
Reed Wade -
Stacy Pober -
vtl＠scls.lib.wi.us