[Koha] Support for Koha

[Nicolas Morin]

On Tue, Aug 4, 2009 at 1:56 AM, Joshua Ferraro<jmf at 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