LoomWare: Entries from November 2009

Sun	Mon	Tue	Wed	Thu	Fri	Sat
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30

Given the nature of the Stephen Abram (SA)/SirsiDynix (SD) document that has been making the rounds I thought it would useful to respond to some of the statements. I also thought it would be useful coming from someone who has used vendor products like Innopac from III and Unicorn from SD, and also implemented or created open source products in all aspects of the Library operation. The comments below are provided in response to specific statements in the SA authored document, which are shown in italics. Like SA I am not quoting sources - it seemed unfair and a bit odd to respond to a document like this with a bunch of quotes and numbers. Besides, in many respects this is a religious issue, where faith is more important than fact, SD is the Magisterium and...darn, where is my dæmon ;-)

Apologies for the length, but the more I read the more I was compelled to respond.

Introduction: caveat emptor
SA's intent to apply the buyer beware concept to open source is much more appropriately applied to a black-box system like Unicorn. I suggest you apply this moniker to SD products whenever they mentioned and it will make a lot more sense.

The concept of open source is fairly misunderstood and quite vague.
No it isn't. Like any rich open landscape, the concept of open source is subject to discussion, interpretation and modification just like actual open source software. Documents like this are the only reason why people become confused about open source, so if SA's intent is to facilitate misunderstanding, this is how it is done.

Nevertheless, it should be noted that it is rare for completely open source projects to be successful.
Not true. I would even wager that there are more successful open source projects and products than there are in the other camp. This statement also depends on how you define successful. For example, if I create an open source project, cease to maintain it, but any number of other people pick it up, use it, and continue to maintain and improve it themselves, is that more or less successful than a vendor product that dies, ceases to be functional, as in nobody can use it anymore? Horizon anyone?

Rather than focusing on best-in-class software choice decision-making, these projects often end up being archipelagos of systems driven by a philosophical principle that is anti-proprietary.
This statement suggests that proprietary systems like Unicorn/Symphony are best-in-class software, rather than a reflection of a companies primary goal, which is to make money. In some cases this can result in "best-in-class" software, but it can also result in "compromise" software. Open source is all about innovation and open (standards, code, data, etc.) - if ever there was an archipelagos system it is a black-box ILS system.

The open source proponents state that it has a much lower price and a much lower total cost of ownership (TCO). What they tend to leave out, however, are the entry costs of switching systems.
Open source does (in my experience) have a much lower TCO. As one example, UPEI moved from the SD Unicorn ILS to Evergreen in just over 2 months, including buying new hardware, hiring a contractor and acquiring a 1-year Equinox platinum support agreement for LESS than what we paid for a year's maintenance for Unicorn. With what was left over we paid developers to add some functionality to Evergreen, some of which found its way back to the project. That kind of giving back to the community feature of open source is hard to assign a value to, but it is many times greater than the effort you typically put into a closed proprietary system, further enhancing the TCO of open source.

Open source proponents tend to focus on the ‘free’ license that commits them to the software.
People who understand open source also understand that this is an old school belief long since proven false - except when documents like this try to raise it again. At UPEI we do not assume cost savings from open source implementations, we assume value added for us and the broader library community, and a lot of it. The funds we used to pay to SD now go to the larger open source community and have benefits far and beyond our immediate requirements. That is what building an ecosystem is all about.

It is very unlikely that an open source solution is any less expensive than a proprietary solution.
Wrong. Just, well, wrong. See previous example. I would add here that when you build capacity internally using open source tools, your investment pays off in so may ways that the cost-benefit of implementing open source is many times that of a proprietary system. The other interesting side of this is when you build capacity internally with open source you also build capacity in the larger community, providing a set of tools and knowledgebase that only makes each implementation of a system like Evergreen easier and more cost-effective. When you buy a system like Symphony you pay the same as your neighbour, and you are only building capacity in SD's bank account.

