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

[Ben Ide]

Excellent reply.  Thank you!  You were one of the folks I alluded to
when I mentioned that others preferred something other than Git, so I
count this as a ringing endorsement.

I'm still not sure what the mechanics of Git are, but as soon as I
contribute code I'll understand it better.  (If Koha ever needs
HyperCard programming, I'm your guy.  ;-)

One more question:  Who first mentioned that LibLime plans to release
their code via tarball?

Thanks,
-- Ben

On Mon, Oct 12, 2009 at 2:16 PM, Kyle Hall <kyle.m.hall at gmail.com> wrote:
>> 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
>>
>