Koha versus Evergreen

This posting is intended to capture your thoughts on the pros and cons of each platform.

We'll update the lists based on your comments (those of you with edit rights to this document can just add your pros and cons directly).

PROS

Evergreen

  1. Originally developed with consortia needs in mind;
  2. Majority of current customers are consortia-based, so these needs continue to push the development;
  3. Existing implementation (Georgia Pines) at a scale similar to any one of our networks;
  4. System architecture designed with scalability in mind;
  5. Nelinet planning to offer training and support on this platform;
  6. Evergreen FullfiLLment project (a potential alternative to URSA) recently funded by State Library of Ohio;
  7. King County Library System funding considerable development for software requirements "suitable for many large, urban, multiple-branch, centralized library systems."
  8. Other?

Koha

  1. Client functions run entirely within a browser (and, therefore, the system doesn't require any client updates);
  2. System's browser-based architecture more in line with overall software industry development (and, therefore, an easier platform for outside developers to understand and work on);
  3. Growing community of developers and support vendors (perhaps due to #2 above);
  4. Software and, perhaps, community slightly more mature (project started earlier than Evergreen);
  5. Community very international resulting in quick translations of the software;
  6. Evidence of a growing base of consortia "customers;"
  7. Heavy adoption in India, a country with extensive IT resources;
  8. MassCat's platform;
  9. Other?

CONS

Evergreeen

  1. Requires client software;
  2. Doesn't currently support pushing client updates automatically from the server, although updates could still be pushed using 3rd party tools;
  3. Some complaints that the platform as implemented in Georgia is slow (but it isn't yet clear whether this problem is caused by factors that are more easily correctable - i.e., hardware and area network configurations, etc. - or whether the problem is more insidious - i.e., poor underlying software design, network packets that are too many and too large, too many parameters, PostgreSQL issues, etc.);
  4. Poor documentation;
  5. More difficult to install than Koha (partly due to poor documentation);
  6. Other?

Koha

  1. Consortia needs haven't been a focus during early and recent development;
  2. Many current features can't be implemented well (if at all) in a consortium environment;
  3. Upcoming development (such as new acquisitions module) still lacks certain consortia-friendly features;
  4. Majority of current "library customers" are small and/or independent rather than large and/or consortia-based;
  5. History of platform forking so that development isn't always getting plowed back into the core;
  6. Strong potential for Indian development to fork since they've had little contact with original developers and don't need IT support;
  7. International aspects of Koha community can potentially divert development from U.S. library needs and/or make new releases less relevant for U.S. libraries than they otherwise would be (a focus on UniMARC, for example);
  8. Other?