Open source ILS offerings do not offer the diversity of choices that SirsiDynix offers.
Ouch. Now that blanket statement actually hurt. As someone who ran a Unicorn system and now has Evergreen this is simply not true. There is no contest on the diversity of offerings and especially the potential diversity of an open source landscape. The problem SD is having is the number of people coming to this realization, and given my previous comments, as more people get on the open source train diversity will grow as more sites lend their creativity to the effort. Proprietary black-box can never be as diverse as an open platform.

Some software isn't compatible with open source.
I call this kind of statement microsoftian: the only kind of software that is incompatible with open source is closed proprietary software that is deliberately made so to limit competition. There is nothing inherent in open source software that makes this statement possible and everything that makes the opposite of this statement true: Most software isn't compatible with proprietary black-box software. The rest of this section is just silly.

While some open source ILS companies are offering hosted solutions, these solutions are not at the scale or professionalism of a proprietary SaaS solution, nor do they provide the service level agreements or service expectations that SirsiDynix commits to.
Careful how you read the section on SaaS. Hosting an old-fashioned ILS like Unicorn does not Software as a Service make. It should be tightly integrated into the whole Web2.0/3.0 world and facilitate integration with other systems and data. What this statement actually says is: Trust us, we will deliver the same "gotcha-now-so-you-can't-go-anywhere-else" service in the cloud as we did you had to install it on expensive local hardware - no change to SD's philosophy, just a different location.

It is one thing to subscribe to a belief system when one is talking philosophy. It is quite another when the discussion turns to provable issues like specific ILS programs features, reliability, security, power, speed, and ease of customizing the software for specific needs.
There is nothing philosophical about an open source framework that solves your problems and gives you the ultimate flexibility to solve them as you see fit. That is a very practical here-and-now benefit. On the other hand, the decision to go with a black-box vs an open solution can be a philosophical one. I have seen decisions for Unicorn or similar systems that were just as much or more about the philosophy of proprietary and the perceived benefits than ours at UPEI were about the philosophy of open. Library Land is full of ILS decisions made for personal, financial or philosophical reasons with little real attention paid to functionality. I would also argue that the traditional RFP process is nothing more than a way for traditional black-box vendors to control the purchasing process in concert with an institution that has already decided on the system they want. I can think of at least 2 major ILS decisions that were based more on dinner with the vendor and an "under the table offer" than anything else.

Generally, the available open source ILS platforms have less than half of the features and functions of any SirsiDynix ILS.
The great benefit of open source products is that they are part of a rich and vibrant ecosystem where you are free to mix and match products to suit your local needs. While the current Evergreen does not have the same full functionality as the flavour-of-the-month-SD ILS (e.g. no serials management), UPEI was able to construct a BETTER for us ILS ecosystem by using the CUFTS open source system to manage all our serials - print and digital. This would be a challenge, or downright impossible, with a system like Unicorn. The Library community does not need more closed ILS systems, we need more OLAFs - Open Library Applications Frameworks. A better way to make this statement would be "The available open source ILS frameworks will always have more features and functions than any SD ILS."

SirsiDynix has the ability to offer libraries the most robust feature set on the market.
This is self-serving market-speak and a good example of the philosophical argument that Stephen suggests he is trying to rise above.

