Hi All,<div><br></div><div>As some of you know I'm involved as a consultant with both Koha and Evergreen projects. One of the things that is being pursued by King County Library System as part of the IMLS grant they received is the development of an Enhancement Database. The RFP is going to be "on the street" soon. The concept is to create an online venue and set of tools to help people find out what others are doing with development and to find out what they WANT to do so they can chime in or join up in some way. </div>
<div><br></div><div>Whatever is created could certainly be used by either project as it will not be Evergreen centric in any way (except possibly in the way that it relates to the Equinox team's development environment - since we're specifying that the product should be able to export specs to the development team once they've been accepted and funded ...or something). </div>
<div><br></div><div>Anyway, just wanted to alert you to that. I'll post it to this list (if you like) as soon as it is released (the RFP that is).</div><div><br></div><div>Lori<br><br><div class="gmail_quote">On Thu, Jan 21, 2010 at 9:32 AM, Scott Kushner <span dir="ltr"><<a href="mailto:skushner@mtpl.org">skushner@mtpl.org</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Owen, MJ. Et. Al.<br>
<br>
Didn't mean to start a minor controversy amongst the list. Let me<br>
clarify what I meant.<br>
<br>
Where I see developers and users at odds (or, a "disconnect, if you<br>
will), is in the Request for Code Development process.<br>
Right now, we are all operating like little "islands" where each library<br>
goes through a long "planning process" in which each library decides<br>
what features that they absolutely need to see in Koha to operate daily<br>
and meet their patron's needs. Now, much development currently needed,<br>
which is not yet committed, is very redundant, and what I'm trying to<br>
suggest is that we all don't spend (and waste) time trying to re-invent<br>
the same wheel. Also, we can't really know what others are planning<br>
right now for KOHA without communicating to them, before the RFC<br>
process.<br>
<br>
I see KUDOS as a place where libraries can meet and discuss the code<br>
that they are "planning" to sponsor, before submitting to Bugzilla<br>
(brrr..) ,or the Koha Wiki, so code development can be leveraged before<br>
being submitted, thereby making the process more stream-lined and<br>
efficient.<br>
<br>
Am I saying that developer's should be excluded from this process?<br>
Absolutely not.<br>
<br>
Am I saying that a KOHA USERS group is an excellent vehicle for the<br>
USERS to communicate and further leverage the planning process and<br>
development thereby making KOHA better. Absolutely.<br>
<br>
That is my take on the value of a "USERS" group in KOHA.<br>
<br>
If I am wrong, then, have at me....<br>
<font color="#888888"><br>
<br>
Scott Kushner<br>
Information Technologies<br>
Middletown Public Library<br>
</font><div class="im">-----Original Message-----<br>
From: <a href="mailto:koha-bounces@lists.katipo.co.nz">koha-bounces@lists.katipo.co.nz</a><br>
</div><div class="im">[mailto:<a href="mailto:koha-bounces@lists.katipo.co.nz">koha-bounces@lists.katipo.co.nz</a>] On Behalf Of Owen Leonard<br>
Sent: Tuesday, January 19, 2010 7:59 PM<br>
To: <a href="mailto:koha@lists.katipo.co.nz">koha@lists.katipo.co.nz</a><br>
Subject: Re: [Koha] Users and developers (was KUDOS - ALA Proposed<br>
Agenda)<br>
<br>
</div><div><div></div><div class="h5">Okay, get ready for a rant...<br>
<br>
> Sometimes "users" and "developers" are at opposite poles...<br>
<br>
When? I'm a Koha user. And in using Koha I saw that I could make Koha<br>
better, and in time became a Koha developer. There is no Koha<br>
developer out there who is developing Koha features just because they<br>
think it would be cool to do. Koha developers are doing their work<br>
because they *see* a need, in an actual user or an actual library. Or<br>
developers are getting paid by libraries to develop the features the<br>
libraries need.<br>
<br>
Here's when users and developers are at opposite poles:<br>
<br>
- When a company decides to develop a feature that they think will<br>
help sell a product, even though the feature doesn't meet any actual<br>
need<br>
- When a company throttles or cripples a feature in a product because<br>
they want to charge extra for a particular feature<br>
<br>
No self-respecting Koha developer or Koha support company is doing<br>
that kind of stuff. That's why we're here.<br>
<br>
> I think this is more about giving the "users" more of a voice than<br>
they've traditionally had in<br>
> the past, no?<br>
<br>
I honestly don't know where this comes from. The Koha project is just<br>
about as open and accessible as any software project can be. You can<br>
participate on the mailing list, you can submit bug reports yourself,<br>
you can submit your own patches or hire your own programmers to write<br>
code for you. You can talk to Koha developers on IRC almost 24 hours a<br>
day!<br>
<br>
The only way in which one might consider that users need "more of a<br>
voice" is if you think of it in terms of working collectively to<br>
achieve a goal that Koha libraries individually could not. If that's<br>
the intention of that statement then, rant over. I agree 100% that<br>
libraries should be seeking ways to pool their resources ($$) to get<br>
done the things they want done, i.e. hire developers or commission<br>
existing companies to do work for them.<br>
<br>
However, if by "more of a voice" you mean, "If we all get together an<br>
ask for a feature the Koha developers should implement it," then no.<br>
This is open source, but time is money. You can donate your time (as I<br>
do, every day, in code, markup, email, and IRC) or you can donate your<br>
money--in the form of paid development work.<br>
<br>
This doesn't shut anyone out. But yes, there is a bar that you have to<br>
clear. I don't know how else it can work.<br>
<br>
So: Let's get together as users and/or developers and figure out how<br>
we can get some stuff done. Let's put together a structure by which<br>
Koha users can spec out new features and get them funded,<br>
collectively. Let's put together a structure by which Koha users can<br>
communicate with their vendors without fear of exclusion or reprisal.<br>
Let's not talk about a users group breaking down some barrier that<br>
isn't really there--let's talk about strengthening and leveraging the<br>
connection that we *already have!*<br>
<br>
-- Owen<br>
<br>
--<br>
Web Developer<br>
Athens County Public Libraries<br>
<a href="http://www.myacpl.org" target="_blank">http://www.myacpl.org</a><br>
_______________________________________________<br>
Koha mailing list<br>
<a href="mailto:Koha@lists.katipo.co.nz">Koha@lists.katipo.co.nz</a><br>
<a href="http://lists.katipo.co.nz/mailman/listinfo/koha" target="_blank">http://lists.katipo.co.nz/mailman/listinfo/koha</a><br>
<br>
_______________________________________________<br>
Koha mailing list<br>
<a href="mailto:Koha@lists.katipo.co.nz">Koha@lists.katipo.co.nz</a><br>
<a href="http://lists.katipo.co.nz/mailman/listinfo/koha" target="_blank">http://lists.katipo.co.nz/mailman/listinfo/koha</a><br>
</div></div></blockquote></div><br></div>