[Koha] Support for Koha

Tue Aug 4 11:56:41 NZST 2009

On Mon, Aug 3, 2009 at 7:19 PM, Joann Ransom<jransom at 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 at scls.lib.wi.us <mailto:vtl at scls.lib.wi.us>>
>> Date: Thu, Jul 30, 2009 at 9:43 AM
>> Subject: [LibLime-Users] LibLime Users Meeting at ALA
>> To: liblime-users at lists.liblime.com
>> <mailto:liblime-users at 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 at liblime.com
>> <mailto:jmf at liblime.com>> wrote:
>>
>> --
>> Vicki Teal Lovely
>>
>> vtl at scls.lib.wi.us <mailto:vtl at 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 at lists.liblime.com <mailto:LibLime-Users at lists.liblime.com>
>> http://lists.liblime.com/cgi-bin/mailman/listinfo/liblime-users
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Koha mailing list
>> Koha at lists.katipo.co.nz
>> http://lists.katipo.co.nz/mailman/listinfo/koha
>>
> _______________________________________________
> Koha mailing list
> Koha at 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 at liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS