[Koha] Defining community participation [was: Koha demo links on koha.org]

Kyle Hall kyle.m.hall at gmail.com
Tue Oct 13 07:16:25 NZDT 2009


> Could you tell me why tarball doesn't count?  To me, it looks like the
> code is out there, even if it's not in the format you want it to be.

A tarball is absolutely the very least a body can do to release code
and no violate the GPL. It means that if we want to integrate the LEK
code into Koha, it will require hundreds of man-hours to integrate. If
Liblime were to make available a Git repository, it would change
hundreds to just tens.

I don't buy they 'customer sensitive data' line. If they can strip
customer sensitive data from a tarball of the code, they could do the
same for a Git repository. From my viewpoint, it looks like Liblime is
doing the minimum they can so they can so 'LEK is Open Source!', while
making it as hard as possible for that "Open Source" code to be
useful.

> Here, I'll ask again:  Is git easy to use while you are
> developing code or is it an added step?  If it's an added step, why
> not wait until the work is done?

You have no idea how amazing Git is! It's the most powerful and
amazing tool I have ever used as a programmer. When the discussion of
switching to Git was going on, I was 100% anti-Git ( I was pushing
subversion ). It is not an added step, it removes steps. I'm sure that
using Git has saved hundreds of man-hours across the entire Koha
developer community.

Since it is not an added step, your second question is moot, but I'll
answer it anyway. The longer the wait, the greater the differences
between Koha and LEK become, and this means more work spent on
integration. It's as simple as that.

Kyle

http://www.kylehall.info
Information Technology
Crawford County Federated Library System ( http://www.ccfls.org )




On Mon, Oct 12, 2009 at 1:51 PM, Ben Ide <benide at gmail.com> wrote:
> On Mon, Oct 12, 2009 at 1:26 PM, Owen Leonard <oleonard at myacpl.org> wrote:
>>> So, if LibLime promised to make all their code available after
>>> customer signoff, would this reduce all of this discussion to a
>>> footnote in Koha's history?  Because this promise has been made on
>>> more than one occasion.
>>
>> Define "available." As we've already heard, LibLime has said that they
>> would not open up a public git repo. That means that the Koha
>> community can't interact with their developments in the way they do
>> with everyone else's.
>
> Everyone except for the one's I mentioned (below), you mean.
>
>> As has been pointed out frequently before, making code available by
>> releasing a tarball just doesn't count. That's not participation.
>
> You have pointed that out frequently.  Very frequently.
>
> Could you tell me why tarball doesn't count?  To me, it looks like the
> code is out there, even if it's not in the format you want it to be.
> What are the rules for participation?  Does everyone prefer git?  I've
> read about a few other flavors that people prefer.
>
>>> Actually, with perhaps two exceptions, all the discussion off that
>>> thread can be summed up with "Thanks. Could you use Git, please?"
>>
>> In other words, "Could you return to the kind of participation you
>> were doing just a few months ago?"
>
> Yes, before they took on a new client's requests.  But you know that
> already.  Is this more about impatience in TKC or one company's
> commitment?
>
>>> Let me ask a very basic question, which I think is at the heart of
>>> this matter.  How is LibLime's actions different from those of
>>> software.coop, the work done for the Learning Access Institute, and
>>> HTL?  All have code that, so far as I can tell, have not been released
>>> back to TKC,* despite open source licensing agreements.  What makes
>>> this stink bigger?
>>
>> HLT. Horowhenua Library Trust. http://www.library.org.nz. And neither
>> software.coop or HLT has posted demos of non-public versions of Koha
>> on koha.org. Neither are advertising a non-public version of Koha
>> using the Koha name.
>
> But that's not really the issue, is it?  This is about doing a
> "find/delete" on anything that says "supported by LibLime."
>
>>> Thank you.  But as it's been said before, corporations have the right
>>> to profit and programmers have the right to get paid.
>>
>> It's amazing that we're still having this conversation. Who around
>> here isn't getting paid? All of us, not least of all LibLime, are
>> proof that participation--real participation--in an open source
>> project can be sustainable and profitable.
>
> It is amazing that we are having this conversation.  I thought
> everyone had moved on with their lives until you started this thread.
>
> And for the record, I haven't earned one thin dime off of Koha.  Does
> that make my statements and concerns irrelevant?
>
>>> I have another question that maybe someone can help me with.  I've
>>> been reading a bit about git and it seems like a real pain to use
>>> while you're developing code.
>>
>> It's not. It's beneficial. LibLime knows this very well, as they use
>> the tool every day to support their customers. This is a non-issue for
>> this subject.
>
> I never claimed it wasn't beneficial or made guesses about who knew it
> or not.  Here, I'll ask again:  Is git easy to use while you are
> developing code or is it an added step?  If it's an added step, why
> not wait until the work is done?
>
> Thanks,
> -- Ben
> _______________________________________________
> Koha mailing list
> Koha at lists.katipo.co.nz
> http://lists.katipo.co.nz/mailman/listinfo/koha
>


More information about the Koha mailing list