At 07:17 AM 6/1/2013 -0700, BWS Johnson wrote:
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.
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>
_______________________________________________
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/
