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

[Chris Nighswonger]

On Mon, Jun 6, 2011 at 12:05 PM, Clay Fouts <cfouts at liblime.com> wrote:
> 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".

That's easy: the point at which the vendor (whomever they may be)
chooses to fork from Koha. At that point, the software the vendor is
servicing, maintaining, your-term-goes-here, ceases to be Koha. It may
be said to be based upon Koha, but it is not Koha.

> 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?
> Is Software Coop's fork Koha? I understand there are large differences that
> they are not paying to port back into the community base. I even recall
> seeing an announcement that someone was paying ByWater to do the work of
> porting the coop's EDI code back to community. Does this qualify as
> "cooperation"? How is this different from LibLime publishing its code so
> that any library is welcome to pay the vendor of their choosing to back port
> it to community? Would we receive the same praiseful press release if
> ByWater was getting paid to port our large-bib functionality into community
> code?

By definition a fork is not the same as the base from which it was
forked. A given instance of code is only a true fork once there is a
delta between it and the source from which it was cloned. Otherwise it
is a clone rather than a fork. So, by definition any repo,
installation, etc. which has a delta over the main repo is a fork.
Since we live in a world where there must be some objective standard
against which to make accurate comparisons, we must decide on that
standard. In the Koha community that standard has long been the code
base in the main repo. So every fork is by definition only as nearly
"Koha" as it conforms to that standard. Thus, the larger the delta
between the fork and the main repo, the less the fork can be said to
be "Koha." Its an inverse relationship if that is clearer. At this
point in history, LibLime's fork has a pretty large delta and so is
less "Koha" than other forks.

> The community had their opportunity to fork their project from the company
> that owns the trademark, website, etc. and call their software something
> different, much like LibreOffice and Jenkins chose to do when splitting from
> the Oracle-run projects. But that wasn't the choice that was made, so now we
> all get to have endless arguments and have libraries confused about what is
> or is not Koha.

Liblime only owns the US trademark usage of the name "Koha," and last
I looked, the US does not dictate world trademark law. Koha is much
bigger than LibLime (as much as LibLime might pretend otherwise). So
just as you are free to have your opinion, the Koha community has
their opinion: There is no confusion to those in the know. The Koha
community produces and holds the standard against which all other
things calling themselves Koha are judged.

> At the very least, LibLime when asked tries to be respectful of our
> differences and does not say "well, that's not really Koha."

I'd say that LibLime is simply acceding to the facts of reality when
they refrain from making such claims. They are certainly not doing the
community any favors.

Kind Regards,
Chris