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

[ccalle]

Estimates

This is a topic which I fully understand what is happening with the
versions, and what I personally favor is changing URL and the business
sense behind that there Koha, Koha we adopt in our University and thanks
to community and (http://koha-community.org/) achieves important
objectives.

I do not think there is another alternative as this community that we
are the programmers who love freedom.

Never fails KOHA (http://koha-community.org/) from Bolivia.

Thanks.


Christian Jhonny Calle Jahuira
TUTOR ELEARNING - UMSA
Consultor Sistemas de Informacion de Bibliotecas de la UMSA
Email: ccalle at umsa.bo
Cel: 73017301

On Tue, 7 Jun 2011 13:34:25 -0700, Clay Fouts <cfouts at liblime.com>
wrote:
> Hello, Paul.
> 
> What you describe here is an insightful analysis followed up with a
> perfectly valid decision that embodies that priorities you've set for
> your business in order to benefit your customers. There is a value in
> seeking to keep in sync with the git.koha-community.org [1] repo, and
> there is value in diverging from it. It's a matter of personal and
> business priorities which path to take, and I respect everyone to make
> that decision for themselves. 
> 
> Cheers,
> Clay
> 
> On Tue, Jun 7, 2011 at 6:38 AM, Paul Poulain  wrote:
>  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
> [3]),
>  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 [4]
>  Expert en Logiciels Libres pour l'info-doc
>  Tel : (33) 4 91 81 35 08
> 
>  _______________________________________________
>  Koha-devel mailing list
>  Koha-devel at lists.koha-community.org [5]
>  http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> [6]
>  website : http://www.koha-community.org/ [7]
>  git : http://git.koha-community.org/ [8]
>  bugs : http://bugs.koha-community.org/ [9]
> 
> 
> 
> Links:
> ------
> [1] http://git.koha-community.org
> [2] mailto:paul.poulain at biblibre.com
> [3]
> http://lists.katipo.co.nz/pipermail/koha/2011-February/027657.html
> [4] http://www.biblibre.com
> [5] mailto:Koha-devel at lists.koha-community.org
> [6]
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> [7] http://www.koha-community.org/
> [8] http://git.koha-community.org/
> [9] http://bugs.koha-community.org/

-- 
Atte

-- 
Christian Jhonny Calle Jahuira
TUTOR ELEARNING - UMSA
Consultor Sistemas de Informacion de Bibliotecas de la UMSA
Email: ccalle at umsa.bo
Cel: 73017301