When we compare where we are today with proprietary platforms versus where we are with open source systems the development priorities for Evergreen and Koha are the same priorities that SD had in the 1980s. How many years will it take for them to achieve a full feature set, if ever?
Given my previous 2 comments the answer to this question is now. Open source ILS frameworks can provide the functionality of a traditional ILS now PLUS a whole lot of new stuff that leaves them in the dust. Also, given where open source systems like Evergreen have come in a few short years they also demonstrate the advantages to an open development approach, open standards and tools, open source software and an open philosophy. The box is open and no proprietary vendor will ever be able to put it back. Unless of course we all jump on the emerging OCLC "Cloud ILS" black-box wagon :-(

Proprietary software has more features. Period.
Open source frameworks have more features. Period.
I love Ping Pong! A tie at 1: your turn Stephen.

Proprietary software is much more user-friendly.
Hmmm. One of the most interesting outcomes of our switch from Unicorn to Evergreen was the comments our student assistants made when they came back from summer break and discovered a new ILS: This software is a lot easier to use. Our staff training with Evergreen also took a fraction of the time it did with the switch to Unicorn.

SirsiDynix has been building this ILS for more than 30 years. It has a feature set second to none. There's that old-style religious argument sneaking back into the "just the facts" document again. In an imperfect world without any other ILS or ILS framework than SD's this statement would be a fact. But only then. And an uncomfortable one at that. I'm getting an image of Will Smith in a new movie called "I Am ILegendS", driving around the city with his trusty Z39.50 server sidekick looking for other ILS vendors...it could be a hit...really

Probably the most attractive claim by the open source community is its ability to be customized by anyone, for anyone. This claim is technically true.
This claim is actually so true it makes me feel all warm and fuzzy inside.

Much of the desire for customization comes from Innovative Interfaces Inc. (III) clients.
Ouch. Feeling the pressure from the III and open source sides, eh SA?

Other proprietary software companies like LibLime and Equinox have always offered customization to their clients.
Ouch. SD's sales must be so hurting to describe two open source leaders with the proprietary moniker. It also helps me realize that SA uses proprietary as an insult and is applying it as such here. Otherwise why overplay the API card? Especially the closed proprietary API card? If I am a Unicorn site and I make something cool with the API using an open source tool, can I release it on Source Forge? Or to anybody I want? No, I can only release it to the SD community members, who happen to be in the closed community forum that SD provides. Why not let the code out? Why not let other non SD developers modify the code and make it better? If an API call is in the forest and no other API calls are there to help, is it still an API? Sorry, couldn't resist.

Extensive customization, especially with potentially little or no documentation can make upgrades and changes increasingly difficult.
True. This messy, difficult thing is called innovation, and while it can cause angst for those who prefer stable dysfunctionality, it does make the Library ecosystem a richer and more diverse place.

Rogue programming teams may decide to create a better version, while exclaiming “Damn the torpedoes.” The result is that the relationship to the core kernel of the software can be broken or made 'odd'.
Hmmm. Not sure how to respond to this FUDishness. At UPEI we use a rogue-ish kind of rapid development I like call a Scrum, after rugby's tried and true way of moving the ball up the field. It can get a little hairy, but it really works. And we don't have Rogue programmers, although we sometimes have well-meaning programmers going down a different path to what we intended. That is almost always a great learning experience and one that leads to more knowledge and better products. I'll take a rogue-ish Java programmer over a take no risks Visual Basic kinda guy any day. I've never heard 'odd' used in this context before, but since open source developers have often been called odd I believe this is a compliment to the effects of forking and innovation. 'Odd'?

Again, customization comes with the caveat emptor warning.
In my world customization comes with the "Oh yea!" shout. Funny true story: We were "customizing" the UPEI Evergreen database the other day and somehow managed to delete all the records in the bib database on our production server. Not only did we recover the records blazingly fast, with the awesome help of Equinox, but we also learned some valuable lessons. Never delete all the bib records before lunch! While this may sound flippant, the greatest thing about an open system like Evergreen is that it encourages people to fail and learn, rather than to fail to learn. And yes, we will be installing a new test server :-)

If they don’t, they may end up being an outlier or be forced into a proprietary environment like Red Hat.
There's that nasty word proprietary being used in a derogatory way against an open source vendor again. Now I'm really puzzled! Is the word even worse when applied against a REALLY proprietary company? Does it mean you should REALLY stay away from REALLY proprietary companies? I think the polemic is backfiring...

Open source is often represented as more secure. This, too, is debatable.
The way this statement is worded it is debatable. However, if I were to say "Software developed in an open source environment is more secure."

Some of the most security-conscious entities, like the United States Department of Defense, restrict the use of open source software for fear that it could pose a terrorist opportunity.
I'm not sure about the validity of this statement (plus the Department of Defense moves slowly, so it is only a matter of time until they wake up) but I suspect the "terrorists" will kick butt, since they are almost certainly using open source :-(

In open source, anyone can release code. But extensive testing is needed to ensure those codes are secure. The three big open source applications—Firefox, Apache, and Linux—have communities large enough to do this to find and isolate threats. It would be naive for the library market to think that the ILS community of open source programmers is large enough to create this assurance—it isn’t even close.
In considering an open source framework you need to bear in mind that a some of the functionality of the system is provided by other open source programs, such as PostgreSQL and the standard LAMP applications (also no doubt used by SD). These applications are tested and kicked by thousands of developers and are arguably much more secure than the closed source equivalents. Also, the development community that is hammering away at relatively new applications like Evergreen is definitely much bigger than the few developers who have access to Symphony code, so I am quite comfortable that the open source software I am using is, and will continue to be, more secure than any of the closed source equivalents.

The proprietary ILS market currently utilizes large-scale networks that work at speeds and performance measurements that far exceed any open source ILS installation anywhere.
Uh, don't we all pretty much use the same networks? Not sure what this one means, but it sure sounds good. My understanding (unverified, so I serve to be corrected) is that the Evergreen product was created partly because the previous Unicorn installation in Georgia was unable to meet the transactional demands of the consortium. Even if this were not the case, there are countless large metadata and fulltext systems running on open source software that knock the socks off a lot of proprietary systems, so this seems a hollow claim at best. Some actual numbers for a claim like this would be useful.

If you wanted to argue that LibLime or Equinox do not respect the skills and depth at SirsiDynix, just ask why they have hired so many alumni from SirsiDynix.
I don't really want to enter this personal little fray, but is it not possible that former SD staff were actively looking for other opportunities and recognized where the greener pastures were? Refrain" "The old black-box just ain't what it used to be, ain't what it used to be..."

Is open source harder to deploy?
No. Our implementation of Evergreen took a fraction of the time that Unicorn did at UPEI. Also, because we are proactively investing staff time and money in more useful open source/LAMP type skills, our staff can easily install most open source software stacks, giving us a great deal of flexibility. At UPEI all our current software applications (with the exception of RefWorks and desktop OS) are open source. We also have created a world-class open source framework called Islandora, all with a full-time staff complement of 26 and a systems staff of 4. Encouraging a staff to be fluent with open source tools and philosophies is the best way to transform your library.

Libraries considering open source should clearly evaluate the skills required. This might involve hiring an expensive consultant.
The only expensive consultants I have ever hired in almost 25 years of Library/Higher Ed experience were for deployment of proprietary systems. Closed Ecosysytem = Fewer Skilled Practitioners = Greater Cost. Just ask a PeopleSoft site. Or a new Symphony site. That is a good question - just how much does it cost to buy and implement the new Symphony? How many SD staff and consultants does it take? A lot of institutions hire consultants just to prepare the RFP to select the ILS system they already like, so the next part doesn't look good.

Libraries would be well advised that they have a long tradition of working with application software and that the management of a proprietary ILS involves a different skill set than managing an ILS that must be extensively customized to assure performance.
Yes they should be so advised, and that proprietary ILS skill-set is very different and will not get you nearly as far, nearly as fast, as one built on open tools and standards. Besides, why spend all your time trying to do something you know the black-box can't do when an open system will let you do whatever you want?

The employment market for development programmers is different than application programmers. It also requires a different type and level of project manager and software leadership. These people are extremely rare and cost more. And most libraries cannot cover the salaries required to retain the talent they need. Moreover, these programmers won’t necessarily be in the library programming space, meaning that libraries will have to compete with a larger development market than the limited library programming space.
Actually, it is exactly the opposite. Increasingly "application programmers" (read proprietary software programmers) will be in short supply, or replaced by expensive consultants, while "development programmers" (read open source developers) will be all over progressive organizations, including libraries. At UPEI most of our staff are becoming open source developers in one form or another. And yes, some of the open source developers are from outside the library community - this is good for the species cause it leads to a more diverse gene pool. Ommmmmmm...diversity...good...

Indeed it is an interesting strategy for some library programmers to upgrade their skills in the library open source environment and leave as their worth increases.
Only if you work somewhere that doesn't appreciate and apply those skills in challenging and rewarding ways. Why are all those people leaving SD for Equinox and Liblime? In over 15 years of working with open source developers I have never had one leave after "upgrading their skills" - they have all stayed on because they would never find a more invigorating and rewarding environment to scratch their itch. The rewards of working in an open source ecosystem are much greater and diverse than you think, SA.

SirsiDynix has rigorous testing procedures. These are brought about through large investments in automated professional testing programs and procedures, regression testing, a mature beta testing process...[more meaningless test-ish words]
In the open source community we test by releasing early and often, sharing code and secrets, and encouraging people to help because it grows a healthy ecosystem.

This [the way SA says open source testing works] is evidence of a very young development program and the lack of real management in the process. The open source process is too organic and lacks tight priorities and strong management oversight.
Many of today's best testing and debugging tools and approaches actually come from the open source community (SD probably uses many of them), so the community is far from young - yes it is organic and yes it lacks strong management oversight (in terms of the actual coding). This is why open source frameworks produce better code and can spin on a dime to respond to issues and bugs. Strong Management Oversight (read Will This Help Our Bottom Line?) = weak and ancient code.

SirsiDynix has a long tradition of using open source in our solutions
Hah. Told ya. Open source rocks cause SD uses it. Cheap shot, I take it back. Open source rocks cause it works.

SirsiDynix also has a history of participation in the care and feeding of a community of users and programmers that share and collaborate with us and with each other for the common good.
First part is true, but the second part is not, because the common good should mean in the larger library community, not just in the SD walled garden. Some of the people that use systems like Unicorn are incredibly talented people who do contribute innovation back to the common good, but they are increasingly interested in working with an ILS platform that really does contribute back to the commons, rather than the house on the hill.

Some open source system vendors describe their software as “consortially aware” or having been built for consortia from the ground up. This is fairly weaselly language.
Weaselly is not in my dictionary, but I think I understand SA's intent here. Systems like Evergreen have an awesome consortially aware architecture that makes it easy to accommodate a diverse group of libraries. This is one of its great strengths. Whether designed for Georgia Pines or elsewhere, good software design is good software design. And I think SA has been using weaselly language throughout the document, so I'm not sure where that leaves this statement.

The PINES system is actually a very poor performer at its current scale of small public libraries...[More slamming of Evergreen in general]
I'm not sure what the exact issues are in these libraries and the ones that are so happy with the new Symphony system, but I know Evergreen works well and is a great performer for us. One question I have is, if I had a Horizon or Dynix system that still works well for me and is blazingly fast, why can't I keep running it? With an open source application I could run the old software in my little (or big) library and not have to make a forced decision because a vendor has decided to drop my application. Is Symphony that much faster than Horizon that existing users need to switch to be protected from slow and unresponsive systems? Could Horizon code be released to existing customers for free (since it is dead anyway) so they can determine when they need to switch? These re all questions that one need not lose sleep over in an open source world - if your product dies you can keep running it as long as you want.

End-users are not satisfied with sub-Google performance. The expectation has been set outside of the ILS market and the ILS market doesn’t get by without meeting it. Therefore, SirsiDynix is focused on speed.
This may explain why the SD strategy isn't working so well :-( Speed is not the only game in town - we need to provide users with functionality and features that deliver what they are looking for, and that is not just book citations anymore. SA's assertion that open source ILS systems are slow does not match with my experience, whether it be the native OPAC interface of an Evergreen or a Blacklight overlay OPAC. They are extremely responsive and I'm sure in a proper test bed would meet or exceed the speed of a black-box system. In fact, you can bet that more and more SD clients will be shelving the built-in interface for one of the newer open source systems.

