[Koha-devel] KOHA version 3.0, my question is about the advantages of KOHA 4

[Paul Poulain]

Le 06/06/2011 18:05, Clay Fouts a écrit :
> Each vendor has their own (sometimes very large) customizations that
> they may or may not port back into community code. The community RM
> may or may not accept these back ports even if effort is made to
> rebase them. Please point to the line distinguishing "Koha" from "not
> Koha".
Well, I think we are mixing 2 things :
* local & specific customizations
* fork

a local and specific customization: it occur very often. For example,
one of our customer has very long barcodes, and the barcode length in
the database is not enough for them. it's specific to the customer, and
has nothing to do with a public version. Sometimes, it's not that small
(even if it's local). For example, for Aix-Marseille universities, we
changed the circulation (check-out) workflow to query a NFC reader&
database. The NFC card & database is responsible to say if a card is
valid and fill the members table in Koha database. This is OpenSource
(GPL), available on our public git repo, but won't be submitted to the
community, it's useless unless you've this exact technology. I agree it
can be worth for a library using the same NFC technology and we could
have announced what we made more widely. Our fault, nobody's perfect
(announcement : if you've a 'horoquartz' NFC technology, you can drop me
a mail ;-) )

a fork. Do we have a fork ? Frankly, yes, but 1- we didn't wanted this
to happen, 2- we do all what we can to fix this (yes we consider it's a
"bug"). Reminder about the history : Koha 3.2 has been delayed due to
events we all know here (for newbies, see :
http://lists.katipo.co.nz/pipermail/koha/2011-February/027657.html),
thus many feature we have developed have needed too much time to reach
master (and had to be splitted/merged/...)

I'm on my way to write a mail on our blog to detail how it happens, why
we consider it a bug (and want to fix it), and what's the strategy to
avoid it to happen again.
In a few word:
* we deploy only community version
* if you sponsor a feature 2 options : you sponsor and use it live when
it's in master, you sponsor, go live immediately. BUT if it's not
included in master, then you'll have either to choose to switch back to
community version (and forget you stuff), wait until it's in master,
sign a specific contract for support from BibLibre (or someone else) to
have your nice-feature-not-in-master rebased regularly vs master.
* there are only a few things in "3.2 biblibre" that are not in 3.4, and
everything will be in 3.6.

> Is BibLibre's fork Koha? They have substantial, potentially
> irreconcilable differences that appear not to be destined for the
> community base and their extremely patient efforts to point this out
> and seek solution are met with little more than a dismissive that
> "well, that's your problem." Who is or isn't cooperating this case?
Well, you're not completely wrong. I'm sometimes quite upset by
"community". And I'm sure "community" is sometimes upset by me too ;-) .
But I still think it's better to have strong discussions and arguments
than doing our way without "the community".

Hope that explains

-- 
Paul POULAIN
http://www.biblibre.com
Expert en Logiciels Libres pour l'info-doc
Tel : (33) 4 91 81 35 08