[Koha-devel] RFC: Plugins QA

[BWS Johnson]

Salvete!


>Tarballs, packages, gits (including vendors), stables, latest, bugs and
patches, wikis (various), tools, reports, live-DVDs, mailing lists, chat,
maybe more, and now plug-ins?  Could we please look at what the
"open source" world is doing? Apache, SendMail, Perl, PostFix,
FireFox, Debian, Ubuntu, OpenOffice, LibreOffice ... are fairly stable
with an established security update capability. Even Java and MySQL are
simplifying.
>

    I'm all for giving our developers the flexibility to deliver their code in whatever form they have time to wrap it in. I might _like_ them to do things my way, but I'm not paying them, and I never have.

    What do you consider instable or insecure in particular?

    Many of those projects are quite large, so in my light, afford their respective projects the ability to do things that we as a smaller project might not be able to manage.


    Many thanks to Robin and anyone else that helped with the packages. I had whinged for ages that I'd love to just have an apt-get command.   
    


>I had a "rather important" librarian from Quebec drop in, out
of the blue, yesterday to talk about Koha. Her group (37 libraries) had
previously been burned by a trial commercial implementation of Koha (no
need to quote names), so they're using Opals, but "liked the
idea" of Koha. First question: "stability?"
>

    I am stymied by this. Completely, utterly flabbergasted. First, whatever trash LibLime were selling wasn't Koha. Second, OPALS?  As in

http://www.mediaflex.net/showcase.jsp?record_id=52

    One of the questions I posed to my students was "Is OPALS truly open source if you have to beg for the code and a demo?" In terms of feature comparison and breadth of adoption, it's not even close. It's well known I've a soft spot in the granite thing that's meant to be my heart when it comes to Koha, but I freely admit when I think we get beat. That is most certainly not the case with Koha, and I wish them the best of luck getting a consortium up and running in a multilingual capacity with that heap.
    



>I know that a number of you will ... whatever ... Paul's a pain in the
neck, doesn't understand, does his own thing, but the bottom line is that
<http://opac.navalmarinearchive.com/>
is fully functional and is intrinsically Koha. It's (reasonably) secure
(without https) and meets the needs of our users and librarians. It runs
itself with minimal ( < 1 hour/week statistically ) intervention by IT
personnel. 
>

    So what's the problem? I'm truly sorry, but I just don't understand why you're ranting here.



>There are very few institutions that have "happiness" in the
form of unlimited budgets and unlimited IT departments. I'm personally
intrigued by the creativity of the Koha community, so try and follow
what's happening -- which is magnificent -- but doubt that your average
library has the same passion.
>


    I think most of the discussions we have are important, and I really love having the longer term steering and strategic types of conversations. It's been a long time since I had to interact with proprietary vendors, and I don't relish the thought of ever being charged with that again. I think that a lot of the development done at least gives a nod to small libraries. More often than no, folks bend over backwards for small libraries. I get quite prickly if I sense that things *aren't* moving that way. This is a big tent system, there's plenty of room for everyone's individual take. :)


Cheers,
Brooke