Hi Koha Users, I am a US librarian considering Koha. A friend of mine sent me the following email when I shared this and I wanted to check with other libraries to see if this is how everyone handles developments. Are you working on your own or with a support company? Are all new develpments you pay for making it into the public Koha? Thank you for info Cheryl ---------- Forwarded message ---------- From: Vicki Teal Lovely <vtl@scls.lib.wi.us> Date: Thu, Jul 30, 2009 at 9:43 AM Subject: [LibLime-Users] LibLime Users Meeting at ALA To: liblime-users@lists.liblime.com Good Morning Everyone, By now you have probably read the announcement that there was a user group meeting at ALA. Debra Denault took notes at this meeting and you will see them below. I was present at this meeting and this is an accurate transcription of the discussion that occurred there. Please keep in mind that no decisions were made at this meeting--it was only the beginning of some discussions that LibLime customers need to have. The email list was created as a forum for us to discuss topics such as these (among other things), so let's start discussing. Joshua Ferraro has suggested that we may want have a meeting to discuss these topics in person--perhaps in a virtual forum. Thanks, Vicki Teal Lovely LibLime Users Group Meeting, ALA, July 13 Attendees: LibLime (Josh, Debra, Maria) WALDO (Rob, John, Becky) Walden University - Michele INCOLSA - Becki Whitaker Highland Park - Jane Stanley SCLS - Vicky Teal Lovely Masscat - Nora Blake St. John's University - Charles ? Josh presents: Why are we here? Challenges we face *Jane Stanley said that she would be amenable to extra maintenance to support the gap between cost and expense of development LibLime user group proposal air dirty laundry expand development exchange get to know other LibLime customers improve communication of software releases improve communication of new and info to LibLime customers LibLime committed to launch a listserv next month 1. Incorporation 2. Membership 3. Funding 4. 2010 users group conference Feedback: John Stromquist - always find emergence of user's group when there is a strategic relationship between customer and vendor. Evaluate vendors performance, encourage them etc which shouldn't interfere with a broader community group. More difficult challenge of funding of future development. Exercise option by searching for solutions to the funding problems for development. Get a funding stream for development through membership dues etc. Jane - Hard for a small library that can only contribute a small amount to get anything done. Perception is that LL is too committed to these large projects to let the small guys have a say. Josh - have membership fee x% of contract value to go towards user group as well as development decisions Vicky - she would hate to see a small library with a small amount of money who has committed money to large pool and not get what they want done ... would prefer to see a) people need to see what dev projects are out there but who is going to keep it up - maybe a user group responsibility b) wishlist - we want this done can we cosponsor. Do not want to be locked into a voting situation. Kudos want to do it on larger scale but no where near being able to do it. John S - lots of ways we can approach this - some money toward larger scale but understand there are small development needs that could exist in parallel. Do a credit against funding toward positive suggestions and central fund could match it. Vicky - can't see their libraries putting there money somewhere where they do not have control over it . Nora concurs from Masscat John S - libraries want to see service out of where their money is going. WALDO sees the benefits of it. Josh - 15% wouldn't necessarily be pooled but can be. But libraries could band with others to do projects separatey. Needs to be a metric by which to measure how participation is going. John S - libraries need to know it's an equitable process Vicky - To Josh - is getting this money what LL needs to make it more stable. Help out others that may not be able to afford something specifically. Get folks together and do it. Josh - How can we make this work? Jane - Can we get a quote for LL and post to the listserv if others would want to share. Vicky - Thinks that would be better than pooling it together. Jane - It's the large consortia versus the little guys and they would have the budget to do things on their own and the small guys need the help. Josh - but WALDO could help in in any situation Becki - value of a group like this would be the method to share what we are doing and important step to be able to share our developments. Vicky - very first step - who's doing what. But we want to work with our vendor Rob - now that we are all shareholders in this and in LibLime there is a risk in sharing the development and that the investment is safe (i.e. from other vendors in the space) Need to maintain a level of discretion in involvement of other groups. Josh - if user group would like to take over and run the development exchange that would relieve our staff. Specification process is a line item. Is there a committment when a request is made for a sponsored project to be done? Vicky - Maybe two lists - one for committed project and one for good ideas and have projects move along a spectrum. Josh - LL is working on a new LibLime website that will have a login for customers to log in access Vicky - Koha bugzilla db - use that for enhancements - ??? how much do LL customers want to share with outside world what will be done. Jane - was told can't pay for bugfixes - Josh - need to figure out membership dues - just do freeform - need to figure out how it all works - can reevaluate this yearly. John - would like to propse some kind of statement of intent or recognition as a open source LL user that there is an obligation to contribute to ongoing development and money needs to be set aside for this so system can continue to grow. Not just a free lunch Vicky - part of their philosophy is we have money for development and they are contributing and they would hate to force any library to contribute to development. Doesn't want it to be part of membership requirements Josh - related to funding we at LL are interested too as we have made a significant investment in Koha and that has been at the expense of profit for us and we want to make sure development is working as sufficiently as possible. Becky - significant improvement in that a customer can be recognized for their contribution. Josh - Any thoughts on a conference? Rob - could be dependent on going live dates etc. John - alot of chatter about the community of Koha by developers need librarian input and we are looking for an organization that talk about library issues. Vicky - too soon to have a conference. Don't think folks could afford it for such a small group. Do a half day for LL users off KohaCon as automation libraries cannot go to ALA. Should be off a kudos annual conference. Jane - how does that contradict our committment to LL. Josh - part of our goal with LL users group is to build stronger legs where we can compete with other companies. Not that we are against all the other competitors - have great relationship with ByWater but there are some out there acting like sharks putting us in a difficult position Vicky - puts us in a difficult position not to be able to share with other community to users and the LL pool is too small in her opinion. Josh - well LL users contributes 97% Vicky - you will cause a rift in your customer base and there are enough that want to work with Koha users that it is going to happen. John - but there doesn't need to be a choice to be made. The kudos committment is a higher level participation. Josh - not saying can't go to the kudos or participate in kudos but we need the LL user's group conference because of other reasons. Kate - what kind of attendence of LL customers - 60% of customers - 100 people Josh - at a LL user group meeting customers can be more open and honest than if at a shared event. Charles - i'm a low level player but what he sees is a .com organization talking to a bunch of .edu organizations with different philosophies. Where/when does this mean a split in the product. Josh - 1. that's already happened . Koha by LibLime different already than what others delivered. 2. getting considerable pressure by sponsored developments to embargoing the code. 3. LL cannot change the philosophy to contribute to the community. Need to have a timed release that gives us a strategic advantage. Nora - this is very upsetting and disconcerting to us. That's not why we joined on. Josh - we would still give you all the community stuff Becky - but that breaks the value of open source Rob - the conditions have changed in being able to support the model. The user community has to answer why are we uncomfortable sharing and how the community is having adverse effect on why we got together in the first place. Vicky - would like to explore more positive ways for getting LL funding rather than break the community model of Koha. Josh - not making it not opensource - but we will hold it back. Nora/Vicky - don't like it - won't fly. Vicky - Kings County is splitting Evergreen to their own code and Vicky has been telling everyone how proud we are not in a position of having to do that. John - Jane - if there is another company underbidding are they sustainable themselves Josh - but this company has deep pockets and can sustain the loss. We have no capital backing Rob - learning a lesson from a shark that may not do much damage but what about the next shark. John - obligation to his consortia members who have contributed 750K Vicky - still share with everyone and want what they have. All of Wisconsin may all become LL customers. Rob - what we are grasping with is it open or not? It's not that it's not open but rather when does it become open. Charles - holding open source back - what period of time do you have in mind Josh - not made a concrete decision on this yet. Not intent to talk about it today but bottom line is the problem is the cost to expense ratio of development and we cannot subsidize it with other services. Vicky - how are those decisions to develop those made if didn't have funding. Becki - if we had known then that 3.2 is not till the fall they would have bought into it back in the spring. If intent is to have a product that there are delays in releasing customer needs to know more concrete dates. Rob - development exchange can address these needs by gathering funding from smaller sources to be applied to these types of big projects. Vicky - instead of you saying it's a good project a library will front it you are suggesting this needs to be done who will front it. Vicky - if you are asking for the money to get closer it needs to be Koha related not other 3rd party projects and the software needs to be brought to a level that other libraries will migrate it to it. John - it's a timing issue Vicky - LL needs to offer stable support and need to prove that we can do it and show evidence it can be done. Do not want to withhold code. It would be a hard sell for me to go back and have my library agree to that. Josh - well of course there is time involved before the customer even approves code - make it longer term quality assurance testing first with customer then LL customers then to the community at large. Other thing that needs to be considered is that LL has been leading the Koha community but there seems to be an uprising amongst other Koha developers so we won't be holding those positions of quality assurance / release management of Koha and that will mean a detrimental effect on the quality of the product - trying to address that eventuality. Jane - do you see LL version diverging from the community Vicky - isn't there a group of folks Josh - yes but release manager has final say and if we lose that capability then what if our customers are not served by the product. We are not dedicated to the Koha community to a fault. Our customers come first and need to have stable good code. WrapUp It's been a valuable conversation. Need to continue the dialog to address. Will establish LL mailing list .. appropriate time to have a group meeting. Meeting adjourned 12:06 p.m. On Thu, Jul 23, 2009 at 10:51 AM, Joshua Ferraro<jmf@liblime.com> wrote: -- Vicki Teal Lovely vtl@scls.lib.wi.us Software Applications Supervisor SCLS Automation 201 W. Mifflin St. Madison, WI 53703 (608)261-9109 _______________________________________________ LibLime-Users mailing list LibLime-Users@lists.liblime.com http://lists.liblime.com/cgi-bin/mailman/listinfo/liblime-users
No Cheryl, this is not at all the way the Koha Community operates as a rule. There are plenty of other vendors who are prepared to honour the licensing conditions designed to keep Koha the open source project it was released as and should always be. Choose another vendor if you are uncomfortable about a vendors choice to hold back code or not contribute to the good of the community; there are plenty of good alternatives out there. Cheers Joann Ransom. Horowhenua Library Trust original developers of Koha. C MC wrote:
Hi Koha Users,
I am a US librarian considering Koha. A friend of mine sent me the following email when I shared this and I wanted to check with other libraries to see if this is how everyone handles developments. Are you working on your own or with a support company? Are all new develpments you pay for making it into the public Koha?
Thank you for info Cheryl
---------- Forwarded message ---------- From: Vicki Teal Lovely <vtl@scls.lib.wi.us <mailto:vtl@scls.lib.wi.us>> Date: Thu, Jul 30, 2009 at 9:43 AM Subject: [LibLime-Users] LibLime Users Meeting at ALA To: liblime-users@lists.liblime.com <mailto:liblime-users@lists.liblime.com>
Good Morning Everyone,
By now you have probably read the announcement that there was a user group meeting at ALA. Debra Denault took notes at this meeting and you will see them below. I was present at this meeting and this is an accurate transcription of the discussion that occurred there. Please keep in mind that no decisions were made at this meeting--it was only the beginning of some discussions that LibLime customers need to have. The email list was created as a forum for us to discuss topics such as these (among other things), so let's start discussing. Joshua Ferraro has suggested that we may want have a meeting to discuss these topics in person--perhaps in a virtual forum.
Thanks,
Vicki Teal Lovely
LibLime Users Group Meeting, ALA, July 13
Attendees: LibLime (Josh, Debra, Maria) WALDO (Rob, John, Becky) Walden University - Michele INCOLSA - Becki Whitaker Highland Park - Jane Stanley SCLS - Vicky Teal Lovely Masscat - Nora Blake St. John's University - Charles ?
Josh presents:
Why are we here? Challenges we face
*Jane Stanley said that she would be amenable to extra maintenance to support the gap between cost and expense of development
LibLime user group proposal
air dirty laundry expand development exchange get to know other LibLime customers improve communication of software releases improve communication of new and info to LibLime customers LibLime committed to launch a listserv next month
1. Incorporation 2. Membership 3. Funding 4. 2010 users group conference
Feedback:
John Stromquist - always find emergence of user's group when there is a strategic relationship between customer and vendor. Evaluate vendors performance, encourage them etc which shouldn't interfere with a broader community group. More difficult challenge of funding of future development. Exercise option by searching for solutions to the funding problems for development. Get a funding stream for development through membership dues etc.
Jane - Hard for a small library that can only contribute a small amount to get anything done. Perception is that LL is too committed to these large projects to let the small guys have a say.
Josh - have membership fee x% of contract value to go towards user group as well as development decisions
Vicky - she would hate to see a small library with a small amount of money who has committed money to large pool and not get what they want done ... would prefer to see a) people need to see what dev projects are out there but who is going to keep it up - maybe a user group responsibility b) wishlist - we want this done can we cosponsor. Do not want to be locked into a voting situation. Kudos want to do it on larger scale but no where near being able to do it.
John S - lots of ways we can approach this - some money toward larger scale but understand there are small development needs that could exist in parallel. Do a credit against funding toward positive suggestions and central fund could match it.
Vicky - can't see their libraries putting there money somewhere where they do not have control over it . Nora concurs from Masscat
John S - libraries want to see service out of where their money is going. WALDO sees the benefits of it.
Josh - 15% wouldn't necessarily be pooled but can be. But libraries could band with others to do projects separatey. Needs to be a metric by which to measure how participation is going.
John S - libraries need to know it's an equitable process
Vicky - To Josh - is getting this money what LL needs to make it more stable. Help out others that may not be able to afford something specifically. Get folks together and do it.
Josh - How can we make this work?
Jane - Can we get a quote for LL and post to the listserv if others would want to share.
Vicky - Thinks that would be better than pooling it together.
Jane - It's the large consortia versus the little guys and they would have the budget to do things on their own and the small guys need the help.
Josh - but WALDO could help in in any situation
Becki - value of a group like this would be the method to share what we are doing and important step to be able to share our developments.
Vicky - very first step - who's doing what. But we want to work with our vendor
Rob - now that we are all shareholders in this and in LibLime there is a risk in sharing the development and that the investment is safe (i.e. from other vendors in the space) Need to maintain a level of discretion in involvement of other groups.
Josh - if user group would like to take over and run the development exchange that would relieve our staff. Specification process is a line item. Is there a committment when a request is made for a sponsored project to be done?
Vicky - Maybe two lists - one for committed project and one for good ideas and have projects move along a spectrum.
Josh - LL is working on a new LibLime website that will have a login for customers to log in access
Vicky - Koha bugzilla db - use that for enhancements - ??? how much do LL customers want to share with outside world what will be done.
Jane - was told can't pay for bugfixes -
Josh - need to figure out membership dues - just do freeform - need to figure out how it all works - can reevaluate this yearly.
John - would like to propse some kind of statement of intent or recognition as a open source LL user that there is an obligation to contribute to ongoing development and money needs to be set aside for this so system can continue to grow. Not just a free lunch
Vicky - part of their philosophy is we have money for development and they are contributing and they would hate to force any library to contribute to development. Doesn't want it to be part of membership requirements
Josh - related to funding we at LL are interested too as we have made a significant investment in Koha and that has been at the expense of profit for us and we want to make sure development is working as sufficiently as possible.
Becky - significant improvement in that a customer can be recognized for their contribution.
Josh - Any thoughts on a conference?
Rob - could be dependent on going live dates etc.
John - alot of chatter about the community of Koha by developers need librarian input and we are looking for an organization that talk about library issues.
Vicky - too soon to have a conference. Don't think folks could afford it for such a small group. Do a half day for LL users off KohaCon as automation libraries cannot go to ALA. Should be off a kudos annual conference.
Jane - how does that contradict our committment to LL.
Josh - part of our goal with LL users group is to build stronger legs where we can compete with other companies. Not that we are against all the other competitors - have great relationship with ByWater but there are some out there acting like sharks putting us in a difficult position
Vicky - puts us in a difficult position not to be able to share with other community to users and the LL pool is too small in her opinion.
Josh - well LL users contributes 97%
Vicky - you will cause a rift in your customer base and there are enough that want to work with Koha users that it is going to happen.
John - but there doesn't need to be a choice to be made. The kudos committment is a higher level participation.
Josh - not saying can't go to the kudos or participate in kudos but we need the LL user's group conference because of other reasons.
Kate - what kind of attendence of LL customers - 60% of customers - 100 people
Josh - at a LL user group meeting customers can be more open and honest than if at a shared event.
Charles - i'm a low level player but what he sees is a .com organization talking to a bunch of .edu organizations with different philosophies. Where/when does this mean a split in the product.
Josh - 1. that's already happened . Koha by LibLime different already than what others delivered. 2. getting considerable pressure by sponsored developments to embargoing the code. 3. LL cannot change the philosophy to contribute to the community. Need to have a timed release that gives us a strategic advantage.
Nora - this is very upsetting and disconcerting to us. That's not why we joined on.
Josh - we would still give you all the community stuff
Becky - but that breaks the value of open source
Rob - the conditions have changed in being able to support the model. The user community has to answer why are we uncomfortable sharing and how the community is having adverse effect on why we got together in the first place.
Vicky - would like to explore more positive ways for getting LL funding rather than break the community model of Koha.
Josh - not making it not opensource - but we will hold it back.
Nora/Vicky - don't like it - won't fly.
Vicky - Kings County is splitting Evergreen to their own code and Vicky has been telling everyone how proud we are not in a position of having to do that.
John -
Jane - if there is another company underbidding are they sustainable themselves
Josh - but this company has deep pockets and can sustain the loss. We have no capital backing
Rob - learning a lesson from a shark that may not do much damage but what about the next shark.
John - obligation to his consortia members who have contributed 750K
Vicky - still share with everyone and want what they have. All of Wisconsin may all become LL customers.
Rob - what we are grasping with is it open or not? It's not that it's not open but rather when does it become open.
Charles - holding open source back - what period of time do you have in mind
Josh - not made a concrete decision on this yet. Not intent to talk about it today but bottom line is the problem is the cost to expense ratio of development and we cannot subsidize it with other services.
Vicky - how are those decisions to develop those made if didn't have funding.
Becki - if we had known then that 3.2 is not till the fall they would have bought into it back in the spring. If intent is to have a product that there are delays in releasing customer needs to know more concrete dates.
Rob - development exchange can address these needs by gathering funding from smaller sources to be applied to these types of big projects.
Vicky - instead of you saying it's a good project a library will front it you are suggesting this needs to be done who will front it.
Vicky - if you are asking for the money to get closer it needs to be Koha related not other 3rd party projects and the software needs to be brought to a level that other libraries will migrate it to it.
John - it's a timing issue
Vicky - LL needs to offer stable support and need to prove that we can do it and show evidence it can be done. Do not want to withhold code. It would be a hard sell for me to go back and have my library agree to that.
Josh - well of course there is time involved before the customer even approves code - make it longer term quality assurance testing first with customer then LL customers then to the community at large. Other thing that needs to be considered is that LL has been leading the Koha community but there seems to be an uprising amongst other Koha developers so we won't be holding those positions of quality assurance / release management of Koha and that will mean a detrimental effect on the quality of the product - trying to address that eventuality.
Jane - do you see LL version diverging from the community
Vicky - isn't there a group of folks
Josh - yes but release manager has final say and if we lose that capability then what if our customers are not served by the product. We are not dedicated to the Koha community to a fault. Our customers come first and need to have stable good code.
WrapUp
It's been a valuable conversation. Need to continue the dialog to address. Will establish LL mailing list .. appropriate time to have a group meeting.
Meeting adjourned 12:06 p.m.
On Thu, Jul 23, 2009 at 10:51 AM, Joshua Ferraro<jmf@liblime.com <mailto:jmf@liblime.com>> wrote:
-- Vicki Teal Lovely
vtl@scls.lib.wi.us <mailto:vtl@scls.lib.wi.us>
Software Applications Supervisor SCLS Automation 201 W. Mifflin St. Madison, WI 53703
(608)261-9109
_______________________________________________ LibLime-Users mailing list LibLime-Users@lists.liblime.com <mailto:LibLime-Users@lists.liblime.com> http://lists.liblime.com/cgi-bin/mailman/listinfo/liblime-users
------------------------------------------------------------------------
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
No Cheryl, this is not at all the way the Koha Community operates as a rule. There are plenty of other vendors who are prepared to honour the licensing conditions designed to keep Koha the open source project it was released as and should always be. Choose another vendor if you are uncomfortable about a vendors choice to hold back code or not contribute to the good of the community; there are plenty of good alternatives out there. This is very misleading, Joann! It has been well established that Horowhenua in particular has withheld code from the Koha community. For instance, the version of Koha that you are now running live on, has code and templates that have never been shared with the rest of us. It certainly wasn't done out of spite, but is just the reality of
On Mon, Aug 3, 2009 at 7:19 PM, Joann Ransom<jransom@library.org.nz> wrote: limited resources of the vendor that supported you. Since this has turned into an attack on LibLime I feel I must state for the record that, as far as I know, LibLime is the ONLY vendor that has historically contributed 100% of our code as soon as it was approved by a customer's quality assurance testing. As far as I know, every other vendor in the Koha community intentionally withholds customizations that are only available to their customers, or don't take the time to fully integrate their code into the mainline Koha codebase (understandably so, as this either gives them a competitive edge, or they simply don't have time to contribute it). I've had contractors who have worked for me, and for other vendors in the community confirm this of nearly all of the active Koha vendors listed on the support page (if that's not the case at your firm, and you feel I'm misrepresenting you, please correct me). Also, please check your sources. The GPL V2 (which Koha uses) only _requires_ redistribution of modifications if the code leaves the servers owned by the creator of the modifications. So, companies who host Koha in a software as a service environment are not obligated to redistribute their code to the community (which is why so many Koha vendors are able to withhold their code). Also, the GPL V2 only requires making the source code available to the specific people it is re-distributed to, there is no requirement for people to spend time they may not have, integrating their changes into the main project! It's a good thing too, otherwise many of the people implementing Koha, or supporting Koha, wouldn't have the resources to continue doing so. It's frankly depressing that after contributing well over 60% of Koha's codebase to date, these kind of negative implications about LibLime are injected into the community with such disregard for all the 'good' we've done. Also, for the record, as requested by LibLime's customers, the LibLime Users's Group list is a closed list, so messages sent to that list should NOT be forwarded to the general Koha list, or anywhere else. Cheers, Josh
Joann Ransom. Horowhenua Library Trust original developers of Koha.
C MC wrote:
Hi Koha Users,
I am a US librarian considering Koha. A friend of mine sent me the following email when I shared this and I wanted to check with other libraries to see if this is how everyone handles developments. Are you working on your own or with a support company? Are all new develpments you pay for making it into the public Koha?
Thank you for info Cheryl
---------- Forwarded message ---------- From: Vicki Teal Lovely <vtl@scls.lib.wi.us <mailto:vtl@scls.lib.wi.us>> Date: Thu, Jul 30, 2009 at 9:43 AM Subject: [LibLime-Users] LibLime Users Meeting at ALA To: liblime-users@lists.liblime.com <mailto:liblime-users@lists.liblime.com>
Good Morning Everyone,
By now you have probably read the announcement that there was a user group meeting at ALA. Debra Denault took notes at this meeting and you will see them below. I was present at this meeting and this is an accurate transcription of the discussion that occurred there. Please keep in mind that no decisions were made at this meeting--it was only the beginning of some discussions that LibLime customers need to have. The email list was created as a forum for us to discuss topics such as these (among other things), so let's start discussing. Joshua Ferraro has suggested that we may want have a meeting to discuss these topics in person--perhaps in a virtual forum.
Thanks,
Vicki Teal Lovely
LibLime Users Group Meeting, ALA, July 13
Attendees: LibLime (Josh, Debra, Maria) WALDO (Rob, John, Becky) Walden University - Michele INCOLSA - Becki Whitaker Highland Park - Jane Stanley SCLS - Vicky Teal Lovely Masscat - Nora Blake St. John's University - Charles ?
Josh presents:
Why are we here? Challenges we face
*Jane Stanley said that she would be amenable to extra maintenance to support the gap between cost and expense of development
LibLime user group proposal
air dirty laundry expand development exchange get to know other LibLime customers improve communication of software releases improve communication of new and info to LibLime customers LibLime committed to launch a listserv next month
1. Incorporation 2. Membership 3. Funding 4. 2010 users group conference
Feedback:
John Stromquist - always find emergence of user's group when there is a strategic relationship between customer and vendor. Evaluate vendors performance, encourage them etc which shouldn't interfere with a broader community group. More difficult challenge of funding of future development. Exercise option by searching for solutions to the funding problems for development. Get a funding stream for development through membership dues etc.
Jane - Hard for a small library that can only contribute a small amount to get anything done. Perception is that LL is too committed to these large projects to let the small guys have a say.
Josh - have membership fee x% of contract value to go towards user group as well as development decisions
Vicky - she would hate to see a small library with a small amount of money who has committed money to large pool and not get what they want done ... would prefer to see a) people need to see what dev projects are out there but who is going to keep it up - maybe a user group responsibility b) wishlist - we want this done can we cosponsor. Do not want to be locked into a voting situation. Kudos want to do it on larger scale but no where near being able to do it.
John S - lots of ways we can approach this - some money toward larger scale but understand there are small development needs that could exist in parallel. Do a credit against funding toward positive suggestions and central fund could match it.
Vicky - can't see their libraries putting there money somewhere where they do not have control over it . Nora concurs from Masscat
John S - libraries want to see service out of where their money is going. WALDO sees the benefits of it.
Josh - 15% wouldn't necessarily be pooled but can be. But libraries could band with others to do projects separatey. Needs to be a metric by which to measure how participation is going.
John S - libraries need to know it's an equitable process
Vicky - To Josh - is getting this money what LL needs to make it more stable. Help out others that may not be able to afford something specifically. Get folks together and do it.
Josh - How can we make this work?
Jane - Can we get a quote for LL and post to the listserv if others would want to share.
Vicky - Thinks that would be better than pooling it together.
Jane - It's the large consortia versus the little guys and they would have the budget to do things on their own and the small guys need the help.
Josh - but WALDO could help in in any situation
Becki - value of a group like this would be the method to share what we are doing and important step to be able to share our developments.
Vicky - very first step - who's doing what. But we want to work with our vendor
Rob - now that we are all shareholders in this and in LibLime there is a risk in sharing the development and that the investment is safe (i.e. from other vendors in the space) Need to maintain a level of discretion in involvement of other groups.
Josh - if user group would like to take over and run the development exchange that would relieve our staff. Specification process is a line item. Is there a committment when a request is made for a sponsored project to be done?
Vicky - Maybe two lists - one for committed project and one for good ideas and have projects move along a spectrum.
Josh - LL is working on a new LibLime website that will have a login for customers to log in access
Vicky - Koha bugzilla db - use that for enhancements - ??? how much do LL customers want to share with outside world what will be done.
Jane - was told can't pay for bugfixes -
Josh - need to figure out membership dues - just do freeform - need to figure out how it all works - can reevaluate this yearly.
John - would like to propse some kind of statement of intent or recognition as a open source LL user that there is an obligation to contribute to ongoing development and money needs to be set aside for this so system can continue to grow. Not just a free lunch
Vicky - part of their philosophy is we have money for development and they are contributing and they would hate to force any library to contribute to development. Doesn't want it to be part of membership requirements
Josh - related to funding we at LL are interested too as we have made a significant investment in Koha and that has been at the expense of profit for us and we want to make sure development is working as sufficiently as possible.
Becky - significant improvement in that a customer can be recognized for their contribution.
Josh - Any thoughts on a conference?
Rob - could be dependent on going live dates etc.
John - alot of chatter about the community of Koha by developers need librarian input and we are looking for an organization that talk about library issues.
Vicky - too soon to have a conference. Don't think folks could afford it for such a small group. Do a half day for LL users off KohaCon as automation libraries cannot go to ALA. Should be off a kudos annual conference.
Jane - how does that contradict our committment to LL.
Josh - part of our goal with LL users group is to build stronger legs where we can compete with other companies. Not that we are against all the other competitors - have great relationship with ByWater but there are some out there acting like sharks putting us in a difficult position
Vicky - puts us in a difficult position not to be able to share with other community to users and the LL pool is too small in her opinion.
Josh - well LL users contributes 97%
Vicky - you will cause a rift in your customer base and there are enough that want to work with Koha users that it is going to happen.
John - but there doesn't need to be a choice to be made. The kudos committment is a higher level participation.
Josh - not saying can't go to the kudos or participate in kudos but we need the LL user's group conference because of other reasons.
Kate - what kind of attendence of LL customers - 60% of customers - 100 people
Josh - at a LL user group meeting customers can be more open and honest than if at a shared event.
Charles - i'm a low level player but what he sees is a .com organization talking to a bunch of .edu organizations with different philosophies. Where/when does this mean a split in the product.
Josh - 1. that's already happened . Koha by LibLime different already than what others delivered. 2. getting considerable pressure by sponsored developments to embargoing the code. 3. LL cannot change the philosophy to contribute to the community. Need to have a timed release that gives us a strategic advantage.
Nora - this is very upsetting and disconcerting to us. That's not why we joined on.
Josh - we would still give you all the community stuff
Becky - but that breaks the value of open source
Rob - the conditions have changed in being able to support the model. The user community has to answer why are we uncomfortable sharing and how the community is having adverse effect on why we got together in the first place.
Vicky - would like to explore more positive ways for getting LL funding rather than break the community model of Koha.
Josh - not making it not opensource - but we will hold it back.
Nora/Vicky - don't like it - won't fly.
Vicky - Kings County is splitting Evergreen to their own code and Vicky has been telling everyone how proud we are not in a position of having to do that.
John -
Jane - if there is another company underbidding are they sustainable themselves
Josh - but this company has deep pockets and can sustain the loss. We have no capital backing
Rob - learning a lesson from a shark that may not do much damage but what about the next shark.
John - obligation to his consortia members who have contributed 750K
Vicky - still share with everyone and want what they have. All of Wisconsin may all become LL customers.
Rob - what we are grasping with is it open or not? It's not that it's not open but rather when does it become open.
Charles - holding open source back - what period of time do you have in mind
Josh - not made a concrete decision on this yet. Not intent to talk about it today but bottom line is the problem is the cost to expense ratio of development and we cannot subsidize it with other services.
Vicky - how are those decisions to develop those made if didn't have funding.
Becki - if we had known then that 3.2 is not till the fall they would have bought into it back in the spring. If intent is to have a product that there are delays in releasing customer needs to know more concrete dates.
Rob - development exchange can address these needs by gathering funding from smaller sources to be applied to these types of big projects.
Vicky - instead of you saying it's a good project a library will front it you are suggesting this needs to be done who will front it.
Vicky - if you are asking for the money to get closer it needs to be Koha related not other 3rd party projects and the software needs to be brought to a level that other libraries will migrate it to it.
John - it's a timing issue
Vicky - LL needs to offer stable support and need to prove that we can do it and show evidence it can be done. Do not want to withhold code. It would be a hard sell for me to go back and have my library agree to that.
Josh - well of course there is time involved before the customer even approves code - make it longer term quality assurance testing first with customer then LL customers then to the community at large. Other thing that needs to be considered is that LL has been leading the Koha community but there seems to be an uprising amongst other Koha developers so we won't be holding those positions of quality assurance / release management of Koha and that will mean a detrimental effect on the quality of the product - trying to address that eventuality.
Jane - do you see LL version diverging from the community
Vicky - isn't there a group of folks
Josh - yes but release manager has final say and if we lose that capability then what if our customers are not served by the product. We are not dedicated to the Koha community to a fault. Our customers come first and need to have stable good code.
WrapUp
It's been a valuable conversation. Need to continue the dialog to address. Will establish LL mailing list .. appropriate time to have a group meeting.
Meeting adjourned 12:06 p.m.
On Thu, Jul 23, 2009 at 10:51 AM, Joshua Ferraro<jmf@liblime.com <mailto:jmf@liblime.com>> wrote:
-- Vicki Teal Lovely
vtl@scls.lib.wi.us <mailto:vtl@scls.lib.wi.us>
Software Applications Supervisor SCLS Automation 201 W. Mifflin St. Madison, WI 53703
(608)261-9109
_______________________________________________ LibLime-Users mailing list LibLime-Users@lists.liblime.com <mailto:LibLime-Users@lists.liblime.com> http://lists.liblime.com/cgi-bin/mailman/listinfo/liblime-users
------------------------------------------------------------------------
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
-- Joshua Ferraro SUPPORT FOR OPEN-SOURCE SOFTWARE CEO migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
Hi Josh, Not sure my response warranted such a full frontal attack mate .... Cheers Jo. Joshua Ferraro wrote:
On Mon, Aug 3, 2009 at 7:19 PM, Joann Ransom<jransom@library.org.nz> wrote:
No Cheryl, this is not at all the way the Koha Community operates as a rule. There are plenty of other vendors who are prepared to honour the licensing conditions designed to keep Koha the open source project it was released as and should always be. Choose another vendor if you are uncomfortable about a vendors choice to hold back code or not contribute to the good of the community; there are plenty of good alternatives out there.
This is very misleading, Joann! It has been well established that Horowhenua in particular has withheld code from the Koha community. For instance, the version of Koha that you are now running live on, has code and templates that have never been shared with the rest of us. It certainly wasn't done out of spite, but is just the reality of limited resources of the vendor that supported you.
Since this has turned into an attack on LibLime I feel I must state for the record that, as far as I know, LibLime is the ONLY vendor that has historically contributed 100% of our code as soon as it was approved by a customer's quality assurance testing. As far as I know, every other vendor in the Koha community intentionally withholds customizations that are only available to their customers, or don't take the time to fully integrate their code into the mainline Koha codebase (understandably so, as this either gives them a competitive edge, or they simply don't have time to contribute it).
I've had contractors who have worked for me, and for other vendors in the community confirm this of nearly all of the active Koha vendors listed on the support page (if that's not the case at your firm, and you feel I'm misrepresenting you, please correct me).
Also, please check your sources. The GPL V2 (which Koha uses) only _requires_ redistribution of modifications if the code leaves the servers owned by the creator of the modifications. So, companies who host Koha in a software as a service environment are not obligated to redistribute their code to the community (which is why so many Koha vendors are able to withhold their code). Also, the GPL V2 only requires making the source code available to the specific people it is re-distributed to, there is no requirement for people to spend time they may not have, integrating their changes into the main project! It's a good thing too, otherwise many of the people implementing Koha, or supporting Koha, wouldn't have the resources to continue doing so.
It's frankly depressing that after contributing well over 60% of Koha's codebase to date, these kind of negative implications about LibLime are injected into the community with such disregard for all the 'good' we've done.
Also, for the record, as requested by LibLime's customers, the LibLime Users's Group list is a closed list, so messages sent to that list should NOT be forwarded to the general Koha list, or anywhere else.
Cheers,
Josh
Joann Ransom. Horowhenua Library Trust original developers of Koha.
C MC wrote:
Hi Koha Users,
I am a US librarian considering Koha. A friend of mine sent me the following email when I shared this and I wanted to check with other libraries to see if this is how everyone handles developments. Are you working on your own or with a support company? Are all new develpments you pay for making it into the public Koha?
Thank you for info Cheryl
---------- Forwarded message ---------- From: Vicki Teal Lovely <vtl@scls.lib.wi.us <mailto:vtl@scls.lib.wi.us>> Date: Thu, Jul 30, 2009 at 9:43 AM Subject: [LibLime-Users] LibLime Users Meeting at ALA To: liblime-users@lists.liblime.com <mailto:liblime-users@lists.liblime.com>
Good Morning Everyone,
By now you have probably read the announcement that there was a user group meeting at ALA. Debra Denault took notes at this meeting and you will see them below. I was present at this meeting and this is an accurate transcription of the discussion that occurred there. Please keep in mind that no decisions were made at this meeting--it was only the beginning of some discussions that LibLime customers need to have. The email list was created as a forum for us to discuss topics such as these (among other things), so let's start discussing. Joshua Ferraro has suggested that we may want have a meeting to discuss these topics in person--perhaps in a virtual forum.
Thanks,
Vicki Teal Lovely
LibLime Users Group Meeting, ALA, July 13
Attendees: LibLime (Josh, Debra, Maria) WALDO (Rob, John, Becky) Walden University - Michele INCOLSA - Becki Whitaker Highland Park - Jane Stanley SCLS - Vicky Teal Lovely Masscat - Nora Blake St. John's University - Charles ?
Josh presents:
Why are we here? Challenges we face
*Jane Stanley said that she would be amenable to extra maintenance to support the gap between cost and expense of development
LibLime user group proposal
air dirty laundry expand development exchange get to know other LibLime customers improve communication of software releases improve communication of new and info to LibLime customers LibLime committed to launch a listserv next month
1. Incorporation 2. Membership 3. Funding 4. 2010 users group conference
Feedback:
John Stromquist - always find emergence of user's group when there is a strategic relationship between customer and vendor. Evaluate vendors performance, encourage them etc which shouldn't interfere with a broader community group. More difficult challenge of funding of future development. Exercise option by searching for solutions to the funding problems for development. Get a funding stream for development through membership dues etc.
Jane - Hard for a small library that can only contribute a small amount to get anything done. Perception is that LL is too committed to these large projects to let the small guys have a say.
Josh - have membership fee x% of contract value to go towards user group as well as development decisions
Vicky - she would hate to see a small library with a small amount of money who has committed money to large pool and not get what they want done ... would prefer to see a) people need to see what dev projects are out there but who is going to keep it up - maybe a user group responsibility b) wishlist - we want this done can we cosponsor. Do not want to be locked into a voting situation. Kudos want to do it on larger scale but no where near being able to do it.
John S - lots of ways we can approach this - some money toward larger scale but understand there are small development needs that could exist in parallel. Do a credit against funding toward positive suggestions and central fund could match it.
Vicky - can't see their libraries putting there money somewhere where they do not have control over it . Nora concurs from Masscat
John S - libraries want to see service out of where their money is going. WALDO sees the benefits of it.
Josh - 15% wouldn't necessarily be pooled but can be. But libraries could band with others to do projects separatey. Needs to be a metric by which to measure how participation is going.
John S - libraries need to know it's an equitable process
Vicky - To Josh - is getting this money what LL needs to make it more stable. Help out others that may not be able to afford something specifically. Get folks together and do it.
Josh - How can we make this work?
Jane - Can we get a quote for LL and post to the listserv if others would want to share.
Vicky - Thinks that would be better than pooling it together.
Jane - It's the large consortia versus the little guys and they would have the budget to do things on their own and the small guys need the help.
Josh - but WALDO could help in in any situation
Becki - value of a group like this would be the method to share what we are doing and important step to be able to share our developments.
Vicky - very first step - who's doing what. But we want to work with our vendor
Rob - now that we are all shareholders in this and in LibLime there is a risk in sharing the development and that the investment is safe (i.e. from other vendors in the space) Need to maintain a level of discretion in involvement of other groups.
Josh - if user group would like to take over and run the development exchange that would relieve our staff. Specification process is a line item. Is there a committment when a request is made for a sponsored project to be done?
Vicky - Maybe two lists - one for committed project and one for good ideas and have projects move along a spectrum.
Josh - LL is working on a new LibLime website that will have a login for customers to log in access
Vicky - Koha bugzilla db - use that for enhancements - ??? how much do LL customers want to share with outside world what will be done.
Jane - was told can't pay for bugfixes -
Josh - need to figure out membership dues - just do freeform - need to figure out how it all works - can reevaluate this yearly.
John - would like to propse some kind of statement of intent or recognition as a open source LL user that there is an obligation to contribute to ongoing development and money needs to be set aside for this so system can continue to grow. Not just a free lunch
Vicky - part of their philosophy is we have money for development and they are contributing and they would hate to force any library to contribute to development. Doesn't want it to be part of membership requirements
Josh - related to funding we at LL are interested too as we have made a significant investment in Koha and that has been at the expense of profit for us and we want to make sure development is working as sufficiently as possible.
Becky - significant improvement in that a customer can be recognized for their contribution.
Josh - Any thoughts on a conference?
Rob - could be dependent on going live dates etc.
John - alot of chatter about the community of Koha by developers need librarian input and we are looking for an organization that talk about library issues.
Vicky - too soon to have a conference. Don't think folks could afford it for such a small group. Do a half day for LL users off KohaCon as automation libraries cannot go to ALA. Should be off a kudos annual conference.
Jane - how does that contradict our committment to LL.
Josh - part of our goal with LL users group is to build stronger legs where we can compete with other companies. Not that we are against all the other competitors - have great relationship with ByWater but there are some out there acting like sharks putting us in a difficult position
Vicky - puts us in a difficult position not to be able to share with other community to users and the LL pool is too small in her opinion.
Josh - well LL users contributes 97%
Vicky - you will cause a rift in your customer base and there are enough that want to work with Koha users that it is going to happen.
John - but there doesn't need to be a choice to be made. The kudos committment is a higher level participation.
Josh - not saying can't go to the kudos or participate in kudos but we need the LL user's group conference because of other reasons.
Kate - what kind of attendence of LL customers - 60% of customers - 100 people
Josh - at a LL user group meeting customers can be more open and honest than if at a shared event.
Charles - i'm a low level player but what he sees is a .com organization talking to a bunch of .edu organizations with different philosophies. Where/when does this mean a split in the product.
Josh - 1. that's already happened . Koha by LibLime different already than what others delivered. 2. getting considerable pressure by sponsored developments to embargoing the code. 3. LL cannot change the philosophy to contribute to the community. Need to have a timed release that gives us a strategic advantage.
Nora - this is very upsetting and disconcerting to us. That's not why we joined on.
Josh - we would still give you all the community stuff
Becky - but that breaks the value of open source
Rob - the conditions have changed in being able to support the model. The user community has to answer why are we uncomfortable sharing and how the community is having adverse effect on why we got together in the first place.
Vicky - would like to explore more positive ways for getting LL funding rather than break the community model of Koha.
Josh - not making it not opensource - but we will hold it back.
Nora/Vicky - don't like it - won't fly.
Vicky - Kings County is splitting Evergreen to their own code and Vicky has been telling everyone how proud we are not in a position of having to do that.
John -
Jane - if there is another company underbidding are they sustainable themselves
Josh - but this company has deep pockets and can sustain the loss. We have no capital backing
Rob - learning a lesson from a shark that may not do much damage but what about the next shark.
John - obligation to his consortia members who have contributed 750K
Vicky - still share with everyone and want what they have. All of Wisconsin may all become LL customers.
Rob - what we are grasping with is it open or not? It's not that it's not open but rather when does it become open.
Charles - holding open source back - what period of time do you have in mind
Josh - not made a concrete decision on this yet. Not intent to talk about it today but bottom line is the problem is the cost to expense ratio of development and we cannot subsidize it with other services.
Vicky - how are those decisions to develop those made if didn't have funding.
Becki - if we had known then that 3.2 is not till the fall they would have bought into it back in the spring. If intent is to have a product that there are delays in releasing customer needs to know more concrete dates.
Rob - development exchange can address these needs by gathering funding from smaller sources to be applied to these types of big projects.
Vicky - instead of you saying it's a good project a library will front it you are suggesting this needs to be done who will front it.
Vicky - if you are asking for the money to get closer it needs to be Koha related not other 3rd party projects and the software needs to be brought to a level that other libraries will migrate it to it.
John - it's a timing issue
Vicky - LL needs to offer stable support and need to prove that we can do it and show evidence it can be done. Do not want to withhold code. It would be a hard sell for me to go back and have my library agree to that.
Josh - well of course there is time involved before the customer even approves code - make it longer term quality assurance testing first with customer then LL customers then to the community at large. Other thing that needs to be considered is that LL has been leading the Koha community but there seems to be an uprising amongst other Koha developers so we won't be holding those positions of quality assurance / release management of Koha and that will mean a detrimental effect on the quality of the product - trying to address that eventuality.
Jane - do you see LL version diverging from the community
Vicky - isn't there a group of folks
Josh - yes but release manager has final say and if we lose that capability then what if our customers are not served by the product. We are not dedicated to the Koha community to a fault. Our customers come first and need to have stable good code.
WrapUp
It's been a valuable conversation. Need to continue the dialog to address. Will establish LL mailing list .. appropriate time to have a group meeting.
Meeting adjourned 12:06 p.m.
On Thu, Jul 23, 2009 at 10:51 AM, Joshua Ferraro<jmf@liblime.com <mailto:jmf@liblime.com>> wrote:
-- Vicki Teal Lovely
vtl@scls.lib.wi.us <mailto:vtl@scls.lib.wi.us>
Software Applications Supervisor SCLS Automation 201 W. Mifflin St. Madison, WI 53703
(608)261-9109
_______________________________________________ LibLime-Users mailing list LibLime-Users@lists.liblime.com <mailto:LibLime-Users@lists.liblime.com> http://lists.liblime.com/cgi-bin/mailman/listinfo/liblime-users
------------------------------------------------------------------------
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
2009/8/4 Joann Ransom <jransom@library.org.nz>:
Hi Josh,
Not sure my response warranted such a full frontal attack mate ....
Can we just treat this calmy ... Joshua you know that HLT are the reason Koha exists, attacking Jo like this is not very nice to watch. And long may it continue that Liblime contributes the source back to the community, you would have forgiven anyone who read the minutes for thinking that Liblime was planning other wise though. Chris
Have to say that I do not feel that Josh's response was either a "full frontal attack" on Joann or ill-tempered. Joann stated in fairly clear terms her view that LibLime does not intend either to honor the licensing conditions that have historically guided Koha's development or to "contribute to the good of the community." Whatever the merits of her opinions, LibLime certainly has the right to respond to what would be considered pretty serious charges in any open source community. Josh did so, and in a way that, at least in my view, falls within the norms of meaningful and respectful discourse. Full disclosure -- We're a small-fry client of LibLime's, but know for sure that the company is not perfect. With respect to Brooke's point about closed lists, I don't see that it is a priori unreasonable for clients of a particular company to have a separate forum in which to interact with each other and with the company in question. One thing IS clear, however: the intersection of open source and private commerce is a messy one! But surely this is not the only example of such an intersection out there -- MySQL itself seems to have a ton of official and unofficial companies attached to it. So, just growing pains?? Cheers, Cab Vinton, Director Sanbornton Public Library Sanbornton, NH
On Tue, Aug 4, 2009 at 1:56 AM, Joshua Ferraro<jmf@liblime.com> wrote:
Since this has turned into an attack on LibLime I feel I must state for the record that, as far as I know, LibLime is the ONLY vendor that has historically contributed 100% of our code as soon as it was approved by a customer's quality assurance testing. As far as I know, every other vendor in the Koha community intentionally withholds customizations that are only available to their customers, or don't take the time to fully integrate their code into the mainline Koha codebase (understandably so, as this either gives them a competitive edge, or they simply don't have time to contribute it).
I've had contractors who have worked for me, and for other vendors in the community confirm this of nearly all of the active Koha vendors listed on the support page (if that's not the case at your firm, and you feel I'm misrepresenting you, please correct me).
Well, since you ask: yes, I do want to correct you. BibLibre did historically contribute 100% of our code back to the Koha community. And no, we don't intentionally withhold customizations that would be only available to our customers. There used to be an understanding between vendors that as far as possible we stick with the official version of Koha and avoid, again, as far as possible, deploying customized versions. I want to get back to the minutes of this meeting themselves. Even though there's no talk in there of violating in any way the letter of the license, and even though your email here emphasizes that it's basically "business as usual, you know, a little customization, all vendors do that", I think the spirit of the meeting seems to have been very different. If I may quote from the central section of the minutes : "Charles - i'm a low level player but what he sees is a .com organization talking to a bunch of .edu organizations with different philosophies. Where/when does this mean a split in the product. Josh - 1. that's already happened . Koha by LibLime different already than what others delivered. 2. getting considerable pressure by sponsored developments to embargoing the code. 3. LL cannot change the philosophy to contribute to the community. Need to have a timed release that gives us a strategic advantage. Nora - this is very upsetting and disconcerting to us. That's not why we joined on. Josh - we would still give you all the community stuff Becky - but that breaks the value of open source Rob - the conditions have changed in being able to support the model. The user community has to answer why are we uncomfortable sharing and how the community is having adverse effect on why we got together in the first place. Vicky - would like to explore more positive ways for getting LL funding rather than break the community model of Koha. Josh - not making it not opensource - but we will hold it back." If I can sum that up, it seems to me that: * Josh considers that "a split in the product" has "already happened": we have a fork, we just didn't know it. Can you confirm this? * Some of LL's customers around the table were upset by this and stressed that it all "breaks the value of open source": the letter of the GPL is respected all right; the spirit seems gone. * You, Josh, stated quite clearly, according to the minutes, that you expected LL to retain control of the code base, because "the release manager has final say and if we lose that capability then what if our customers are not served by the product". We could say the same thing, and Catalyst, and every single vendor: if you don't accept the premise that someone else can be the R. Manager, you simply cannot have an open source community. If we follow your line of reasoning, there'd be as many Koha as there is vendors, and there'd never have been an OS ILS in the 1st place : we'd be called ExLibris France and you'd be called SirsiDynix Ohio, or something of the sort. OSS works when developers and vendors in general cooperate: J. Wagner from PTFS entering enhancements requests in bugs.koha.org yesterday, indicating intended developement by PTFS is certainly how things are intended to work. And by the way, the current R. Manager is not a LibLime employee, Galen having started a new job with another company just this week. * can you commit to Galen staying on as the R. Manager for 3.2 and to someone else outside of Liblime potentially fullfilling that role after that? * is it possible that the internal debate which the minutes of this meeting highlights among LL customers, about the "spirit of Open Source and community involvement" also existed within LibLime and played a part in the departure of several employees recently, or not at all? Cheers, Nicolas -- Nicolas Morin Mobile: +33(0)633 19 11 36 http://www.biblibre.com
This has been a very interesting thread and I thank the original poster for sharing this information. Nicolas brought up some critical issues in this e-mail below and I am sure I am not alone in being interested in a response from Joshua Ferraro or other LibLime representative. Perhaps I missed a response, but if one has not been posted, please consider doing so. Kind regards, Rich Boulet -----Original Message----- From: koha-bounces@lists.katipo.co.nz [mailto:koha-bounces@lists.katipo.co.nz] On Behalf Of Nicolas Morin Sent: Tuesday, August 04, 2009 5:08 AM To: Joshua Ferraro Cc: koha@lists.katipo.co.nz; Joann Ransom Subject: Re: [Koha] Support for Koha On Tue, Aug 4, 2009 at 1:56 AM, Joshua Ferraro<jmf@liblime.com> wrote:
Since this has turned into an attack on LibLime I feel I must state for the record that, as far as I know, LibLime is the ONLY vendor that has historically contributed 100% of our code as soon as it was approved by a customer's quality assurance testing. As far as I know, every other vendor in the Koha community intentionally withholds customizations that are only available to their customers, or don't take the time to fully integrate their code into the mainline Koha codebase (understandably so, as this either gives them a competitive edge, or they simply don't have time to contribute it).
I've had contractors who have worked for me, and for other vendors in the community confirm this of nearly all of the active Koha vendors listed on the support page (if that's not the case at your firm, and you feel I'm misrepresenting you, please correct me).
Well, since you ask: yes, I do want to correct you. BibLibre did historically contribute 100% of our code back to the Koha community. And no, we don't intentionally withhold customizations that would be only available to our customers. There used to be an understanding between vendors that as far as possible we stick with the official version of Koha and avoid, again, as far as possible, deploying customized versions. I want to get back to the minutes of this meeting themselves. Even though there's no talk in there of violating in any way the letter of the license, and even though your email here emphasizes that it's basically "business as usual, you know, a little customization, all vendors do that", I think the spirit of the meeting seems to have been very different. If I may quote from the central section of the minutes : "Charles - i'm a low level player but what he sees is a .com organization talking to a bunch of .edu organizations with different philosophies. Where/when does this mean a split in the product. Josh - 1. that's already happened . Koha by LibLime different already than what others delivered. 2. getting considerable pressure by sponsored developments to embargoing the code. 3. LL cannot change the philosophy to contribute to the community. Need to have a timed release that gives us a strategic advantage. Nora - this is very upsetting and disconcerting to us. That's not why we joined on. Josh - we would still give you all the community stuff Becky - but that breaks the value of open source Rob - the conditions have changed in being able to support the model. The user community has to answer why are we uncomfortable sharing and how the community is having adverse effect on why we got together in the first place. Vicky - would like to explore more positive ways for getting LL funding rather than break the community model of Koha. Josh - not making it not opensource - but we will hold it back." If I can sum that up, it seems to me that: * Josh considers that "a split in the product" has "already happened": we have a fork, we just didn't know it. Can you confirm this? * Some of LL's customers around the table were upset by this and stressed that it all "breaks the value of open source": the letter of the GPL is respected all right; the spirit seems gone. * You, Josh, stated quite clearly, according to the minutes, that you expected LL to retain control of the code base, because "the release manager has final say and if we lose that capability then what if our customers are not served by the product". We could say the same thing, and Catalyst, and every single vendor: if you don't accept the premise that someone else can be the R. Manager, you simply cannot have an open source community. If we follow your line of reasoning, there'd be as many Koha as there is vendors, and there'd never have been an OS ILS in the 1st place : we'd be called ExLibris France and you'd be called SirsiDynix Ohio, or something of the sort. OSS works when developers and vendors in general cooperate: J. Wagner from PTFS entering enhancements requests in bugs.koha.org yesterday, indicating intended developement by PTFS is certainly how things are intended to work. And by the way, the current R. Manager is not a LibLime employee, Galen having started a new job with another company just this week. * can you commit to Galen staying on as the R. Manager for 3.2 and to someone else outside of Liblime potentially fullfilling that role after that? * is it possible that the internal debate which the minutes of this meeting highlights among LL customers, about the "spirit of Open Source and community involvement" also existed within LibLime and played a part in the departure of several employees recently, or not at all? Cheers, Nicolas -- Nicolas Morin Mobile: +33(0)633 19 11 36 http://www.biblibre.com _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Joshua Ferraro <jmf@liblime.com> wrote: [...]
Since this has turned into an attack on LibLime I feel I must state for the record that, as far as I know, LibLime is the ONLY vendor that has historically contributed 100% of our code as soon as it was approved by a customer's quality assurance testing.
Probably that's correct because I think several vendors are publishing 100% of their code as soon as it gets past their own QA! I think software.coop is the only Koha vendor whose governing rules commit us "to inform the general public - particularly young people and opinion leaders - about the nature and benefits" of Koha's development model; and "work for the sustainable development" of our communities. Yes, that's really in our company mission, as submitted to our national registration bodies. In short, we're a good cooperative. In our last evaluation (2008), we were achieving 69% of these goals and we're improving each year.
As far as I know, every other vendor in the Koha community intentionally withholds customizations that are only available to their customers, or don't take the time to fully integrate their code into the mainline Koha codebase (understandably so, as this either gives them a competitive edge, or they simply don't have time to contribute it).
Well, software.coop forked 3.0 many moons ago because we made the mistake of promising the announced 3.0 release date plus a few months slack to a customer, so we needed to stabilise it quickly and disagreed on some principles. We've been fairly open about that and we will reconcile that fork. It looks like the features will merge into 3.2 and not 3.0 now. Even though it's not on the mainline, the code is normally available, although we've had a few services die on us and not really publicised it - so now we plan to introduce git.software.coop for public hosting but I don't know when we'll get resources for that. There's also some development code which isn't public because early drafts contain authentication details and things like that which we can't publish, but it's normally described in enhancement bug reports on bugs.koha.org - unlike a vendor whose apparently-similar work we only learnt about when someone tweeted from their conference sessions!
[...] So, companies who host Koha in a software as a service environment are not obligated to redistribute their code to the community (which is why so many Koha vendors are able to withhold their code).
Yes, I feel anyone commissioning Koha hosting should probably add a clause that requires they get a copy of the exact version used in the hosting and access to all their data and configuration files on demand, so they can host it on their own server if they want. Maybe we should add a "download all" link in the Tools section and mention it in the official manual? If that's missing/disabled, users will know to start plotting an escape. [...]
Also, for the record, as requested by LibLime's customers, the LibLime Users's Group list is a closed list, so messages sent to that list should NOT be forwarded to the general Koha list, or anywhere else.
Yes, that's not good. On lists I run, I change the standard footer to something which mentions restrictions like that, but it's hard to put these back in private once published. Best wishes, -- MJ Ray (slef) LMS developer and webmaster at | software www.software.coop http://mjr.towers.org.uk | .... co IMO only: see http://mjr.towers.org.uk/email.html | .... op
MJ wrote:
Yes, I feel anyone commissioning Koha hosting should probably add a clause that requires they get a copy of the exact version used in the hosting and access to all their data and configuration files on demand, so they can host it on their own server if they want. Maybe we should add a "download all" link in the Tools section and mention it in the official manual? If that's missing/disabled, users will know to start plotting an escape.
Wouldn't this be a good use for the AGPL? Have any notable projects switched to the Affero GPL license? Kyle http://www.kylehall.info Information Technology Crawford County Federated Library System ( http://www.ccfls.org ) On Wed, Aug 5, 2009 at 8:43 AM, MJ Ray<mjr@phonecoop.coop> wrote:
Joshua Ferraro <jmf@liblime.com> wrote: [...]
Since this has turned into an attack on LibLime I feel I must state for the record that, as far as I know, LibLime is the ONLY vendor that has historically contributed 100% of our code as soon as it was approved by a customer's quality assurance testing.
Probably that's correct because I think several vendors are publishing 100% of their code as soon as it gets past their own QA!
I think software.coop is the only Koha vendor whose governing rules commit us "to inform the general public - particularly young people and opinion leaders - about the nature and benefits" of Koha's development model; and "work for the sustainable development" of our communities. Yes, that's really in our company mission, as submitted to our national registration bodies. In short, we're a good cooperative. In our last evaluation (2008), we were achieving 69% of these goals and we're improving each year.
As far as I know, every other vendor in the Koha community intentionally withholds customizations that are only available to their customers, or don't take the time to fully integrate their code into the mainline Koha codebase (understandably so, as this either gives them a competitive edge, or they simply don't have time to contribute it).
Well, software.coop forked 3.0 many moons ago because we made the mistake of promising the announced 3.0 release date plus a few months slack to a customer, so we needed to stabilise it quickly and disagreed on some principles. We've been fairly open about that and we will reconcile that fork. It looks like the features will merge into 3.2 and not 3.0 now.
Even though it's not on the mainline, the code is normally available, although we've had a few services die on us and not really publicised it - so now we plan to introduce git.software.coop for public hosting but I don't know when we'll get resources for that.
There's also some development code which isn't public because early drafts contain authentication details and things like that which we can't publish, but it's normally described in enhancement bug reports on bugs.koha.org - unlike a vendor whose apparently-similar work we only learnt about when someone tweeted from their conference sessions!
[...] So, companies who host Koha in a software as a service environment are not obligated to redistribute their code to the community (which is why so many Koha vendors are able to withhold their code).
Yes, I feel anyone commissioning Koha hosting should probably add a clause that requires they get a copy of the exact version used in the hosting and access to all their data and configuration files on demand, so they can host it on their own server if they want. Maybe we should add a "download all" link in the Tools section and mention it in the official manual? If that's missing/disabled, users will know to start plotting an escape.
[...]
Also, for the record, as requested by LibLime's customers, the LibLime Users's Group list is a closed list, so messages sent to that list should NOT be forwarded to the general Koha list, or anywhere else.
Yes, that's not good. On lists I run, I change the standard footer to something which mentions restrictions like that, but it's hard to put these back in private once published.
Best wishes, -- MJ Ray (slef) LMS developer and webmaster at | software www.software.coop http://mjr.towers.org.uk | .... co IMO only: see http://mjr.towers.org.uk/email.html | .... op _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
I know - otrs (http://www.otrs.org), an excellent open source ticket system - has released it's latest version on AGPL, specifically to address the "ASP loophole". On 8/5/09, Kyle Hall <kyle.m.hall@gmail.com> wrote:
MJ wrote:
Yes, I feel anyone commissioning Koha hosting should probably add a clause that requires they get a copy of the exact version used in the hosting and access to all their data and configuration files on demand, so they can host it on their own server if they want. Maybe we should add a "download all" link in the Tools section and mention it in the official manual? If that's missing/disabled, users will know to start plotting an escape.
Wouldn't this be a good use for the AGPL? Have any notable projects switched to the Affero GPL license?
Kyle
http://www.kylehall.info Information Technology Crawford County Federated Library System ( http://www.ccfls.org )
On Wed, Aug 5, 2009 at 8:43 AM, MJ Ray<mjr@phonecoop.coop> wrote:
Joshua Ferraro <jmf@liblime.com> wrote: [...]
Since this has turned into an attack on LibLime I feel I must state for the record that, as far as I know, LibLime is the ONLY vendor that has historically contributed 100% of our code as soon as it was approved by a customer's quality assurance testing.
Probably that's correct because I think several vendors are publishing 100% of their code as soon as it gets past their own QA!
I think software.coop is the only Koha vendor whose governing rules commit us "to inform the general public - particularly young people and opinion leaders - about the nature and benefits" of Koha's development model; and "work for the sustainable development" of our communities. Yes, that's really in our company mission, as submitted to our national registration bodies. In short, we're a good cooperative. In our last evaluation (2008), we were achieving 69% of these goals and we're improving each year.
As far as I know, every other vendor in the Koha community intentionally withholds customizations that are only available to their customers, or don't take the time to fully integrate their code into the mainline Koha codebase (understandably so, as this either gives them a competitive edge, or they simply don't have time to contribute it).
Well, software.coop forked 3.0 many moons ago because we made the mistake of promising the announced 3.0 release date plus a few months slack to a customer, so we needed to stabilise it quickly and disagreed on some principles. We've been fairly open about that and we will reconcile that fork. It looks like the features will merge into 3.2 and not 3.0 now.
Even though it's not on the mainline, the code is normally available, although we've had a few services die on us and not really publicised it - so now we plan to introduce git.software.coop for public hosting but I don't know when we'll get resources for that.
There's also some development code which isn't public because early drafts contain authentication details and things like that which we can't publish, but it's normally described in enhancement bug reports on bugs.koha.org - unlike a vendor whose apparently-similar work we only learnt about when someone tweeted from their conference sessions!
[...] So, companies who host Koha in a software as a service environment are not obligated to redistribute their code to the community (which is why so many Koha vendors are able to withhold their code).
Yes, I feel anyone commissioning Koha hosting should probably add a clause that requires they get a copy of the exact version used in the hosting and access to all their data and configuration files on demand, so they can host it on their own server if they want. Maybe we should add a "download all" link in the Tools section and mention it in the official manual? If that's missing/disabled, users will know to start plotting an escape.
[...]
Also, for the record, as requested by LibLime's customers, the LibLime Users's Group list is a closed list, so messages sent to that list should NOT be forwarded to the general Koha list, or anywhere else.
Yes, that's not good. On lists I run, I change the standard footer to something which mentions restrictions like that, but it's hard to put these back in private once published.
Best wishes, -- MJ Ray (slef) LMS developer and webmaster at | software www.software.coop http://mjr.towers.org.uk | .... co IMO only: see http://mjr.towers.org.uk/email.html | .... op _______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
Kyle Hall <kyle.m.hall@gmail.com> wrote:
MJ wrote:
Yes, I feel anyone commissioning Koha hosting should probably add a clause that requires they get a copy of the exact version used in the hosting and access to all their data and configuration files on demand, so they can host it on their own server if they want. Maybe we should add a "download all" link in the Tools section and mention it in the official manual? If that's missing/disabled, users will know to start plotting an escape.
Wouldn't this be a good use for the AGPL? Have any notable projects switched to the Affero GPL license?
Some projects have switched to the Affero GPL license, but I feel it's not even clear whether the Affero GPL is a free software licence without additional permissions from copyright holders that pointing to the mainline repositories constitutes compliance; and that rate-limiting that download is OK. Having to offer the complete thing as a download from your servers to all users (even vexatious ones) seems like it would be an unacceptable extra burden on already cash-strapped libraries. Also, if I remember correctly, the Affero GPL doesn't require that you can backup/restore all your data easily either, so there would still be ways for hosting providers to lock in libraries. To me, the underlying flaw in the Affero GPL is the idea that licensors can "ensure cooperation" (AGPLv3 first sentence) whereas "Voluntary and Open Membership" is the first cooperative principle. Forced collaboration is coercion, not cooperation. Cooperation is voluntary and GPL enables cooperation - now it's up to each of us to choose whether we ask for it. Hope that explains, -- MJ Ray (slef) LMS developer and webmaster at | software www.software.coop http://mjr.towers.org.uk | .... co IMO only: see http://mjr.towers.org.uk/email.html | .... op
participants (11)
-
C MC -
Cab Vinton -
Chris Cormack -
Joann Ransom -
Joe Atzberger -
Joshua Ferraro -
Kyle Hall -
MJ Ray -
Nicolas Morin -
Rich Boulet -
savitra sirohi