Posted by Malachi-gdo on August 14, 2008 at 12:19am
Yes, sign me up!
32% (6 votes)
Perhaps, how much work is already completed?
32% (6 votes)
No, but I would love to see a Drupal ILS.
37% (7 votes)
Total votes: 19
Comments
For those of you that are
For those of you that are not library people, I took the following from Wikipedia.
An integrated library system, or ILS, is an enterprise resource planning system for a library, used to track items owned, orders made, bills paid, and patrons who have borrowed.
http://en.wikipedia.org/wiki/Integrated_library_system
FYI
I've never used it, but Evergreen, is an open source ILS developed by The Georgia Public Library Service.
http://www.open-ils.org/faq.php
4th option, no!
At the risk of being labeled a heretic, I think there needs to be another choice. "Don't do it"
Based in my understanding of the intricate nature of ILS's and over a decade of Free Software technology work (including 5 years of doing development using drupal), I would advise against taking on such a project.
This might sound odd, considering I'm in the middle of building a system that is a parallel to an ILS but in the world of Public Access Media Centers, but I think you should view drupal as a way of creating a library website -- use drupal as the public facing system that can link to your ILS in all sorts of creative ways, but not as a replacement for your ILS.
When we started on the Pegspace project (PEG is the industry acronym for Public, Educational, and Governmental Access Media access centers), which is now morphing into the Open Media Project, we started by looking to see if there was any pre-existing tool that we could build on. There was not, so we decided to base the new system on Drupal.
In the library world, we already have two very stable and functional Free Software ILS's (evergreen and koha).
I would suggest that you look into those tools and use drupal in conjunction with them.
Mainly the reason to not build an ILS in drupal is that drupal development moves far too fast. Two new versions of drupal have been released since we started code work on the peg project. Without substantial funding and/or a formal collaboration on behalf of many libraries, I think that having to deal with the ever changing API and the pace of development would be very problematic.
I think you would end up so far behind the curve that not only would your system quickly become obsolete, but within 18 months it would be based on a version of drupal that is not supported with security releases, and your ILS would become a security hole in your library's network.
Drupal is a great tool, but it is too easy to fall into the primary trap of technology development -- When you get to know one tool really well it becomes your only tool. Not every problem is suitable to be hit with your drupal hammer.
Use drupal in a way that will enhance your technology systems, not in a way that will drain resources from the larger picture.
Integrate drupal into the existing F/OSS ILS tools, don't rebuild that wheel.
Makes perfect sense
Eric,
Your post makes perfect sense. The right tool for the right project. Since there is no option for a straight NO... I will vote for the only no option.
Bob Snodgrass
Bob Snodgrass
Integrate drupal into the existing F/OSS ILS tools, don't rebuil
Yep. Modules that provide better integration with ILS systems (F/OSS or not), courseware and other educational technologies would provide a better return on investment than a full scale ILS. Let Drupal be the glue that holds together a wide variety of online library tools.
I agree. I would much
I agree. I would much prefer to see Drupal modules that enable good integration of one of the existing ILS systems. My own preference would be Koha but either Koha or Evergreen would be a very good ILS base (both are GPL). Integration leads to the discussion of what integration would mean.
Caveat to my yes vote
I'll second Eric's comment regarding a complete replication of an full-featured ILS. However, I voted yes in the poll under the assumption of what a book/media catalog could be. I posted a note (http://groups.drupal.org/node/11981) proposing a much less functional catalog which seems to cover the functionality required for a corporate library.
Unfortunately, I've collected no comments/responses regarding that so I'll continue with my probably ignorant notions of how a lightweight corporate-focused library catalog could work. I'm hoping to get started near the end of the month. Everything I need appears to be there except for the client ability to assign ownership of physical media to another client.
Functional requirements are worth investigating
... even if it doesn't come to much. My vote is yes.
Maybe not a "full featured Drupal ILS"
I am very much in if we were to keep the scope of the project more limited.
While Koha and Evergreen are great in medium sized public libraries and large consortial libraries respectively, I do not think they address the needs of all libraries. Just consider the limited hardware/software requirements of Drupal versus either of the existing open source options. Imagine if you were a small library and could have a ILS that ran on an inexpensive web host.
I think a small scale, limited ILS would be very powerful for small and special libraries. If we kept the scale small, I think we could keep up with the rate of Drupal development.
I have been thinking that this needed to be done for some of the smaller private libraries that we serve, so I am excited by the prospect of someone else wanting to do something along these lines.
Both Koha and Evergreen can
Both Koha and Evergreen can run on small systems. Except for being Perl based, both have essentially the same requirements as Drupal. Koha can even run with a file-based DB and doesn't need to have quite as much power underneath as Drupal does. My wife runs Koha on her laptop and it runs quite well, so your argument doesn't hold about needing more than an inexpensive web host.
I've been thinking about what we do need in Drupal. I can see adding OPAC interfaces to Drupal to provide the public view of the library in a consistent manner where the OPAC module would interface to that part of an existing ILS. The OPAC is actually a relatively small part of an ILS.
For a lighter-weight solution, how much is already done?
It seems that between:
http://drupal.org/project/marc
http://drupal.org/project/library
http://drupal.org/project/millennium
http://drupal.org/project/biblio
http://drupal.org/project/faceted_search
http://drupal.org/project/biblio_facets
http://drupal.org/project/apachesolr
A lot of the heavy lifting is already done, at least for smaller libraries -- Using this functionality (or, better yet, a more clearly defined spec) as a starting point would help focus the discussion.
With that said, I'd love to see libraries more effectively served by Drupal, and it seems that this thread could help identify a subset of common needs that could then be addressed either through config or development.
FunnyMonkey
Tools for Teachers
FunnyMonkey
Keep it modular
In my opinion, this is really the approach to take. Maybe the ILS isn't a new module but a new install profile of modules that provide ILS type functionality.
I am actually working in the process of expanding on the MARC module to be used in a union catalog/ILL situation which would lend itself nicely to this project.
Beyond the obvious library modules, I think it is well worth looking for other Drupal modules that might be flexible to be used for this. One need an ILS is the booking issue and I have been meaning to see if Open Resort module couldn't be used for this. http://drupal.org/project/openresort
I think this would be the sort of Drupal way of taking on project like this.
Response to Eric
Eric makes some good points, for ALL Drupal development. Drupal development is rapid, which is great, however fast Drupal development causes problems for all Drupal site maintainers.
So should we not use Drupal at all? I think not!
Should we not use any PHP framework? Drupal is a still a PHP framework (on steroids).
Why not use Drupal? Use the framework safely. The data will all be in MySQL or Pgres., take your pick.
I do not think it is impossible, and the benefits over static development are,
Eric, if what you say is true, then Ann Arbor should not be using Drupal as their OPAC.
With CCK, Drupal can be used, judiciously, with only the minimal modules, to create:
Biblio
Items
Patrons
Held items
Fin rules
The Drupal user already has all the permission structure to setup librarian (or patron) login's any way you want.
Then some PHP-code/rules to hold it together.
What we see now with the ILS companies is them scrambling to put in Web2.0 functionality. Drupal already has that.
Could we not at least create something more advanced than OpenBiblio (in PHP).
If Drupal should not be an ILS then it should not be an OPAC, or Fish4Info, or one of the thousands of very complex Drupal web sites with tons of plug-ins.
Drupal is not a hammer, it is a power tool workshop. A hammer is more like, PHP by itself. All complex Drupal sites require effort. The library modules should be based on the core as much as possible and be kept simple.
-Malachi
Not sure you got my point
By the tone of your reply, I feel I might have offended you with my comment. I'm sorry if you took my comment as criticism and not simply one geek giving his opinion.
When you start with "So should we not use Drupal at all? I think not!" in bold, you've already moved so far from what I stated that I'm not sure you really read my post. I just don't see how that in any way is responding to the content of my post.
Just for background: I've been actively advocating for the use of Drupal, among other Free Software tools in libraries for years. I tried to convince the ALA to move their website to drupal about 3 or 4 years ago, and although they went for a non-free system instead, I'm really happy to see that recently the ALA has started taking Free Software in general, and Drupal in specific more seriously.
In my comment I tried to be clear that we should use drupal, but we should be careful about people's expectations or replicating the effort of other F/OSS communities.
As a Free Software developer and project manager, I have learned that the most important job when introducing people to Free Software is managing expectations.
Drupal has become the first interaction with Free Software for many in the library world. Oversell what it can do, or try to take things too far and you will not only damage Drupal's reputation, but you do damage to the world of Free Software in general.
I'm not going to debate if drupal is a hammer or a set of power tools, the end result is the same. Use the right tool for the job, a chainsaw is powerful but hardly appropriate for cutting butter.
When you say "If Drupal should not be an ILS then it should not be an OPAC" you also miss my point. Drupal is the right tool for certain uses in a library.
The taxonomy system of drupal makes it a perfect tool for an OPAC. Drupal can be an OPAC with currently existing features in drupal core (plus a couple well maintained and stable contributed modules.). Drupal can not be a "full featured ILS" without a ton of code that does not yet exist.
You refute my position by saying "Eric, if what you say is true, then Ann Arbor should not be using Drupal as their OPAC."
Ann Arbor is doing exactly what I suggest. They are using Drupal for what drupal is good for. The same is true of many other libraries. The NYPL uses drupal in some places, but they still turn to Omeka (another F/OSS tool) when appropriate.
Drupal is an important tool for libraries. The taxonomy system makes it a natural match for libraries. But, without serious funding or a long term explicit collaboration by a group of libraries, trying to make it a full featured ILS is risky.
I think it's a great idea to work on the requirements/spec of such a tool even if it never gets built; I'm not trying to stop you from moving forward with such a project, I'm simply offering some advice based on my experience.
Instead of building a drupal ILS, I think the long-term needs of libraries would be better met by integrating drupal with as many existing ILS tools as possible allowing any library to use drupal as the public facing website, community communications center, and OPAC. (although if you're going to integrate it into non-free ILS systems, remember that you have to be careful how you bridge the two systems in order to not violate the GPL)
Thanks for getting this discussion started. I'm interested to see where it all goes.
Reply #2
Tone? Yep, and my opinion is let's do it. This is just code. given some of the complex Drupal sites out there, a Drupal ILS is certainly work like anything worthwhile. Start simple, then build slowly. There is nothing wrong with that. Let us start small to build an ILS small libraries can use for free if they have a reasonably knowledgeable IT staff.
No, I read it. If Drupal can be a complex OPAC, then it can be a lightweight ILS.
People's expectations ought to be that anything worthwhile takes time and effort.
Right, and how about a lightweight ILS, slightly more clever than OpenBiblio with all the functionalit of Drupal.
??? I just damaged Drupal and the world of free software in general....by proposing a new project. ??? :D
What??? ROTFL <- no really
I don't think Linus Torvalds is shaking in his boots by the mere suggestion of a new OS project somewhere in the world.
There is no frame of reference to what you are talking about. Nobody is selling anything, this is talk about a possible new project, that will take time.
Why should you determine what those uses are. People said for years that Linux/(and historically Unix) was a toy, not good for any real production work, is it still true? In the days of IBM mainframes in the 80's people laughed at Unix and called it a joke. This is a small project. There are no expectations until version 1.0 is finished, all I did was post an idea.
None of the OPAC code existed until the III modules were written. Yes, they had to write some code, since Drupal could not become an OPAC until they wrote a ton of code that did not yet exist. Those III modules are not entirely simple, much work went into them.
Right, it is an OPAC, you are proving my point. They had to code alot to get the OPAC working in Drupal, so now on to the ILS.
Say I build with CCK a patron data type. Now Drupal will have a patron with a built in way to edit that data type---done. Many of the data types for an ILS can be built this way, including a CCK type to contain rules of the ILS, then code needs to exist to allow the types to operate. With triggers, some of the coding is reduced, and reports can just be written the old fashioned way.
Risky how? For whom? I am talking about people working for the passion of a project. The risk of some time to try a cool and interesting project? There is no "risk."
Actually your advice was "don't" so now you say we should? I think you need some rest! Well, at least the idea, just an idea, of building a lightweight ILS in Drupal is starting to sink in.
I don't think it would if it is just obtaining data from a database to show on an OPAC.
Your comments are expected, since someone already made a Drupal OPAC, sure it is possible now. But before they did this, there would have been naysayers: "Drupal is good for a website only and should never be an OPAC, it is just too risky." If their Drupal install crashes, then they have no OPAC, but it is pretty stable and updates should always be done on test installations to test them, and not the production until the patches are clear. It would be the same for a Drupal ILS or OPAC.
Well, after we build it then will you admit it is worthwhile? ;)
you really are missing my point
No, I never said that and you are taking my words completely out of context.
You have done no harm with this discussion.
Should you be telling a library that you can easily turn drupal into a "full featured ILS" and fail, then you will be doing damage.
But I also see that you have now changed "full featured ILS" to "lightweight ILS" by doing so, you might be addressing my concerns. how do you see a full featured ILS differing from a lightweight ILS?
I do think that you have underestimated the complexity of what you want to do. Trying to keep your modules up to date and consistent with the ever changing API of drupal (which only changes with new versions of drupal) and the ever changing API of CCK (which has made major changes in sub-versions) and Views, etc, is going to be a major challange.
If you move forward with this project I'll do my best to share code with you and otherwise put in what I can. But, to be honest I won't recommend use of it to any library I work with until you have successfully created the system and kept it stable through at least one if not two new versions of drupal.
This is where the risk for the larger community lies and there are many examples to point to over the history of drupal. There are many modules and tools, even distributions of drupal that promised to handle the needs of one part of the community or another. A lot of folks jumped in and got left using modules that never got upgraded or a distribution that ended (forcing a hard and painful cutback to drupal).
Please read and respond to my comments with an understanding that they are offered as constructive criticism and I have no desire to be in a hostile exchange with you.
If man had been meant to fly, they would have given him wings
Flying contraptions? Bombast! It will never work!
Eric, I am not upset. In fact, this is my last reply, there is little point to this.
I want to talk to people who want to work on something worthwhile.
When I said "full featured" I mean in the sense that Drupal already has tons of features. Ann arbor is using many of these features in their Opac because they are already built into Drupal.
Look at Ann Arbor
http://www.aadl.org/catalog
Much of the heavy lifting has been done. So they have integrated blogs and the rest of the web site built in. They could also have a variety of authentication methods for login, since Drupal already has these. I am saying "full featured" in the sense that Drupal has many modules which could be used to enhance content. These modules are stable and have been used for a variety of things--there is lots of flexibility there, even if the check in/out and hold modules are more simplistic.
"Calmer than you are." - Quote by Walter. From the Big Lebowski
ILS and GPL
Eric, would you be able to elaborate on this point, with some examples:
although if you're going to integrate it into non-free ILS systems, remember that you have to be careful how you bridge the two systems in order to not violate the GPL
I don't want to take this thread off topic, but this is highly germaine to the library world in general. We deal with Horizon, and would like to replicate something like Ann Arbor's triple-I middleware to have Drupal serve as the OPAC. Can you describe a scenario like this that would violate the GPL?
Also, I need to get more familiar with the terms of GPL in general. Can you point to one or more easy-to-digest resources?
Many thanks,
Devin
quick answer now, more later
I have a few min before heading out to a meeting, so here's the quick answer. I'll start another thread on the topic of the GPL and ILS integration later today with a longer answer so we don't move this thread off topic.
When integrating software licensed under the GPL with software licensed under any license that is not considered compatible with the GPL, you need to do so in a "hands off" manner -- via a remote api (soap, rest, http, etc,). Your bridge code can not have the ability to directly call internal functions within both applications, but should act as a data conduit between them.
for getting more familiar with the gpl: http://www.fsf.org/licensing/licenses/gpl.html
list of GPL compatible licenses: http://www.fsf.org/licensing/licenses/index_html#GPLCompatibleLicenses
U of Rochester eXtensible catalog will use Drupal as a front end
https://urresearch.rochester.edu/handle/1802/5757 (from Information Technology in Libraries June 2008) says that the eXtensible catalog will use Drupal as a public and staff front end.
Case-study using eXtensible Catalog with Drupal as front-end
Creating Communities by Denver library: http://drupal.org/node/903926
Uses the eXtensible Catalog Drupal toolkit.
Other ILS interfaces in Drupal: Social Online Public Access Catalog (SOPAC)