Although clearly there is something to be said for building on what
already exists, I also think that a new project is an opportunity to
break away from the traditional ILS design. Although I haven't looked at
Koha and Evergreen in great depth, they seem to me to be open source
versions of the 'traditional' ILS (happy to be corrected) - there's
nothing wrong with this, and clearly this may stimulate some competition
and more innovative thinking in the market place.
So to answer the questions posed by John:
1) Does designing an open source ILS seem like something worth exploring
for academic libraries?
Yes
2) Given the information above about the proposed project, is your
institution interested in:
-- staying informed of our progress?
Yes
-- contributing time and effort to the planning process, even if only
through the first or second workshops?
Possibly
-- possibly being one of the core schools that participates throughout
the full planning and writing process
Probably not
3) If you have any initial feedback on our ideas, we would love to hear
it!
I'm probably as much interested in how the ILS integrates into other
systems as I am in the user interface. Some thoughts:
It should have the option to avoid having it's own locally maintained
database of users - these should be sourced via LDAP or other mechanism
from the institutional directory, Identity Management system or other
relevant database
It should have the option to avoid having it's own locally maintained
authentication mechanism - it should integrate with institutional
authentication supporting a variety of methods
It should have the option to avoid having it's own locally maintained
finance information - this should be achieved through integration with
corporate finance
It should have the option to avoid having it's own procurement system -
this should be achieved through integration with corporate procurement
It should have a data publication platform to push information about the
materials held by the library into many different environments - as RDF,
XML, HTML etc.
It should have well documented APIs for all interactions with other
systems, and preferably support Web Services for many interactions
It should rethink subscriptions management to reflect the fact that
large proportions of library budgets are now spent on subscriptions to
electronic resources
It should be built with support for RFID in mind - thinking about
circulation, acquisitions, stock checking etc. Support for both hardware
and functionality should be considered.
Circulation functionality should be built to support the publication of
relevant data to many applications - e.g. expose current circulation
status via NGC OPAC replacements.
To get more radical:
It should not use MARC as a way of storing bib records (although it
should support import and export of MARC for backwards compatibility)
It should adopt FRBR as a data model for bib data
Cataloguing client/workflow should force the re-use of data (via
pointers) rather than literal values in each record.
To be worth starting from scratch this has to be radical - as you say,
we aren't going to get to this point by incremental improvements to
existing systems.
Owen
Owen Stephens
Assistant Director: e-Strategy and Information Resources
Imperial College London Library
Imperial College London
South Kensington
London SW7 2AZ
Tel: 020 7594 8829
Email: o.stephens_at_imperial.ac.uk
> -----Original Message-----
> From: Next generation catalogs for libraries
> [mailto:NGC4LIB_at_listserv.nd.edu] On Behalf Of Dan Scott
> Sent: 29 January 2008 00:50
> To: NGC4LIB_at_listserv.nd.edu
> Subject: Re: [NGC4LIB] Planning open source Library system at Duke
>
> On 28/01/2008, John Little <John.Little_at_duke.edu> wrote:
> > NGC:
> >
> > The Duke University Libraries are preparing a proposal for
> the Mellon
> > Foundation to convene the academic library community to
> design an open
> > source Integrated Library System (ILS). We are not focused
> on developing an
> > actual system at this stage, but rather blue-skying on the
> elements that
> > academic libraries need in such a system and creating a
> blueprint. Right
> > now, we are trying to spread the word about this project
> and find out if
> > others are interested in the idea.
> >
> > We feel that software companies have not designed
> Integrated Library Systems
> > that meet the needs of academic libraries, and we don't think those
> > companies are likely to meet libraries' needs in the future
> by making
> > incremental changes to their products. Consequently,
> academic libraries are
> > devoting significant time and resources to try to overcome
> the inadequacies
> > of the expensive ILS products they have purchased.
> Frustrated with current
> > systems, library users are abandoning the ILS and thereby
> giving up access
> > to the high quality scholarly resources libraries make available.
> >
> > Our project would define an ILS centered on meeting the
> needs of modern
> > academic libraries and their users in a way that is open,
> flexible, and
> > modifiable as needs change. The design document would
> provide a template to
> > inform open source ILS development efforts, to guide future ILS
> > implementations, and to influence current ILS vendor
> products. We would use
> > the grant to fund a series of planning meetings, with broad
> participation in
> > some of those meetings and a smaller, core group of schools
> developing the
> > actual design requirements document.
> >
> > At this stage, we're seeking feedback on our ideas and
> finding out who might
> > be interested in participating, prior to our formal
> submission of the
> > proposal to the Mellon Foundation in early March. We would greatly
> > appreciate your responses to the following questions.
> >
> > 1) Does designing an open source ILS seem like something
> worth exploring for
> > academic libraries?
> >
> > 2) Given the information above about the proposed project, is your
> > institution interested in:
> >
> > -- staying informed of our progress?
> >
> > -- contributing time and effort to the planning process,
> even if only
> > through the first or second workshops?
> >
> > -- possibly being one of the core schools that participates
> throughout the
> > full planning and writing process
> >
> > 3) If you have any initial feedback on our ideas, we would
> love to hear it!
> >
> > *Please email us at openlib_at_duke.edu.*
> >
> > Thank you for your interest and considering this
> opportunity to work with us
> > on this project. If your answer is yes to number two
> above, we will be
> > contacting you to further explore participation. Please
> send your *reply to
> > openlib_at_duke.edu.*
>
> Hi John:
>
> This sounds very much like the first step in a traditional
> waterfall-oriented approach to systems development. While I applaud
> your willingness to approach the implementation as open source
> software, and agree that having a rough set of requirements publicly
> documented would be useful, I worry that pouring a huge amount of
> effort into creating a set of design documents with "a series of
> planning meetings" would be far less rewarding than simply taking an
> existing open source library system and building out / discovering the
> additional academic requirements you have using an agile development
> methodology.
>
> We (Laurentian University, McMaster University, and University of
> Windsor) plan to take an agile approach with Evergreen (a recent
> recipient of a Mellon award). I've been focused on old-fashioned
> infrastructure work to support internationalization, to begin with,
> but once we have a shared consortial test system running we plan to
> try it out with our users (patrons, staff, librarians), find out what
> needs fixing and what's missing, address those pieces, and iterate
> again in relatively fast cycles.
>
> We know at the "rough requirements" level that above and beyond
> Evergreen's current features we want acquisitions, serials, reserves,
> and integration with course management systems, for example - but we
> also know that spec'ing all of that out in advance is going to be far
> less effective than getting something basic working, trying it out,
> and figuring out what needs fixing or enhancing. We don't see that
> cycle ever stopping, actually. Library systems should be living
> systems: that's part of the problem that we've seen with our
> proprietary systems (even the ones that aren't having their life
> support pulled by the vendor).
>
> If you have to go the full design document route for process or
> funding reasons, that's understandable: however, when you pass the
> design document stage, please consider an implementation route that
> builds upon and extends an existing open source ILS.
>
> --
> Dan Scott
> Laurentian University
>
Received on Wed Jan 30 2008 - 04:59:31 EST