Emilda and Koha: how to choose between them?
Hi folks, (Apologies in advance for the HTML mail, but i couldn't find a better way to represent the table below...) I've been evaluating implementing a couple of small libraries (my church and home, both around 1000 volumes) on Emilda and Koha, and i'd be interested in comments from people about their relative strengths and weaknesses. I'm coming from the perspective of a K-12 school IT manager with a Unix background. I don't know much about library cataloguing (although i'm learning), and MARC is almost incomprehensible to me (as it is to all of the librarians i know). :-) I'd really love to convert my school (about 80,000 resources) from a proprietary system to Koha, and i'm using these libraries as guinea pigs. However, my call is not final at school: there are a number of other staff to convince. The merits of free software would have to be pretty strong for us to only save around AU$1000/year (the maintenance contract on our existing library system), not to mention that there's no local phone support. Neither Koha nor Emilda seems to have the features to challenge the more school-oriented library systems yet. Here are my perceptions so far: Product Pros Cons Emilda * Very easy to install on Debian * Z39.50 cataloguing is easy to set up and robust * Simple interface * Easy to hack on (PHP-based) * Exposes a lot of MARC & Yaz; adding search and cataloguing fields requires advanced skills * Developer/user communities not so active (user mailing list about 1/10th the traffic of Koha's) * Requires login to self-loan and -return Koha * Nice features in interface (e.g. cover images) * Pretty (the suggested demo sites look awesome!) * Seems to have quite an active developer and user community * Install not so simple - no Debian package; requires messing about with CPAN * Requires separate Z39.50 daemon that, when last i used it (not the current version), broke easily and frequently * Interface is moderately complex (a moderate amount of MARC) * I hate Perl (i know it to a reasonable level of competency, and write scripts in it regularly - i just hate looking at it). Can anyone comment on whether: * Koha has pros for Emilda's cons? (Self-loan and return seems to be one.) * Koha's cons have improved since i last looked at it? Are there any other considerations that i should be looking at? Low maintenance is a priority for me - after i've implemented the systems, i won't have a lot of time to spend on them. Both products seem to fit the bill in this respect, although i haven't tried to restore one from backup yet. ;-) Thanks for listening, Paul <http://paulgear.webhop.net> -- Did you know? Microsoft Internet Explorer and Outlook have a poor track record for security <http://www.kb.cert.org/vuls/id/713878>. Why not try one of the more secure alternatives from <http://mozilla.org>?
I don't know anything about Emilda, but I can see the last release was almost 1 year ago + emilda mailing lists seems very very silent. While Koha is a very active project, with at least 3 companies supporting it. -- Paul POULAIN et Henri Damien LAURENT Consultants indépendants en logiciels libres et bibliothéconomie (http://www.koha-fr.org)
Paul POULAIN wrote:
I don't know anything about Emilda, but I can see the last release was almost 1 year ago + emilda mailing lists seems very very silent.
While Koha is a very active project, with at least 3 companies supporting it.
That's probably the clincher, isn't it? :-) -- Paul <http://paulgear.webhop.net> -- Did you know? Viewing your email in HTML mode makes you more vulnerable to 'phishing' (fraudulent email) and 'spam' (junk email). Find out more about protecting yourself at <http://www.spamhelp.co.uk/2004/05/dont-use-webmail-view-html-spam-emails.html>.
I don't see a reason why koha cannot include shell scripts that would: 1) apt-get install all neccessary debs (including yaz related debs) 2) grab the other neccessary cpan modules from cvs and compile/install them Of course, it would be neccessary to have a seperate shell script for each distro (debian & redhat). Also, is there any reason why we don't just include the source for the cpan modules that we need to compile? That wouldn't cut out a few steps. This would at least semi-automate the most painful part of koha setup. Any opinions on this? Any reasons it would be unfeasable, or at least undesireable? Kyle -- IT Tech Crawford County Federated Library System On 5/18/06, Paul Gear <paul@gear.dyndns.org> wrote:
Paul POULAIN wrote:
I don't know anything about Emilda, but I can see the last release was almost 1 year ago + emilda mailing lists seems very very silent.
While Koha is a very active project, with at least 3 companies supporting it.
That's probably the clincher, isn't it? :-)
-- Paul <http://paulgear.webhop.net> -- Did you know? Viewing your email in HTML mode makes you more vulnerable to 'phishing' (fraudulent email) and 'spam' (junk email). Find out more about protecting yourself at <http://www.spamhelp.co.uk/2004/05/dont-use-webmail-view-html-spam-emails.htm...
.
_______________________________________________ Koha mailing list Koha@lists.katipo.co.nz http://lists.katipo.co.nz/mailman/listinfo/koha
-- IT Tech Crawford County Federated Library System
Paul Gear <paul@gear.dyndns.org> wrote:
Debian has all but one or two of the Perl modules available in the main distribution. It would be nice if those and Koha itself were available from apt-getable sources.
To do this, we need to know which versions of the modules work with Koha (URLs preferred, as IIRC some are not on CPAN), get the modules into debian (I will sponsor if needed - IAADD) and then get Koha packaged and into debian. - Who has a working Koha rel_2_6 or rel_3_0 and will list the module versions? - Who will help make the debs? Kyle Hall <kyle.m.hall@gmail.com>
This would at least semi-automate the most painful part of koha setup. Any opinions on this? Any reasons it would be unfeasable, or at least undesireable?
It wouldn't be packaged or play nice with the package systems, which already solve a lot of the problems. Including the source of modules will leave us making something more like a distribution than an application and the release management is even more complicated. I'm convinced that the best approach for koha installation is to make koha look a lot more like the typical perl modules+scripts packages that you find on CPAN, probably with a collection of data ready to load from the web interface the first time that it is run. The first steps are above. After that, it's some ExtUtils::MakeMaker and some new system parameters pages for loading the sample data.
On Wed, 17 May 2006 20:48:16 +1000 Paul Gear <paul@gear.dyndns.org> wrote:
Hi folks,
Hi Paul, I don't know Emilda, but as a Koha developer, let me answer about your Pros and Cons :-)
* [Emilda cons] Developer/user communities not so active
That's a really bad point in my opinion (see my conclusion below).
* [Koha pros] Pretty (the suggested demo sites look awesome!)
I suppose you've seen Liblime [1] templates. They are not the default template but they are always up to date when new releases are available. The important is that you can easily switch to other templates and even create your own. We've planned to open an online extension manager where anyone will be able to contribute by adding a template. Hopefully, it should open by the end of this month (May 2006).
* [Koha pros] Seems to have quite an active developer and user community
You're right, the developer community is really active and worldwide (mainly USA, France and New-Zealand). I'm sure we could improve the size of the user community by using more user oriented tools (that's another debate).
* [Koha cons] Install not so simple - no Debian package; requires messing about with CPAN
I totally agree, installing Koha is not simple. We have to make an effort to simplify the installation procedure. Nevertheless, in my opinion, Koha will hardly be as simple to install as a Php/MySQL software. Simply because of Perl additionnal modules. Furthermore, with Koha 3.0 will come a new step in the technical installation: zebra server. I think Emilda also uses one (I confirm after visiting Emilda website), so if you've found Emilda installation easy, it means Koha can make zebra installation easy.
* [Koha pros] I hate Perl [...]
Of course Perl is more complexe than PHP. As a PHP and Perl developer, I appreciate the simplicity of PHP and the possibilities of Perl data structure. If the Koha team had to make a technology choice today to build a new application from scratch, I'm not sure Perl would still be used. At the beginning of the project in 1999, when Chris (from Katipo) decided which technology to use, PHP was not as popular as today and Perl was quite the most obvious choice for a web based application. The advantage of Perl versus PHP is CPAN, even with PHP having Pear. In some way, the drawback of Perl is also CPAN, because you need to install many dependencies from CPAN, check the compatibility, be sure the module is maintained. Anyway, the most important is that Perl is a free software oriented programming language. Such as Python, Ruby or PHP (even if PHP is driven by a single private company, in the same way of thinking PostgreSQL is more "free" than MySQL). I would understand the complaint if Koha was written in .Net or Java for example.
Are there any other considerations that i should be looking at? [...]
On a free software project, one of the most important thing to consider is the activity of the project: how many developers, are they active, how open is the project (easy to contribute, features discussed between users and developers to reach the best solution, availability of a roadmap in time and features). I would even say that maturity is less important than the activity (even if Koha is quite mature). With a good activity, you can be sure the project won't be abandonned in a year. [1] http://liblime.com Cheers, -- Pierrick LE GALL INEO media system
Pierrick LE GALL wrote:
...
* [Emilda cons] Developer/user communities not so active
That's a really bad point in my opinion (see my conclusion below).
Agreed - that's why it's in the cons column. ;-)
...
* [Koha cons] Install not so simple - no Debian package; requires messing about with CPAN
I totally agree, installing Koha is not simple. We have to make an effort to simplify the installation procedure. Nevertheless, in my opinion, Koha will hardly be as simple to install as a Php/MySQL software. Simply because of Perl additionnal modules.
Debian has all but one or two of the Perl modules available in the main distribution. It would be nice if those and Koha itself were available from apt-getable sources.
Furthermore, with Koha 3.0 will come a new step in the technical installation: zebra server. I think Emilda also uses one (I confirm after visiting Emilda website), so if you've found Emilda installation easy, it means Koha can make zebra installation easy.
apt-get and a Debian package that just works are what makes Emilda's installation easy. Speaking of zebra, assuming i have my library working with Emilda, how hard would it be to extract everything in my local Zebra server and pump it in as a Koha biblio?
... In some way, the drawback of Perl is also CPAN, because you need to install many dependencies from CPAN, check the compatibility, be sure the module is maintained.
Exactly - i'd much prefer just to install a package and have it work. -- Paul <http://paulgear.webhop.net> -- Did you know? It is illegal to use your copy of Microsoft Office on multiple computers without multiple licenses. Why not try the free alternative OpenOffice.org? <http://www.openoffice.org>
participants (5)
-
Kyle Hall -
MJ Ray -
Paul Gear -
Paul POULAIN -
Pierrick LE GALL