[Koha] Community Feedback

[Joshua Ferraro]

On Wed, Dec 17, 2008 at 12:23 PM, BWS Johnson
<mhelman at illinoisalumni.org> wrote:
> Salve!
>
>>>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*.
>>
>
>
> I respectfully disagree. It's like a doctor saying that you'll need your leg
> amputated before trying physical therapy.
Sigh ... I can't even count how many ways it's NOT like that.

>>>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.
>>
>
>
> The prevailing attitude in this community prior to arrival of LibLime was
> that features and Libraries would not be orphaned and left high and dry. I
> used to be very proud to go out and speak to others about the quality of the
> programme and the compassion of the community. The more I see the attitude
> that if you're not a developer, we don't care what your opinion is, the less
> likely I am to recommend it to a friend. The Koha release date has nothing
> to do with a custom contract that LibLime promises to a paying customer. A
> solution is easily bundled and shipped out to that client. LibLime's lack of
> planning is not my emergency, nor are their vendor promises.
You seem to be aiming a lot of your frustration at LibLime. I'd argue
that we've done a very good job promoting just the spirit you're
saying the community is known for. I think we've specifically planned
for that, and have aired topics for discussion to plan for just that
type of project. I wonder why you think we have a lack of planning,
from my POV, it's quite the opposite.

> It isn't practically impossible to fix what's broken, it'll just take time.
> It's better to wait longer, schedule things out with a longer lead time, and
> have a better product at the end of the day then to have a Frankenstein's
> monster of features since there's this silly notion that stuff has to be
> done quickly. I fail to see why nagging problems, like acquisitions,
> cataloguing, the installer and spine labels aren't being given a better once
> over between releases to get them user friendly and nearly bug free. There's
> been progress, but there's a lot of traffic on the list for the same errors
> year in and year out. How is this beneficial to anyone? I'm aware that folks
> like MJ are all over QA, and I very much appreciate that. When the roadmap
> is set, just factor more time in. I've seen some of this stuff slated for
> next week or next month with an initial feeling that it would take much
> longer. Why put yourself through that? Better planning will avoid folks
> getting impatient.
This is over on the other thread, where this started, before you
changed threads on me, so I'll paste it in again:

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

-- 
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