[Koha] LibLime Enterprise Koha Q&A

[paul POULAIN]

Joshua Ferraro a écrit :
> Hi folks,
>
> We have been working hard on creating a
> business model that will both ensure the success of our customers and
> the long-term viability of Koha.
mmm... strange we (BibLibre) don't need a "BibLibre enterprise Koha" to 
have a sustainable business (we are 9, probably soon 12, so not a 
magnitude from your size)
> We hope that the discussion below in
> Q & A format will help promote better understanding about what we are
> doing, and that we can all move forward, wishing each other well.
>   
OK, let's see and add my comments.
> Q: Is LibLime Enterprise Koha a 'Fork' of Koha?
>
> A: LibLime Enterprise Koha is not a 'fork' of Koha. LibLime Enterprise
> Koha is a set of deployment and development procedures that allows us
> to provide our customers with ongoing updates to Koha on a realistic
> schedule.
>   
It's written here : 
http://www.liblime.com/products/koha/koha-solution-comparison that 
Enterprise Koha has many "liblime enhancements". None of them having 
been published. So, if not a fork, how do you call that !
I must add that, at BibLibre, we use some internal tools to host Koha. 
They let us check any customer installation, add a new install,... but 
this is NOT Koha. This is a good and full use of Linux command line. 
they have no licence as they are 100% internal + not used by our 
customers at all +  not really something "releasable".
Our hosted customers use a 100% standard Koha.
Sometimes, we fix a bug not already included in a release but here how 
we do:
- (Usually Nahuel) fixes the bug and build a patch
- he apply it on our hosted customers
- he send it to patches at koha.org
- on the next release, the patch is in official release, so the "git 
rebase" works fine.

It happend sometimes that the community says "the patch must be 
improved". In this case, a revert & apply of the final accepted patch 
does the job for our customers.
(did I say I really loves git ?)
> This is a change in process for LibLime, but not a change in
> philosophy. Prior to this change, our development process began with
> contribution to the Koha community, often before a set of patches was
> even approved by the sponsoring customer. This real-time contribution
> process created enormous overhead, especially given the volume of
> development that LibLime is involved in (which historically and
> currently represents an order of magnitude more than the entire rest
> of the community combined).
mmm... looking at: http://git.biblibre.com/gitstat/authors.html i'm 
still the 1st committer (add tipaul, Paul Poulain and Paul POULAIN 
patches). It's trues LLers are ranked in the firsts commiters, but it's 
not true that "it represents an order of magnitude more...")
The same results are available from: 
http://www.ohloh.net/p/koha/contributors or 
http://git.koha.org/gitstat/chart.php?chart_parameter1=4&chart_parameter_ver=v3.00.00&submit=1&chart_parameter2_year=2009&chart_parameter2_month=0&submit=1&showcount=10
that shows for 3.0.0 LL is 1st with 2200 patches and BibLibre (add 
koha-fr.org and biblibre.com) 2nd with 759 patches.
For 1.0, 2.0, and 2.2, LL numbers would be much differents (as for 1.0 
LL and BibLibre didn't exists, and for 2.0, you didn't exist, and for 
2.2 you were starting your involvement. (And please, stop saying "before 
3.0, Koha was bugguy". It's simply an insult for all of us that worked 
hard for 1.x and 2.x, and it's just false, there were dozens of 
libraries using it)

I'm impatiently waiting for 3.2 numbers. I think it will be: BibLibre 
50% of the patches, owen, 10%, PTFS 10%, jesse weaver 10%, chris_n 10%, 
others 10%, and LL a few. (sorry if I forget someone, I don't have true 
numbers yet)
> Our new approach moves the contribution
> phase of development to the end of the cycle, which allows us and our
> customers adequate time to vet the functionality and to ensure that it
> integrates seamlessly with the public Koha repository.
>   
which, obviously, makes you be withdrawn from the community. As Nicolas 
said recently: "we're successful because of the community, not despite 
the community".
It's a technical non-sense to pretend to release code once it's totally 
done. It's a big mistake !
Do you seriously think it will be possible to merge your code with our 
code if 6 or more months occurs between the dates?

Just an example: you didn't release "Guided and saved reports 
organization and parameters". That's something the community want, and 
BibLibre could probably develop soon and quickly (we wrote the RFC on 
wiki.koha.org many months ago). How would you deal with this? The 
community version would have something, you would have another one. It's 
a dead end for you josh ! you won't be able to sustain the community 
improvements in your forked version.

I know you won't believe me, but let's have a meeting in 2 years to see 
who was right.
You can be sure i'll say and say again everywhere it's a technical 
non-sense and dead-end.
> Q: Has LibLime withdrawn from the Koha community?
>
> A: LibLime has not withdrawn, and does not intend to withdraw, from
> the Koha community. LibLime has invested significant resources into
> Koha development and community infrastructure and will continue to do
> so.
You recently loose all your employees involved in the community: Galen 
Charlton, Nicoles Engard, Joe Atzberger. I should add (but she weren't 
involved in the community) Debra Denault.
So, how do you plan to stay involved? Who will be involved?
> LibLime will publish our LibLime Enterprise Koha enhancements. The
> integration process with the main Koha code repository will be a
> seamless one.
as everybody: give the git repo! should need less than one hour of work.

I want to add something: I don't have access to http://www.koha.org as 
writter, but  we should update the homepage and the demo site links.
The official demos sites should be http://demo.koha.org (in france it's 
demo.koha-fr.org, even if it's hosted by BibLibre), and demo OFFICIAL 
version, not your LEK.
> We currently support dozens of libraries running on
> official Koha versions on their own servers and it is critical to
> their success that they benefit from the LibLime customer-sponsored
> contributions.
>   
Critical to their success? But I predict a failure and a lot of pains to 
anyone choosing LEK. What is critical to the success for a library is to 
stay vendor independant. With LEK, the libraries won't be !
> Q: Is LibLime Enterprise Koha truly open source both in the letter and
> spirit of the movement?
>
> A: Our announcements are clear on this issue. From the press release
> "Just to make one thing crystal clear: All of LibLime's development
> efforts will be available to the library community under an
> open-source license," ... "These are process changes, not
> philosophical changes. As the leader in open-source solutions for
> libraries, LibLime is 100% committed to the open-source movement."
>
> Q: Why has LibLime chosen to deploy LibLime Enterprise Koha as a
> Software as a Service offering only?
>
> A: Our new cloud-computing platform makes the process of developing,
> upgrading and maintaining Koha a seamless and fully-automated process.
> We have not yet developed the mechanism for managing remote Koha
> installations outside of our platform.  The requirements for keeping
> these off-platform installations in sync with the rest of our install
> base is not feasible. We are 100% committed to continuing to upgrade
> our Appliance customers(non-hosted) and to keep them in step with the
> latest community-released versions of Koha.
>   
GPL don't require to publish the code for a hosted software. And your 
tools require to release LEK only hosted ! Thus, you can not publish 
your code and it's legal ! How lucky you are (irony) !
> Thanks for your understanding.
>   
Yes, I think I understand you. But i'm not happy with what I understand :(

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