[Koha] Freight in aquistions?

[Joshua Ferraro]

Hey Brooke,

My perception is that you're coming at this from the perspective of a
library who's downloaded Koha on your own, and who's been active in
the community with respect to documentation and help on the various
mailing lists, right? ie, you haven't signed up for support with a
Koha company, and you haven't contributed or sponsored any code,
right? BTW: I think that's just great, hats off to you for your
continued involvement and community support, it's much appreciated and
the community wouldn't be the same without you and others like you.

However, things get tricky because as valuable as all those activities
you do are, they don't do help motivate Koha developers to change add
or improve code. This isn't the kind of open source community where
we've got a bunch of volunteers contributing code out of the goodness
of their hearts ... over 90% of Koha is done by programmers who work
on Koha as a full time job (or two) to put meals on the table.
Currently, the margins on Koha development are so low, many of us have
to supplement our Koha development work with other services just to
make ends meet.

So from that perspective, the perspective of a starving developer,
what are your thoughts on how we developers can both keep our stomachs
full (not to mention mortgages, etc.), and fulfill the needs of users
like yourself? Some kind of voting mechanism that gives a weight of
voting based on dollars, and a commitment from the development
community to tap that resource for sponsoring voted-upon features?
It's a very interesting problem, and I'd love to hear your thoughts on
how we might solve it.

Cheers,

Josh

On Wed, Dec 17, 2008 at 11:00 AM, Joe Atzberger <ohiocore at gmail.com> wrote:
>
>> Finally, I'd again like to point out that out and out removal of
>> functionality is not a bug solution.
>
> It may not be a solution for the feature, but it is a bug solution *for that
> release version*.
>
>>
>> If it were bugged, then I as a user would like whatever bug (or more
>> likely combination of bugs) it was fixed before something new was added to
>> the core programme.
>
> Easily said, but practically impossible to accomplish.  And surely other
> users would prefer to have their favorite feature integrated into a release
> without waiting for every outstanding bug in unrelated, orphaned features to
> be addressed, especially if they are paying developers to accomplish just
> that.
>
>>
>> If removal is the only option, I don't think it's asking to much to take a
>> poll on this list instead of solely discussing things on the developer's
>> list.
>
> A poll doesn't matter much when there isn't code to back it up.  I think it
> would be counterproductive to conduct a poll that suggests itself as a
> mechanism to accomplish something when in fact it is unrelated to
> accomplishing it.  If the group being polled had a developer they could
> dedicate to the task(s), or even a set number of developer hours, then it
> would be a totally different situation.
>
>>
>> Librarians other than me are very patient. One of my favourite things to
>> relate in terms of new features is the 27 year bookmobile feature
>> implementation. Yes, we're waiting for it. Yes, we've not forgot this year.
>> Do you have it yet? No? When will you have it done? It's been a while...
>
> I have no idea what a 27-year bookmobile feature is, but we have sizable
> libraries using the existing offline circulation code for their bookmobile
> transactions.  I suspect this would work in your case as well.  I hope you
> don't mean that you've been waiting 27 years for an implementation!  (Koha
> of course hasn't been around half that long.)
>
>>
>> The pickle is in telling us something will be done by a certain date and
>> then not meeting that, OR in promising a feature that you never deliver
>> upon, in which case we use our Awesome Powers of Nagging.
>
>
> Heh.  As fearsome as those powers surely are, in my experiments, they are
> not impressive to the perl compiler running our Kohas.  Unfortunately.
>
> I'm not sure what features/dates you are referring to, or who you think
> promised them.  But in general, for a codebase that is moving rather
> quickly, I think the developer community has been reasonably pragmatic in
> its decisions.
>
> --Joe
>
>
> _______________________________________________
> Koha mailing list
> Koha at lists.katipo.co.nz
> http://lists.katipo.co.nz/mailman/listinfo/koha
>
>



-- 
Joshua Ferraro                       SUPPORT FOR OPEN-SOURCE SOFTWARE
CEO                         migration, training, maintenance, support
LibLime                                Featuring Koha Open-Source ILS
jmf at liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS