I have moved the bullet-pointed annotations to the end of the document, as they were incomplete. If they are finished, then we should move them back up to the top. KG 4 Nov 2009
The annotations in this annotated document should be merged with the ones at http://wiki.code4lib.org/index.php/SirsiDynix_Etherpad. The annotations linked from the Code4Lib wiki have much more informed comments about specific criticisms of particular systems. - TD.
Introduction: caveat emptor
On February 18, 1815, Hector M. Organ purchased 111 hogsheads (111,000 pounds) of tobacco from Peter Laidlaw and Company. It was the same day that the news broke of the signing of the Treaty of Ghent between the United States and Britain, which ended the War of 1812 and lifted the naval embargo that had drastically depressed the price of American tobacco by 30 to 50 percent.
Organ, who had spoken of the news of the treaty with his brother, speculated that the price of tobacco would rise within the next two days. But Laidlaw was unaware of the news at the time of the sale. During the discussion of the contract, Laidlaw asked Organ if he was aware of any reason for the price to be higher. But Organ remained silent over the news of the embargo lifting, and kept his price low.
The next day, when prices rose, Laidlaw incurred a large loss on the sale relative to the previous day’s price, and repossessed the tobacco by force.
A lawsuit ensued, which eventually reached the Supreme Court and a unanimous ruling from the John Marshall court establishing caveat emptor, or “let the buyer beware” doctrine in the United States. Under this ruling, “the buyer cannot recover from the seller for defects on the property that rendered the property unfit for ordinary purposes.” While this ruling happened almost two centuries ago, some buyers ignore some of the most critical facts of their purchases.
Does it bother anyone else that the section above is entirely lifted from Wikipedia, with no attribution? http://en.wikipedia.org/wiki/Laidlaw_v._Organ I know Wikipedia is an open information source, but it seems intellectually dishonest to copy. Also, this doesn't even make sense to me. In this particular case it was the seller that got cheated by the buyer. It just happens that through the wierd logic of the American legal system this case applies to the concept of caveat emptor. These are minor quibbles, but they point to the overall lack of thought and research that went into this writing.-mep
Today, we see that happening when libraries get into talks about moving their Integrated Library Systems to open source platforms systems. What we have found is that they often are not aware of the heavy drawbacks of what open source systems cannot offer at this point in time. Is it just me or does this statement seems to imply that any library that has chosen an open source ILS solution made an uninformed and...perhaps stupid decision? -ljh
Therefore, to help buyers become aware of the limitations of open source, we set out to clarify what open source is, how it is different from proprietary software platforms, and why Integrated Library Systems (ILS) are not ready for open source at this point.
So what is open source?
The concept of open source is fairly misunderstood and quite vague (I find nothing vague about it - there are official definitions available from the FSF and Opensource.org - there are many books and research papers as well all exploring the history and the goals of open source - see http://www.vuw.ac.nz/staff/brenda_chawner/biblio.html which is only version 1 of her bibliography - Nicole Engard - nce). Most organizations courting the idea of open source development do so because they feel they can project their dreams and desires onto a blank slate and have the features they want sitting at their fingertips quickly and easily.(My research findings into influencing and concerning factors for 6 libraries that developed their own OSS show this is not the main motivation - not allowed to publicise until conf paper in Feb 2010 ) kgI'd be interested in talking to some of the Koha & Evergreen librarians and asking what their motivations were in moving to open source. I doubt that "projecting their dreams and desires" was their motivation. -ljh I've talked to some of these librarians in many cases the switch was because they were being forced to use products they didn't want/like - and yes I'm referring to the fact that they signed up for Horizon and are being forced to use something else. In my experience on the vendor floor and in traveling around the US, this has been the #1 reason people are looking to migrate - whether to open source or something else - nce I could add that our libraries wanted to be "driving their own bus" in terms of features/functions of their ILS. - LR
This is a misunderstanding of how open source software development works. By definition, “Open source is an approach to the design, development, and distribution of software, offering practical accessibility to a software's source code.” Googling this quote returns Wikipedia as the first hit, not authoritative. Free Software Foundation defines free software as software where "the user (has) the freedom to share, study, and modify it." (http://www.fsf.org/about/what-is-free-software) The difference between free software, open source software, and free (library) open source software would be beyond the scope of this paper, but I'd pick the FSF definition over Wikipedia. -tr There are 10 criteria to be met for software license to be "Open Source" , as defined by the Open Source Initiative - including ability to see source code, no discrimination against persons or groups, no discrimination against field or endeavour and the product is technology neutral http://www.opensource.org/docs/osd kg (Citation is definitely needed from Abram--jn)
A more technically correct term to define what open source is would be “peer production development,” (again, likely cribbed from Wikipedia without a citation -tr) (again, citation is needed--jn) meaning that the open source model allows concurrent input of differing agendas and ideas to the development of software. Essentially, anyone can join the collaboration effort with the goal of making it stronger and more feature-rich.
Some of the most successful open source developments include the Linux operating system, Apache HTTP Servers, the Internet address system Internet Protocol, and Mozilla’s Firefox Internet Browser.
The open source community repeatedly points to these efforts as the poster children of how successful open source can be. However, each of these developments has a major issue in common: they were developed because the public demanded it—they each had a critical mass.
Is not the library community at a critical mass, fed up with proprietary software vendors, and needing more customizable systems that have releases and fixes that occur more than every two years and also meet library needs? (not quite sure how to best add comments to this for a response--let me know if this isn't what you were thinking) -(--hb) (Exactly, Heather! How is the demand for an open source ILS any different from the demand for an open source web browser or an open source OS?--jn)
Nevertheless, it should be noted that it is rare for completely open source projects to be successful. ( and that it is a rare proprietary software product that does not rely on components of Open Source kg Yeah, wasn't Mac OS X built on the Linux kernel? -ljh FreeBSD/NetBSD ;)-LR 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. (sometimes true, but not necessarily always true. open source code can be likened to peer reviewed scholarship, and as librarians we know that peer review is an important process that develops new knowledge that has been tested, vetted, and accepted as good scholarship. also the notion that everyone involved with open source projects is philosophically anti-proprietary is false -tr)
How are open source developments and proprietary platforms different?
There are a number of assertions that proponents of open source claim as the strengths of open source, including: ‚
There are many more arguments on behalf of the open source community, but we will focus our attention on these subjects due to the importance of these assertions.
Total Cost of Ownership (TCO): The Real Price
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. Especially in the library market, the two main open source players haven’t been around long enough nor do they have enough clients to provide evidence for this argument.
There is a difference between price and TCO. Open source proponents tend to focus on the ‘free’ license that commits them to the software. This seems to be confusing open source, free open source, etc. -ljh And if it is free, they are not committed to keeping it, since no costs are out of pocket. They can even switch freely if it does not work out for them.
However, all software has a true TCO, which includes the sales price, initial implementation time and costs, any hardware and software upgrades, hosting costs, maintenance and technical support, upgrades, and training (or re-training). It is important to determine the overall costs of adopting a new mode.
It is very unlikely that an open source solution is any less expensive than a proprietary solution. Citation needed. -ljh In fact, in all of the data SirsiDynix has collected And where is this data? -ljh , we are not seeing quotes that conflict with this assertion. Indeed there are very few green fields in the ILS marketplace. Most libraries already have an ILS and receive upgrades as part of their maintenance contract from us or other proprietary vendors. These maintenance contracts are a small percentage of the initial price.
To convert to an open source option like Evergreen or Koha using vendors like Equinox or LibLime the library must start over with conversions and implementations, usually paying another vendor or consultant to accomplish these. (For libraries stuck on Horizon, they will have to pay S-D to migrate their data, S-D's migration team and library consultants, training costs, hardware costs, plus the costs to the local library of rejigging workflows and setting up local customizations. And this will be a forced change due to Sirsi and Dynix's merger -tr) As open source companies assert, it is free like kittens, not free like beer. (is anyone stupid enough to think running a library is free, as in $0? FOSS advocates focus on the free as in freedom, more than free as in no money. -tr)
Generally there will be significant limitations to the hardware and operating system options. (like what? needs examples -tr) (agreed - where is this information coming from?) -nce ( One library that developed OSS reported being able to afford substantially *more powerful* hardware with the $$ saved from not paying license fees - kgThis limits the ability to cooperate consortially or share resources with host cities or institutions that may use a different standard. The library is at risk of being an island in the community.
There are several library consortia successfully using Koha -- INCOLSA, WALDO, MASSCAT, SCLS, and Plano Independent School District immediately come to mind--not sure on the Evergreen numbers. Several regional library consortia in Kansas (NEKLS (30 libraries), SEKLS (9 libraries), CKLS (35 libraries)) as well as Derby Public Library and the Salina Public Library all use the Z39.50 protocol to successfully connect with the State Library Union Catalog, the Kansas Library Catalog and to other libraries for cataloging purposes. We are not islands in Kansas! (hb) Consortia using Evergreen: Georgia PINES (275 libraries), SITKA (British Columbia) (25 libraries), Michigan (10 libraries?), Indiana (42 libraries), Project Conifer (4 post secondaries in Ontario), SC Lends (8 libraries), North Texas Regional Consortium (13 libraries). King Country Library System, Washington, Sage Library System, and Bibliomation will be implementing Evergreen in the future (http://open-ils.org/dokuwiki/doku.php?id=evergreen_libraries) -tr) My publib (Grand Rapids PL) & the Branch District Library are two libraries in Michigan that I know, off the top of my head, are Evergreen libraries. They both participate in MelCat, which is a state-wide ILL-ish consortium. I can check the other 8 libraries if I can find their names. -ljh
SirsiDynix offers—and has offered for many decades—a wide variety of options for servers, operating systems and plug-ins. Open source ILS offerings do not offer the diversity of choices that SirsiDynix offers. ( - having a diverse range of choices is not useful if they include features the clients don't want and don't include features they do .) kg Citation needed. -ljh
Open source proponents and proprietary companies disagree on the total cost of ownership.
Do all libraries really need lots of choices? Do many libraries actually require an ils product with many features they will never use? (hb)
Proponents claim that even if open source requires more expertise, the TCO is ultimately lower. (this needs substantiation. It is not claimed in most library based literature about Open Source software ) kg Companies claim that the required expertise is daunting and the other costs of proprietary solutions are exaggerated. Citation needed. -ljh (These charts illustrate concepts, not actual numbers.)”
Opportunity Costs
Some software isn't compatible with open source. This is pretty vague. -ljh (Some software isn't compatible with proprietary software. Our CMS, a proprietary product, only works with Internet Explorer, which makes it less functional.--jn) Choosing any solution may foreclose on other software. This opportunity cost may not be apparent for years when the need for the other software emerges.
By having open source code of your ils, the whole point is that someone should be able to write then code for that product that might not initially work. 3M hardware and Envisonware used SIP2 protocol that code was written for Koha as libraries who used these products came onto Koha and needed their pre-existing systems to work. (hb)
In many markets, there are major systems in accounting, intranets, e-learning, and so on that must tie in to the ILS. In many cases, open source is still the minority solution because, for example, the number of Linux desktops is meager compared to Microsoft Windows desktops. By choosing a Linux desktop, a user closes the door on some software because it may never be created for or ported to Linux. Add to this the major changes in allied systems that require an adaptation for the ILS and the issue grows exponentially. (lots of open source software works on propritary operating systems: Evergreen, Koha, Firefox, OpenOffice, etc., chosing an open source ILS has nothing to do with chosing to use Linux on a computer -tr)
So for libraries that choose an open source system, the opportunity to integrate different systems into the solution is limited, at best. (... if their parent insititutions choose only proprietary sourced software ...if the parent institution is open to OSS then this is not a problem. The OLE project created guidelines for an OS ILMS for large research libraries designed *specifially* on SOA principles so that it can integrate with other systems like financial and student records) kg
SaaS
Real cost savings in the ILS come from improving the architecture of the whole system. This can be done through Software as a Solution (SaaS), where a proprietary software developer like SirsiDynix hosts a library’s ILS and takes over responsibility for upgrades to hardware, updating, backup, and hosting activities. (open source ILS vendors offer the same service - hosting along with responsibility) -nce
The emergence of SaaS is growing very fast across all types of technology-dependent industries. It is cost effective, more flexible, and delivers significant benefits than traditional software installations, with few downsides.
This can result in total cost of ownership savings of nearly 50 percent. With the best professional hosting facilities availableCitation needed. -ljh , SirsiDynix operates on a global basis. From the point of view of the end user, the ILS workflows and the Online Public Access Catalogue (OPAC) are invisible and are truly adaptable to the Internet. "Truly adaptable to the Internet."? I don't know what that means. -ljh (I'm not sure that libraries *want* an invisible OPAC - and they definitely *do* want pervasive URLs) kg
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. Citation needed. -ljh Some open source SaaS services are hosted on servers in a small vendor’s office, which are not professional hosting solutions and come with extremely high risk to the library.
I believe LibLime, one of the Koha vendors, uses Amazon Web Services to host all their customers. Isn't that a professional hosting solution? (hb)
Georgia PINES, SIKTA (and likely other consortia) are SaaS the servers are maintained in a central location so that indidivdual libraries don't each have to do server upgrades.
ByWater Solutions has full-time professional hosted solutions and professional database centers using the cloud computing format- with redundant backup procedures.
Features and Functions
When one is evaluating the differences between open source ILS and proprietary ILS, the theories need to be overridden by practical applications.
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. (I admit I have not used Sirsi before - but the other systems I have used had very few of these things - maybe just security. I know that you can't lump all proprietary systems together - just like you can't lump all open source systems together)-nce The use of agreed international standards is essential to using the wide range of third-party products used in libraries as well as any that may be considered in the future. (Some examples of Horizon's stellar functionality--not specifically standards related but...--broken media bookings module, inability to generate RSS feeds of new items, inability to automate recalls, don't even get me started on the OPAC -tr)
Generally, the available open source ILS platforms have less than half of the features and functions of any SirsiDynix ILS.Some of these features and functions may not be essential to some clients, some will be. However on this order of scale, and with that potential number of needed features, SirsiDynix has the ability to offer libraries the most robust feature set on the market. It becomes incumbent on the library’s decision-making process to clearly outline what they are giving up or planning to develop on their own if they choose to go open source.
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 SirsiDynix had in the 1980s. Citation needed. -ljh How many years will it take for them to achieve a full feature set, if ever?
Proprietary software has more features. (does this count all the "features" that never really worked and the ones that have been broken and buggy for years and are not being fixed...-tr) Period. (A statement like this needs some facts to back it up.--jn) Proprietary software is much more user-friendly. (again, give examples of this. i hear daily complaints from staff who think the circ, cat, acq, and serials modules suck -tr) (learned helplessness plays a part here - library staff adapt their practices to the system, not vice versa, then get used to working in this way)kg (My library uses Sirsi-Dynix, & we regularly get complaints from patrons about the OPAC. Our response is always, "Unfortunately, we don't have the control over it we'd need to fully customize it, so we can't make the changes you want to see."--jn) SirsiDynix has been building this ILS for more than 30 years. It has a feature set second to none. It is important to note that a SirsiDynix ILS has two main user groups – the library workers who process the resources for the library as acquisitions, cataloguing, circulation, ILL, etc. and the end-users who use the OPAC features and other add-ons like self-check. Open source software developers are spending the majority of their time and resources on getting the back room operations right, 30 years after we already completed the process.(Proprietary software has backroom operations automated, whether it is "right" needs to be backed up by evidence)kgCitation needed. Also, I call shenanigans. -ljh
Customization
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. Much of the desire for customization comes from Innovative Interfaces Inc. (III) clients. However, III has a long history and tradition of not allowing its clients to write APIs to the underlying data and fields in the ILS. Citation needed. Also, this looks like libel. -ljh
Meanwhile, SirsiDynix consultants have written custom API programs since the company introduced the Application Programming Interface (API) nearly 20 years ago. Other proprietary software companies like LibLime and Equinox have always offered customization to their clients.
Even with all the disagreement over LibLime Enterprise Koha, I think LL and definitely Equinox would disagree with the "propriety software company" title given above. (hb)
However, it should be stated that customization is not without risk. Extensive customization, especially with potentially little or no documentation can make upgrades and changes increasingly difficult. SirsiDynix mitigates this with our API training as well as the option to have our consultants to review APIs for errors and bugs.
In the open source world anyone can make significant changes to open source code. This is often presented as a great option to management who don’t completely understand the consequences of too much customization. Too much source code change can result in completely new versions that are neither forward nor backwards compatible with the innovations of the overall open source community. (which is why there are internal checks and balances in the community of committers to avoid this happening) kg Rogue programming teams may decide to create a better version, while exclaiming “Damn the torpedoes.” (and rogue elephants may trample your library shelves going "pppppprrrrrrmmmph" , but - without evidence of frequency or severity of risk - mentioning either point is not useful) kgThe result is that the relationship to the core kernel of the software can be broken or made ‘odd’. In some of the big open source communities, there is an individual or group who gives permission to make change in the software. For example, Linus Torvalds, the genius behind the Linux platform, is materially involved in every Linux code addition to protect the kernel.
Customization can be a risky undertaking. Again, customization comes with the caveat emptor warning. (This isn't an open source issue. The CMS we use at my library is a proprietary system. When we first purchased it, it didn't suit our needs out of the box, so we paid extra to have it customized. Now we can't upgrade the CMS without essentially doing our websites all over again, because the customizations we paid for made that version of the CMS incompatible with later releases.--jn)
Libraries considering an open source ILS should seriously review how they handle version control and customization, as well as who handles the responsibilities and contracts for customization. (these libraries should also include in the review how customizations to propreitary software happen - does it involve voting in user groups with no guarantee that essential modifications will be included in the next version, or ability to just take some customisations, not a whole bundle in the next upgrade ?) kg If they don’t, they may end up being an outlier or be forced into a proprietary environment like Red Hat.
Security
Open source is often represented as more secure. This, too, is debatable. 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.
The DoD recently clarified its position on OSS, stating it is on legal even footing with proprietary software, and emphasizing its strengths in adapting to a quickly changing environment. In April 2009, the DoD launched Forge.mil, a hub for contractors and developers to share software and network solutions. This came in addition to an agreement with the Open Source Software Institute to facilitate greater streamlining of software solutions across other departments and government agencies. (sources: http://www.readwriteweb.com/archives/us_department_of_defense_embraces_open_source.php; http://www.scribd.com/doc/21762380/DOD-Open-Source-Rules; http://www.networkworld.com/news/2009/042709-military-open-source.htm) -- Toby Greenwalt, public librarian, theanalogdivide.com (Can we also mention that the White House just switched to Drupal for its website?--jn) (very good point, Josh; I think we definitely should. hb)
It is not an accident that SirsiDynix ILS systems and SaaS operations are the choice of the U.S. military – possibly the most security- conscious environment in the entire world. (When the US military purchased an ILS, what open source alternatives were there? When did the US military choose Sirsi-Dynix?--jn) And the Government Printing Office uses Aleph, and they made their decision pretty recently (like 2005 or something? I think it went live in 2006.) Does it matter that a branch of government has picked one ILS over another? -ljh
In open source, anyone can release code. (Anyone can write code, but different open source projects have different processes and standards for which code gets applied to the trunk.-tr) But extensive testing is needed to ensure those codes are secure. With open source projects, you can see exactly what the state of testing - manual and automated system / regression / unit testing - consists of, good or bad. With proprietary products, you have to take the vendor's word that they actually do test. As a former Unicorn customer who suffered through regressions between 2003.1.4.5 and the GL3 release, such as corrupted diacritics in overdue notices and linking orders to the wrong bib record, I hope SirsiDynix has improved their own QA process. But customers have no way of actually knowing. dbs 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. How many is enough, then? Has SirsiDynix counted how many developers and testers are involved in the community of each open source library project? Can SirsiDynix provide a fair comparison to the number of developers and testers that are devoted to each of their own proprietary library projects? dbs
To date the ILS has not been a target for security threats, although associated systems for servers and communication have. This may change if a large installed base of open source ILS platforms emerges. Does the iLink OPAC still pass the user's password around in a hidden form variable over plain HTTP by default? Does Unicorn / Symphony still pass all of its traffic between the server and the staff clients over the network in plain text? Does Unicorn/Symphony still store passwords unencrypted in its database? Because let me tell you, none of that is secure. By way of comparison, Evergreen uses SSL encryption for all staff client communication, and for OPAC sessions when the user has logged into their account and wants to review their account information. Evergreen encrypts its passwords when they are stored in the database, reducing the chance that a disgruntled employee could collect the passwords of an entire library's set of patrons and use them to wreak havoc months later. The state of the art in security has advanced a long way in the past twenty years, and while most products have security vulnerabilities, the least a product can do is start with reasonable default settings out of the box. dbs
Networking
Some open source vendors claim that open source is more network-friendly and relies on the Internet and other networks for its performance. Unfortunately for the ILS community, this is a grossly over-stated exaggeration.
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. In fact, SirsiDynix SaaS solutions are world class (what does this mean? -tr) , and our references in consortia and large complex accounts demonstrate the ability of a SirsiDynix ILS to perform on a network scale at excellent performance. This is just a claim without any real data. Sounds like it's time for some objective information: we need to set up an independent library benchmarking organization like tpc.org who can actually measure performance using the same hardware on the same networks using the same data sets and the same workloads, rather than rely on claims from anyone. dbs
Open Formats
An open format is a published specification for storing digital data, which basically can be used and implemented by anyone. For example, the format is interoperable among diverse internal and external platforms and applications.
The argument by the open source community is simply that open formats are better. SirsiDynix agrees. We try to use open formats and international standards as much as possible. Ideally, this would be all the time. But the reality is that open formats are not always the most “open” to formats that a host city or institution uses. It is our opinion that the ILS works with the formats that are needed by their clients rather than engaging in missionary work for greater openness.(Open standards make economic sense and the demand for these formats is driven by being financially responsible) kg
Data management and migration highlight a number of these issues. Open formats are helpful in this area but even accepted standards like MARC have many legacy issues, data quality repair issues, and a company like SirsiDynix has infinitely more experience in migration and implementation issues than any new vendor, open source or not. 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.
Why did those alumni leave SirsiDynix (not necessarily good for the response, but legitimate question)? (hb)
Necessary Expertise
Is open source harder to deploy? All software solutions require some expertise to deploy, secure, and maintain. Some open source software is technically challenging and requires considerable expertise. This is a particularly important point in the library market where there is rarely a large systems department with a variety of programming levels and skills quickly available internally.
Libraries considering open source should clearly evaluate the skills required. This might involve hiring an expensive consultant (or investing in buiding those skills in libraries. also--S-D's consultants are not expensive? WTF -tr) . (not to mention the cost of training a local library staff member to use the SIRSI data tools.-hb) 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. Having managed both Unicorn and Evergreen, the problem usually boils down to "How do I configure things so that it does what my colleagues want it to do?" In both cases, I've also had to develop extensions to make the system do what I want it to do. So, how is this different? dbs Application programming is different than development programming. I'm a developer. I've developed proprietary software and open source software. I don't understand what this sentence means. What is the distinction between "application programming" and "development programming"? dbs
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. Okay, so I take it that "application programmers" are limited in scope by what they can accomplish (due to the software they're working with, perhaps?), while "development programmers" have the ability to extend their system without limit - possibly with an understanding of how to work in a community towards shared goals. dbs These people are extremely rare and cost more. And most libraries cannot cover the salaries required to retain the talent they need. (they find $$$ for proprietary software licenses each year. If they didn't have to pay this, then what could they do with these funds?)kg 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. (same argument could have been made about library webmistresses 15 years ago - skills needed to run our libraries change)kg
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. (again, needs examples -tr) There is *one* well know example of this - but there are many, many more examples of programmers who have joined library Open Source projects from other environments) kg
Testing
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, managed protocols, and testing with partners. We certify some third parties using actual tests to ensure that the customer experience is as seamless as possible. We test for scalability and for the stress of large numbers of users. We test for all major browsers. We test on all supported servers and operating systems. We test aggressively and well. We test at every step of the development process. We do all of this before we have actual clients partner with us to beta test the pre-release candidates. Over the past few years our product has arrived in new releases with a higher standard of performance and more features than ever before. We have released 20 major releases and upgrades in the past two years on time. (but are the features being tested those that the clients actually want, delivered in a timeframe they want them? without this, then tests are not useful)kg These are all just claims with no evidence to back them up. Just trust SirsiDynix, right? dbs
This is not the pattern that open source initiatives follow.Citation needed. -ljh Testing is the responsibility of the original programmer and their buddies. Well, no. This is untrue of many, many open source projects. Many projects have adopted "test-driven development" as a development method. It's one of the methods I adopted to develop the File_MARC PEAR library for PHP, for example. And there are unit tests in open source library systems - check the MFHD code or the internationalization code in Evergreen; and I know Koha has a suite of unit tests as well. Sure, there could be more automated tests, and indeed there is a lot of work going towards enhancing the test infrastructure in Evergreen. dbs Then the philosophy is caveat emptor, or “Installer beware!” And the testing heavily falls on the early adopters. Just like with proprietary software, where on the Unicorn mailing lists everyone hangs back in fear waiting for other customers to adopt the latest release and report back on the results, because nobody trusted SirsiDynix to put out a quality release. dbs
Yet, when reviewing the list of bugs in the open source ILS software as compared to the same bugs for the proprietary software, investigators have to go back decades in the list to find the same bugs open source platforms are fixing today. Independent investigators can't review the list of bugs in your proprietary software, so only the open source ILS software bug reports are exposed for analysis. Does the Unicorn Apache module still have that memory leak that resulted in SirsiDynix suggesting that you restart the Apache server every night? Memory leaks have been around for decades, you know. Or how about that refusal to even start that would happen in Unicorn if you fed it overlapping closed dates for a given library? That was a fun one, and from only a couple of years ago. You can do some research on testing techniques like "black box testing" to help you unveil some of these bugs. dbs
This is evidence of a very young development program and the lack of real management in the process. Evidence requires evidence. dbs The open source process is too organic and lacks tight priorities and strong management oversight.(citation needed) kg Also, please tell IBM, JP Morgan, and other participants in open source development processes that they lack tight priorities and strong management oversight. Last I heard, they really like making money and investing in open source development helps them achieve that goal. dbs
Integration
Some argue that it’s difficult to integrate open source with proprietary solutions. (yes, you just did in the paragraph under the heading "Opportunity Costs", beginning " In many markets, there are major systems in accounting, intranets...")kg It’s always a professional task to make software work well.
The truth is that the software world will always be one of hybrid solutions (so, this is a different truth to the one above that told us we'd miss out because OSS cannot be used with proprietary solutions ?) kg. SirsiDynix has a long tradition of using open source in our solutions, properly tested and integrated (and in 2008 or thereabouts, you even started to comply with the licensing terms for the open source elements like Cygwin that you integrated into your products years before. dbs), as well as ensuring that our APIs and portal solutions allow for integration of any desired solution. We also ensure that these work with all of our ILS solutions, multiple platforms, operating systems, servers and browsers.
Community-driven
“Open source exists because a large community of motivated, generous programmers work together. Some are corporate employees, but open source development thrives on volunteers. Even users without programming or other technical skills find ways to help by filing bug reports, writing documentation, or answering questions on email lists.” (again, citation needed, Google says this one is from http://www.netc.org/openoptions/pros_cons/principles.html -tr)
There is no difference between this assertion about open source and the SirsiDynix approach. (depends whether by "programmers work together" you mean "programmers work together on source code" or "programmers work together sharing workarounds")kg Indeed we have many decades of experience in tracking development suggestions and requests and testing, reviewing and replicating bug reports from programmers and users alike. 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.
Scalability
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. (pot, kettle, black! -tr) Yes, this software can be ‘consortially aware’ without any of the attendant performance (One didn’t even support the Z39.50 international ISO standard until recently! 1. Features are not performance. 2. That one (Evergreen) didn't need Z39.50 server functionality (it always had Z39.50 client functionality) because it was developed for consortial sharing between the 250 libraries that it was originally developed for. 3. And look - a new adopter of Evergreen needed Z39.50 server functionality like the export of holdings in a VDX-compliant format, worked on it for a few weeks, and contributed it to the Evergreen project. That sounds like a really good example of how the open source process can work - thanks for pointing that out. dbs.) Having been designed for a single consortium such as PINES, does not guarantee that the software will work for another consortia’s needs, particularly with the diversity of needs and variety of system architectures that exist in a fully dimensional marketplace. (but when you have them working in the installations listed by hb above, *that* is a better guarantee )kg
If clients are concerned about their ability to scale they should check the actual performance of the ILS in actual complex and consortia environments. The PINES system is actually a very poor performer at its current scale of small public libraries. For example, all large library systems in Georgia have generally decided to stick with SirsiDynix. In fact, several library systems in Georgia have declined the use of the Evergreen system specifically due to scalability and response times. One tester of that system wrote, “Slow response time in Evergreen Staff Client. This includes unexpected "crashes" and "frozen" screens which may or may not be due to response time lag. This problem causes extreme delay and long lines at Circ Desk and results in both major staff and patron frustration.” (citation needed) kg
also, what are the ratios of small public libraries to large public libraries? Which set of numbers is larger? If there were more large public libraries (and other types, as well) around the world, this might be a legitimate point; however, I think there are a lot more small libraries out there, with very limited budgets; for someone with a $20,000 annual budget for everything, I'm sorry, but SIRSI is not an option, nor ever will be an option.
SirsiDynix encourages libraries to visit our large-scale clients and see the sub-second search performance on 10’s of thousands of users. Such SirsiDynix Symphony clients as the Toronto Public Library, Alliance Library System, Los Angeles County Public Library, and more enjoy very strong and stable performance. This is not the case with the small libraries of Georgia who are captive to sub- optimal open source systems. Indeed, despite stating that they were built for consortia, simple consortia features are not available or supported. Add to this the even better performance and TCO improvements of the SirsiDynix SaaS solutions and we offer a much better solution with significantly superior performance.(citation needed)kg
Speed
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.
Our stress testing is done on the professional stress testing facilities at Sun Microsystems, Microsoft and UNIX servers. We test at 50,000 users per configuration for over a week. We use advanced automated testing procedures that cost money but deliver a definite positive result and tell us where to invest time in improving the performance of our software.
In addition we also test for all major browsers and try to ensure compliance with all standards and browsers evident in our market. This includes PC and Macintosh.
This has not been the case in the open source ILS systems. If anything, one of the major complaints by users and clients is that it is so slow. Here, the writer paints all installations of all open source ILS systems over the entire span of time with the same brush. Our 2.5 million bib record Evergreen system runs pretty snappily. I've seen Koha systems that run fast, too. dbs Simple searches in PINES can hang for minutes, resulting in the ‘searching...” bar popping onto the screen to encourage user patience. (Where is this information coming from?--jn) This is unacceptable in ILS software, which is why we test our system so rigorously.
Reliability
Finally, one of the biggest claims of open source proponents is that it is more reliable. (citation needed - I've not found this claim in the literature) kg Our Evergreen instance has a 99.5% uptime, including outages for system maintenance, since July... and that number is rising. Our Unicorn instance had a maximum uptime of 75% because it was down for 8 hours every night for backups. That's not a particularly fair comparison - we're using different hardware and different operating systems and different backup strategies - but that's what we have. dbs They argue that since any programmer can find and fix bugs, the software will be repaired and improved more quickly. (easy to repair != reliable)kg There is, however, no guarantee that the bug you want fixed will engage a member of the community to fix it.(It will be if your library is using funds saved on proprietary licenses to hire a staff member capable of doing this)kg A bug fix can work in one environment and not others and the testing is up to each individual organization in open source. Well, and SirsiDynix doesn't test every bug fix on every environment in every individual organization either, do they? dbs
With open source, the advantage depends on the participation of enough competent programmers who are deeply committed to the entire development process. Without enduring, sufficient, talented interest, an open source project is doomed to fail, and many do. Without enough customers, or without enough revenue, a proprietary project is doomed to failure, and many do. Difference being that an open source project can continue to be maintained and enhanced by even one library in a corner of the world because the source is available. dbs
Unfortunately for the open source proponents in the ILS community, there currently isn’t a critical mass that is demanding the development of open source software. At this point in time, the open source community for ILS software is tiny.
Therefore, the reliability of ILS software developed on an open source platform is questionable. (demand is tiny != unreliable)kg Just like proprietary software, the reliability of an open source program depends on clear feedback after rigorous use in a variety of environments. But that simply cannot be the case at this point in time because the variety of environments is small (Conifer alone includes hospital libraries, mining industry libraries, small community organization libraries, French college libraries, and three universities ranging in size from small to large and including one bilingual university. That's a good bit of variety, isn't it? dbs), and the critical mass needed has not been reached. (but isn't this an argument *for* libraries to work together to make sure this critical mass is reached?)kg
Open Source and Libraries
Although many in the ILS industry are taking an in-depth look at the viability of open source development over the long run, we believe the movement is premature. Moreover, we are joined in our opinion by none other than Cliff Lynch, the head of the Coalition for Networked Information and a leading thinker in the library space.
Cliff called the development of the open source ILS by OLE, Pines, etc. one of the “stupidest strategies ever undertaken” in the library world. (Citation please, Mr. Abram?) (Logical fallacy: Appeal to authority. Just because Cliff Lynch said this doesn't make it a fact. It's still just his opinion & not relevant to this document.--jn) (Also, Lynch clarifies this "quote" & his position here: http://www.librarytechnology.org/blog.pl?ThreadID=134&BlogID=1)At a time when libraries should be investing in systems to improve the priority issues in the end-user’s research, discovery and learning experience, here we have a cadre of libraries investing in the reinvention or at least, recreation, of something they already have and have at a cheaper cost than the redevelopment effort. (and another cadre investing in Open Source discovery layers like VUFind, Blacklight, SOPAC2, Scriblio, eXtensible catalog - because it is the most effective development environment )kg
In addition, these projects do not have a compelling vision of what the end result will be and appear to be driven by library workers’ desires rather than institutional strategies or end-user needs. (do we have a compelling vision of what the "end result" of our collection development will be? The ILMS is an evolving entity, just like our libraries)kg As such, they are tying up resources in an open source ILS effort at a time when budgets are constricted and other priorities are much more important and strategic.
Our patrons in our consortia love the Koha interface; Liz Rea, the NEKLS network administration took the responsibility to customize our templates on http://catalog.nexpresslibrary.org. The SIRSI interface when we were part of the KC consortia was BEYOND awful (but has since changed). hb
SirsiDynix on Open Source
SirsiDynix is not de facto against open source. We use open source software a great deal in our development efforts, in our software and in our company. We easily support clients using the poster children of open source software – Linux, Apache, and Firefox. We have done so for many decades. Simply put, it’s a good solution when it matches the needs of our clients.
SirsiDynix has been an early leader in building more open library management systems and indeed, being more open to even greater integration. This is especially true in the user experience end of our products where clients have added hundreds of applications onto our OPAC easily using our API strategy. And now they're locked in to your product via those proprietary APIs. Caveat emptor!. dbs We also have a very long track record in being open to our customers with beta tests, discussion forums, user groups, feedback mechanisms, and more.
However, SirsiDynix has also been in the ILS industry since 1979 and has developed the best-in-class solutions year-in and year-out. We’ve led the development of some of the most advanced features and capabilities of ILS platforms. So we know a thing or two about what it takes for library systems to be successful. Shouldn't more competition - particularly from a more nimble developer base - help you continue to refine your product and solidify these claims? (tg)
While we encourage the development of open formats, we must discourage libraries from jumping headlong into an open source platform to operate their ILS system on. At the current production cycle, jumping into open source would be dangerous, at best.
Caveat emptor! (<---- IRONY!)
Further thoughts (hb):
- What published reasons are out there for why libraries are choosing open source ils software? I'll see if I can find any and add them here.
--- I haven't published it all yet - but I am keeping survey results for my next book - find some of them here: http://opensource.web2learning.net -- nce
- One of the best parts about Koha has been that tiny libraries that need an affordable ILS system that works, has some type of standards, and is web-based, are finally able to have one, unlike some of the software I've seen a couple of our libraries use that doesn't use MARC at all and completely dies all the time. We have two communities in our system that have just started local libraries and we have put them on their own stand-alone Koha systems. It has been highly beneficial for them in so many ways. They could only afford these Library in a Box (blanking on the proper name right now) type software, and it wasn't really a true library software. They can't afford SIRSI, let alone Follett or Winnebago proprietary software. Also the smaller proprietary ILS software that is out there is basic and not robust and was mainly created for school library use, not as public library software. Koha is great for meeting the needs of different types of libraries. It can be as basic as you need it to be or is working toward being as complicated as you need it to be.
"Today,
we see that happening when libraries get into talks about moving their
Integrated Library Systems to open platforms systems. What we have
found is that they often are not aware of the heavy drawbacks of what
open source systems cannot offer at this point in time."
Is it just me or does this seem to imply that any library that has chosen an open source ILS solution made an uninformed and...perhaps stupid decision? - LJH
It's not just you... this opening salvo pretty much means if you pick open source you don't know what you're doing. kgs
Most choices taken by most people about most things are not taken with sufficient knowledge or understanding of details needed to take a well informed choice. However, there are no drawbacks intrinsic to open source software relative to closed source software or free software relative to proprietary software. Proponents of particular choices should concentrate their efforts on describing the merits of their own preferred choices and not denigrate a software paradigm for which they do not present sufficient understanding for well informed criticism. - TD.
"The concept of open source is fairly misunderstood and quite vague. Most
organizations courting the idea of open source development do so
because they feel they can project their dreams and desires onto a
blank slate and have the features they want sitting at their fingertips
quickly and easily."
"This is a misunderstanding of how open source software development works. By definition, 'Open source is an approach to the design, development, and distribution of software, offering practical accessibility to a software's source code.'"
Nevertheless, it should be noted that it is rare for completely open source projects to be successful. 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.
Generally there will be significant limitations to the hardware and operating system options. This limits the ability to cooperate consortially or share resources with host cities or institutions that may use a different standard. The library is at risk of being an island in the community.
Some
software isn't compatible with open source. Choosing any solution may
foreclose on other software. This opportunity cost may not be apparent
for years when the need for the other software emerges.
"In many markets, there are major systems in accounting, intranets, e-learning, and so on that must tie in to the ILS. In many cases, open source is still the minority solution because, for example, the number of Linux desktops is meager compared to Microsoft Windows desktops. By choosing a Linux desktop, a user closes the door on some software because it may never be created for or ported to Linux. Add to this the major changes in allied systems that require an adaptation for the ILS and the issue grows exponentially. So for libraries that choose an open source system, the opportunity to integrate different systems into the solution is limited, at best."