Smorgasbord 6

I have a smorgasbord of stuff I want to talk about today. Some of these are recurring questions the PINES/Evergreen team seems to get, some are in response to issues raised in library blog-land or email lists, and a couple are news from the development group. There’s something for everyone on this buffet of a blog entry. Grab your plate and come ‘on.

Software Releases

Our baby Evergreen is all grown up. *sniffs* It was our intention to push out an official 1.0 release prior to go-live, but that goal fell down the priority list as the migration approached. Now that the migration rush has passed, expect an official Evergreen 1.0 release soon. Of course, the full software is available from the code repository any time.

In related news, we’re starting the initial planning for Evergreen 2, and acquisitions and serials control are the big features planned for the next release. Just quickly looking around, acquisitions is an area where many of our problems may already be solved in the larger software world. All kinds of folks need to do stuff like order widgets and track accounts. If anyone out there has a suggestion for an open-source software package that may fit in this slot, drop us a line.

“Free” Software

This is something I’ve seen repeatedly in library blog-land and on email lists: “Evergreen [or insert your favorite open source software here] is not really free. Resources have to be devoted to installing, supporting, and maintaining the software.”

Well, duh, of course you’re going to have to devote resources to run an ILS. Sure, Evergreen is cool and all, but it doesn’t pop itself out of the box and start intelligently going to work and maintaining itself. There is no such thing.

Evergreen is a tool… a complex tool, sure, but it’s just a tool. Pretend for a moment we’re all in the earth-moving business instead of librarianship. Evergreen is a big bulldozer, and anyone can go and pick up a copy of the Evergreen Bulldozer for free. Now, you still have to hire someone to drive the bulldozer, you need an engineer to figure out how you want to use the bulldozer, you need a mechanic to maintain the bulldozer, and you need fuel to keep it going.

But, more important than the [no] cost of acquiring the bulldozer, you have the power to take it apart, see how it works, and even improve on it. We have no trade secrets; how this thing works is not locked up and closed-source.

Evergreen is both free as in speech and free as in beer. What you do with it after you acquire it is up to you.


We believe an important aspect of the success of an open source project is the growth and development of a community of users and developers around the software. We’ve largely taken a “build it and they will come” approach and a fledgling community has, as expected, popped up. We want to continue this growth, and eventually foster a large, thriving Evergreen community. If you’re reading this, then there is a good chance you have some interest in the project and software, so, I ask you: do you have any community-building ideas?

Upcoming Appearances

Representatives from the PINES/Evergreen team will be at the following upcoming events/conferences:

6 thoughts on “Smorgasbord

  • Don McMorris

    Excellent! It looks like you’ve finally got through the ToughPart(R), I look forward to V 1.0 for my in-house purposes (a small private library with goals of maintaining technology-related collections for ILL lending). On a side-note, I plan on wearing my Evergreen T-Shirt to some upcoming library system functions (such as the system-wide Users’ group).

    I.T.O. “Free Software”: I cannot think of *any* project (proprietary or open-source) that works out-of-the-box. All software will require time. The thing with Open-Source if it is broke, you CAN fix it if you so desire. Comparisons of Major Open Source Softwares vs. proprietary closed-source counterparts shows that Open-Source is more secure, cheaper, and in many other ways, better. For example: A comparison of the time to fix a bug/security vulnerability in the top Intel-platform proprietary Operating system is often several weeks following announcement. The Linux kernel often has bugs/security vulnerabilities fixed in a matter of hours following announcement. Why? It’s open source! Absolutely anybody can (if they so desire) modify/fix the sofware code!

    It would be interesting to do a study following a few more migrations… Comparing Evergreen to commercial ILS’s.

    Keep up the good work!

  • Josh Stompro

    Community building ideas. I think someone should list the project on Freshmeat ASAP, I think that will help typical open source users find the software, that is the first place I usually look.

    A live demo cd would be a wonderfull tool to show off the software. Boot it up, import your customers/bibs/items and begin playing.

    I will hopefully have time again soon to do a trial install and document things as I go along.

    More documentation is always helpful, Design documentation is always helpful. I haven’t seen much commenting in the few source files I have looked at, which makes it hard to jump in and modify or just understand something.

    Maybe you could post a list of items that you would like help with, ie “We would like someone to go through and add comments to the util.js file” I would love to help more and it would be great if you have some smallish tasks that people could help out with that would move the project forward with some direction from the dev crew.

    Thanks for Evergreen.

  • K.G. Schneider

    Ms. Duh here… I only say that a lot about OSS because I hear all the time that it’s “free,” and there’s confusion out there about the difference between free as in “free beer” and free as in “free kittens.”

  • Don McMorris

    Hey Karen! I’ve heard freedom as in “Free beer” and “free speech”, but never free as in “free kittens”. The term does very much make sense in regards to OSS in business (including libraries). Of course, if you figure in the medical expenses associated with Free Beer, that term would be more appropriate too 😉

  • Tom Barber

    Community building: first off, most successful community-driven open-source projects have a centralized repository in the public space, hosted by a third-party (sourceforge for example), and allow contributions from developers other than the original author(s). Has there ever been talk about truly opening up the project to be driven by a community rather than just a sole sponsor?

    In the cathedral vs bazaar model, OpenILS seems to be very much in the cathedral model … it works fine for GA, but it still remains to be seen if a community will be the driving development force and whether a community will form.

  • miker


    I don’t personally see too much point in using sourceforge (or GNU’s savanah) as the physical repository as long as the repository is open (which it is), and in fact I’ve had a great deal of trouble with sourceforge’s CVS servers in particular. The growing pains they are experiencing are simply too much trouble for us, as three of us are committing new code to multiple branches several times each day. It’s just not feasible to move the core repository to a site that’s /known/ to be less reliable than our own — but I don’t see that making it any less open.

    Also, we are working to reach out to the community on several fronts — for instance, we just set up a at freshmeat project page. We’ve been very lucky to get almost two dozen outside contributers of documentation, and we’d love to have more.

    As far as outside code contributions, there’s a pretty large learning curve at this point, so we’re not expecting anyone to jump in with both feet and start sending patches right away. Now, that doesn’t mean we’re a Cathedral, it just means that we’ve got a more complicated code base to sell at the Bazaar than your average webmail app or problem ticket tracker. We’re very confident that as people interested in the project from both professional and technical perspectives work with the system (there are several folks busy attempting local installations) that we’ll start getting more code /and/ documentation contributions — and at that point “we” will mean the community, not just GPLS.

Comments are closed.