I'd like to reinforce Thomas' point about "disintegrating integrated library systems" (and also correct a small error). NPL now uses BookWhere instead of ITS MARC for cataloging materials -- which actually reinforces Thomas' point, because NPL was able to switch from one cataloging application to another without making changes to Koha. This was possible because both cataloging applications generate MARC records in a standard format (iso2709), and Koha can import those standardized records. However, Koha is only able to do the import after the records have been altered by a customized version of bulkmarcimport.pl. I believe I remember that Paul has already discussed the notion of rewriting the Koha cataloging code so that it generates files of records for import in batches, instead of adding each record as it is created (which is very slow). I think it would be wise to aim for doing this rewrite in such a way that it also makes it easy for a library to use their own cataloging utility. In other words, I suggest that we start the disintegration process with the cataloging module, making it a "stand-alone" application that _can_ be used with Koha, but may also be replaced with another cataloging application of the library's choosing. Stephen Thomas D said:
I agree. Furthermore, there are some significant advocates for disintegrating integrated library systems. An integrated library system seems to discourage adding features and interoperating well with other systems. Modules and major components should be fully modularised so that they can play as well as possible with others. Some ILS vendors already market favoured modules from their ILS systems for using as an add on to another company's ILS. Koha is much more likely to succeed at being installed in libraries if the ILS is not an all or nothing installation. It is not already all or nothing at the largest library using Koha. NPL uses ITS MARC for Windows for cataloguing. Koha needs to be able to do the same for using any module or major component with another ILS. That may go well beyond a direction for 3.0 but should be developed for some future version.
Libraries should be free to choose the best modules from many systems to create their ILS or Library Application Suite. Even if modules work best together with other modules from the same integrated system, they should also work independently perfectly well. As long as common standards to exchange data are used mixing and matching modules between systems should be fine.
Non-proprietary Unix, such as GN/Linux, did not succeed in corporate ILS departments by wholy replacing all computer systems at a corporation. It started by allowing the corporate IT department to fulfil one niche at a time with print servers, webservers, etc. Gradually the confidence developed for non- proprietary Unix to have wider adoption. Non-proprietary Unix has still not been comparably successful in the desktop systems market but that only reinforces the point about the advantages of not having an all or nothing approach to adopting Koha.
Thomas D
Quoting Joshua Ferraro <jmf@liblime.com> :
---------------- Beginning of the original message ------------------
Fantastic ideas Paul! I think you're absolutely right, we need to start thinking in terms of a 'koha suite' with the ILS as just one component in a larger framework. Some of my ideas for things that could be included:
Inventory management Scheduling management Full-text document storage and retrieval (Zebra makes this easy) Computer scheduling (so patrons can sign up for computers, etc.)
These kinds of value-added features will make Koha really stand out compared to other ILS products. More modularization of the code base will make it easier to incorporate new modules. I think we should go for it!
-- Joshua Ferraro VENDOR SERVICES FOR OPEN-SOURCE SOFTWARE President, Technology migration, training, maintenance, support LibLime Featuring Koha Open-Source ILS jmf@liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS
-- Stephen Hedges Skemotah Solutions, USA www.skemotah.com -- shedges@skemotah.com