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

[Nicole Engard]

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.

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.

---

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