At 07:17 AM 6/1/2013 -0700, BWS Johnson wrote:

...

Tarballs, packages, gits (including vendors), stables, latest, bugs and

Salvete! 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.

Agreed -- 100%. My concern is with the "final product", not the means of getting there.

What do you consider instable or insecure in particular?

This thread started questioning the need for QA for plugins, *potentially* insecure. The instability issue is part perception/communication, part superb enthusiasm on the community/development side. But the fact remains that on 14 September 2012, we went live with Koha 3.8.4 which was the "cat's whiskers" just eight months ago. 3.8 is now "old stable", 3.10 is "stable" and 3.12 "development" is advertized (Wiki) equally prominently. And the Wiki continues: "If you're unsure what you want, go for the stable version. If you want to be a bit more conservative, go for the most recent old-stables release. Note that both of these are still very much a work in progress: they won't work perfectly just yet." There is, for a newcomer reading the Wiki, no "working perfectly" LTS (long term stable) release. My *opinion* is that we need (cf Ubuntu) a five year cycle -- 2 years "stable+security", 2 years continuing support, 1 year buffer zone -- this could be seen as maturity in the open-source world.

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.

I truly believe that Koha is no longer a "smaller project", but you make a valid point.

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.

Agreed 100% -- although I have never used the packages.

...

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.

I was somewhat careful not to quote names ;=} -- you could be right in your assumption, but at my age "my memory fails me ..."

Second, OPALS? As in http://www.mediaflex.net/showcase.jsp?record_id=52

Yup. "OPALS, an open source ILS for school libraries and districts developed and supported by Media Flex earned top rankings in Company Satisfaction, Product Support, and Company Loyalty." See <http://www.librarytechnology.org/perceptions2012.pl>

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 respect your opinion (but see Marshall Breeding's survey above.) If I knew more about Opals, I might well agree.

...

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.

Getting Koha recognized as a major player. I'm convinced. I'm keen on persuading other institutions. I'll do my utmost. I just see the lack of a solid LTS release as a difficulty. This thread subject concerns "plugins QA", and my first para mentions [other open-source as] "fairly stable with an established security update capability"; looking at e.g. Firefox plugins, Mozilla says (FAQs) "Unless clearly marked otherwise, add-ons available from this gallery have been checked and approved by Mozilla's team of editors and are safe to install. We recommend that you only install approved add-ons." Mea culpa if I 'pirated' this thread to *stability* rather than *QA*, but they are closely intertwined.

...

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.

I hope (and genuinely believe) that we're not the only two participants here interested in "steering and strategic types of conversations" and also hope that my thoughts on stability (QA, maturity, reputation) might strike chords with others. It's not criticism, perhaps more my dream of the next "small step" for library systems. In my 50+ years of code development, I can honestly say that end-user credibility is very closely related to stability, and that within "stable" the differentiation between security and enhancement must be crystal clear (and separately optional from an upgrade pov.) "It works as promised" is a huge compliment. The old saying "if it doesn't work, use a bigger hammer; if that fails, rtfm" is dubious management. Thanks for your thoughts and best regards, Paul

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 _______________________________________________ Koha-devel mailing list Koha-devel@lists.koha-community.org http://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel website : http://www.koha-community.org/ git : http://git.koha-community.org/ bugs : http://bugs.koha-community.org/

--- Maritime heritage and history, preservation and conservation, research and education through the written word and the arts. <http://NavalMarineArchive.com> and <http://UltraMarine.ca>