[Koha] [Koha-devel] Pay for Support - a Suggestion

Mon May 11 10:48:25 NZST 2009

hi
> I think this sounds extremely fair - but I think we need a bit of an
> explanation for why companies are listed as such.  While the community
> will understand the ordering - people who are new to open source often
> have trouble understanding the roles we assign and what that means to
> the community.
>
>   
Whichever way we list  we should add the info to the "how to get a 
listing" page so that new vendors know what to expect.
> I have been altering my 'Intro to Open Source' talks to include
> community definitions and governance to try and better educate
> librarians - but I can't be all over the world :)
>
> Anyway, my point was that we might want a page explaining the
> community role in open source and the reason the page is ordered as it
> is.   I also agree that most people are going to want to find support
> companies based on where their libraries are located.
>   
Yep sounds like a good idea. It could even be that by date in the region 
works - I just think that you can't really "scan" more than about 5 
companies very easily, so we'll need some other way to break them up 
into easier to digest chunks.

Cheers
Rachel
> ---
>
> Nicole C. Engard
> Open Source Evangelist, LibLime
> (888) Koha ILS (564-2457) ext. 714
> nce at liblime.com
> AIM/Y!/Skype: nengard
>
> http://liblime.com
> http://blogs.liblime.com/open-sesame/
>
>
>
> 2009/5/9 Rachel Hamilton-Williams <rachel at katipo.co.nz>:
>   
>> HI All,
>>
>> After some thought,  I have a suggestion for how to order the the listings
>> on the pay for page which I hope is both fair,  accurate, has longevity, and
>> is useful to the people visiting the page for whom we're providing the info.
>>
>> In the past we've ordered by region and we've ordered alphabetically. At the
>> moment the suggestion is to order by date joined and I don't think that's a
>> good idea (see below for why).
>>
>> FIRST 3-4 PLACES
>>
>> I'd like to propose that the first "3" positions (possibly more but no more
>> than 4), be ordered by current release manager position held in the
>> community, and that after that, depending on how many listings we have, they
>> be ordered by region & alphabetically.
>>
>> I'd like to see the first position on the list be given to the current
>> release manager's company (Lilime ATM). I think that the job of current
>> release manager is huge, and that the company who is currently providing the
>> resources/employment of the release manager deserves all the support and
>> credit we can give, even if they joined yesterday! I agree with Josh that
>> there can seem like not much benefit to being the release manager (or being
>> their boss!), and so this seems to me like a "no brainer". ALSO if I was a
>> library wanting to get some development done then that's the first thing I
>> would want to know, and lets face it, we want to encourage those libraries
>> who DO want development done.
>>
>> The second position on the list would be given to the current release
>> maintainer- ie the release manager for the current stable release (Bib Libre
>> ATM). Again, I think this is a big job, they are still doing a lot of
>> patching, answering a lot of questions  on lists and generally putting in a
>> goodly amount of time and effort getting the current release more stable,
>> mostly I'm sure not directly funded. Again I think that supporting the
>> company that is providing the resources for someone to do this job is the
>> least we can do. It again would mean that a library was "buying into" the
>> idea of supporting the current stable release.
>>
>> The third & fourth positions on the list could be to either the immediate
>> past release maintainer (in our case v 2.x - assuming they are a different
>> company), or the next company providing the most tangible support to the
>> community.
>>
>> I think however that we stop this system after the top 3-4 positions,
>> because it is less useful after that. It may be that when there is a KSF (or
>> similar) there are some other positions which because of the amount of work
>> they entail, justify giving this same privileged to their supporting company
>> in which case we can extend it, and have clear rules around it too.
>>
>> I quite like the idea of the immediate past release managers being listed
>> (ie if they have stopped being current and aren't funding another release
>> themselves), because again being release manager is such a big job, I think
>> they deserve recognition beyond their "active term" - and it kinda means
>> they get a guaranteed "cash in" time for all that hard work, even if they
>> need to pass the torch to someone else for the next release and concentrate
>> or just building their own business.
>>
>>
>> REST OF THE LIST
>>
>> THEN thinking about our actual website users, I imagine that what they
>> mostly want is to see who supports their area, so I'd like to see the list
>> split into countries or regions, ordered alphabetically, and with the
>> vendors listed alphabetically within them, including info on contributions,
>> positions held etc, if they are on/members of a KSF or similar. It may be
>> that we get big enough it's worth having the company who supports or is
>> principle sponsor of the local  usergroup get first position in that
>> grouping - but that's a bit down the track.
>>
>> WHY - well I think it's easier to read and understand, and to re-find a
>> company that way.
>>
>> It will also make it easier to split up the list into "sane" chunks if it
>> gets to  big for one "page". Ie it's pretty easy to have a North America
>> page, a South America page, a European Page, An African page, an
>> Australasian page etc in the future, and will make more sense to the
>> libraries trying to use it I think that having a "started in 2005" page.
>>
>> WHY NOT BY DATE
>>
>> I don't think that date joined is the best way to actually indicate who is a
>> good company (or person) to deal with, and date joined is no inherent
>> indicator of current involvement in a release, or even that the company
>> would be a good choice for getting the current release installed &
>> supported.
>>
>> Katipo is a prime example of why not list by date (Even before selling to
>> Liblime), we had not funded a release manager for a few years, and hadn't as
>> a company been able to afford much official involvement in the project, even
>> though individuals still participated. I don't think that it would be fair
>> particularly, for us to be top of a page when others were doing so much more
>> (and indeed we listed alphabetically in part to avoid that temptation).
>>
>> While at the moment, the longest involved (listed) companies are at the top
>> of the page, I would would like to see us have a policy that effectively
>> achieves the same thing because I think those companies should be at the top
>> of the listings, but is "defensible", and understandable for both libraries
>> and vendors, and that allows for other worthy companies in years to come to
>> also get a spot in the sun if they put in the hard yards like these guys
>> have.
>>
>> Cheers
>> Rachel
>>
>> --
>> -----------------------------
>> Rachel Hamilton-Williams
>> General Manager
>> Katipo Communications Ltd
>>
>> Phone:  +64-4-934 1285
>> Mobile: 021 389 128
>> E-mail: rachel at katipo.co.nz
>> Web:    www.katipo.co.nz
>>
>> _______________________________________________
>> Koha-devel mailing list
>> Koha-devel at lists.koha.org
>> http://lists.koha.org/mailman/listinfo/koha-devel
>>
>>
>>     
> _______________________________________________
> Koha mailing list
> Koha at lists.katipo.co.nz
> http://lists.katipo.co.nz/mailman/listinfo/koha
>   

-- 
-----------------------------
Rachel Hamilton-Williams
General Manager
Katipo Communications Ltd

Phone:  +64-4-934 1285
Mobile: 021 389 128
E-mail: rachel at katipo.co.nz
Web:    www.katipo.co.nz

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.katipo.co.nz/pipermail/koha/attachments/20090511/f262c7ba/attachment-0001.htm