Finally, one of the biggest claims of open source proponents is that it is more reliable. They argue that since any programmer can find and fix bugs, the software will be repaired and improved more quickly.
True. Except for the any programmer part - you would need to know a little bit - the fact that you can learn because the system is open and accessible means that you can not only fix stuff in your own timeline, but contribute it back to the community.

Without enduring, sufficient, talented interest, an open source project is doomed to fail, and many do.
Horizon anyone? Unicorn? Oops, that's right, those projects failed. It's a good thing there is "enduring, sufficient, talented interest" in the hundreds of developers, librarians and others paying attention to Evergreen so it doesn't fail. Open source projects can't fail any more than a university degree can "fail" - they both provide value beyond the here and now and they benefit at least one person (the learner), and almost always many more than can be counted.

At this point in time, the open source community for ILS software is tiny.
I would bet money that the number of developers working in the open source ILS community is many times that currently working in the proprietary ILS community. If people don't want to bet real money we can wager with open source software, it's better than money!

Therefore, the reliability of ILS software developed on an open source platform is questionable.
A Therefore like this assumes a cogent and factual argument before it. Therefore, this statement is wrong.

Cliff called the development of the open source ILS by OLE, Pines, etc. one of the “stupidest strategies ever undertaken” in the library world.
I'll let Cliff speak for himself on this one:
I don't think that I ever wrote those words down in an article; I suppose I may have said something to that effect in an interview or q&a in some conference program like ALA Top Tech, though perhaps no quite as strongly as it's expressed here. I have without question spoken out about my concerns regarding investment in open source ILS development in the last few years. IF I did say this, it feels like it's used a little out of context -- or maybe the better characterization is over-simplistically -- in the report.
Perhaps the most useful thing to do would be to simply and briefly restate my current views on this. You are welcome to quote or share this; it would probably be best to use it in its entirety if you do.
I am very concerned that there are unrealistic expectations about what can be accomplished in terms of economic payoff or improvement in quality of service in the ILS world through investment in the re-implementation of traditional ILS systems; there is a mature, competitive market in such systems, and I question whether the choice to invest in developing an open source ILS makes sense given very constrained resources. The issue here is investment priorities. If we choose to do this, we need to be very clear about what we are trying to accomplish, and how the open source implementation gets us there. Also, there's a lot of confusion among the ideas of open source as a way of disseminating the results of research and allowing others to build upon the research, the idea of open source (or community source) as a means of engineering and developing a system that is conceptually fairly mature and can serve as a collective good, and the possibility and effectiveness of open or community source programs as a means of doing collective research and development.
I think there are still major problems -- many of which we really don't know how to solve effectively, and which call for sustained and extensive research and development -- in various areas where ILS get involved in information discovery and the support of research and teaching. While I'm not opposed to seeing an open source ILS -- who could be? -- and recognize that it could be very useful, particularly as a platform for research and future innovation, open source re-implementation of current ILS functionality will not be a panacea for these still-unsolved challenges.
Thanks for asking about this. I hope this is helpful both in clarifying my thinking on this, and, more importantly, advancing the community debate about the best courses of action here.

Amen. That is why UPEI only uses the Circulation, Cataloguing and OPAC functions of Evergreen, because we are using other open source products for stuff they are really good at. Any new efforts in today's library development community that are less than a modular component of an Open Library Application Framework are less than what we need. We need to reinvent and embrace new and emerging technologies. Saying that an early version of Evergreen did not have a Z39.50 server is a compliment, because we should be moving beyond that. The fact the open source library ecosystem could supply a Z39.50 server that was easily plugged in to Evergreen is testament to this approach. Keep it like Lego and Library Land will be a better place.