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

[Brendan A. Gallagher]

Clay - 

Please get your facts straight before you continue with this thread and us other companies names.  Comment in-line.

On Jun 6, 2011, at 9:05 AM, Clay Fouts 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".
> 
> 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?

Software Coop is not paying ByWater Solutions to rebase EDI for Koha.  This is a project that we are pursuing and we are using our own money to fund for our time to rebase this code.  As part of our company we spend the time to rebase code/ submit bugfixes, and pay for our employees to work on community code and documentation (manual) that is not directly sponsored by a customer.  This is all meant for the best interests in the project as a whole.

Hopefully that makes sense - if not, you are welcome to give me a phone call whenever you want.

-Brendan
ByWater Solutions CEO

> 
> 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.
> 
> At the very least, LibLime when asked tries to be respectful of our differences and does not say "well, that's not really Koha."
> 
> Regards,
> Clay
> 
> 
> On Mon, Jun 6, 2011 at 8:17 AM, Chris Nighswonger <cnighswonger at foundations.edu> wrote:
> 2011/6/6 Clay Fouts <cfouts at liblime.com>:
> > We do not in general make an effort to coordinate our work with other code
> > bases, nor attempt to port our code over to them. The source is however
> > available for all to see. Upon release from the sponsoring customer, we
> > publish the source code for anyone to work whichever pieces they want into
> > whatever code base they manage.
> 
> Cutting to the chase, your wordy explanation can be reduced to a one
> word policy: Non-cooperation.
> 
> Wording it that way wastes less of our time on parsing the verbiage.
> 
> Liblime's product is simply *NOT* Koha. Period. End of discussion. And
> I'm not sure we really want what they have at this point anyway.
> 
> Now back to more productive work.
> 
> Kind Regards,
> Chris
> 
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/

-------------- next part --------------
An HTML attachment was scrubbed...
URL: </pipermail/koha-devel/attachments/20110606/368d0caa/attachment-0001.htm>