Choosing Kuali OLE

Beth Picknally CamdenUniversity of PennsylvaniaALA Heads of Cataloging June 2015

Kuali OLE: Making the Decision for Community-Source Software

1A community within a communityPart of the Kuali Foundation Designed for libraries by librarians!KOLE is building to meet the following requirements:Flexibility in designCommunity ownership with an open source license and strong vendor supportModular Service-Oriented ArchitectureEnterprise-level integration

quick overview what is OLE?

OLE = Open Library Environment A community within a communityPart of the Kuali Foundation Building software and community for Higher Education Note about KualiCo >OLE has NOT gone commercial; each Kuali project is independent to choose path; OLE: stay the course thru release 3.0; new OS license; currently we are reviewing technology stack & long-term functional goals for release 4.0 and beyond

Designed for libraries by librarians!Designed by and for academic and research libraries for managing and delivering intellectual information.KOLE is building to meet the following requirements:Flexibility in designCommunity ownership with an open source license and strong vendor supportModular Service-Oriented ArchitectureEnterprise-level integrationSoftwareEnterprise Java with services middleware; Built to integrate & interoperate; A platform for library services

2OLE Partners and Implementations

U Chicago implemented summer 2014Lehigh implemented summer 2014SOAS implemented Spring 2015

Up next for implementation: Duke (winter 2015/16); Penn, Villanova (summer 2016)3OLE Governance

Board: Library directorsFunctional Council AULs; mix of IT, TS, others; role: scope of releases; functionalityTechnical CouncilIT ; role: infrastructure; architecture Subject-matter experts (SME) groupscloser to work; role: specs, testing, etc.

This is what community source development is about > Doing this as community -work involved-financial and people commitment4OLE Roadmap1.6 (May 2015)FY rollover; Internationalization; SIP2 2.0 (Q3 2015)ERM; GOKb integration3.0 (Q1 2016)Circ upgrades (bills, requests); authorities; MARC holdings; license editor; account queryhttps://www.kuali.org/ole/roadmap

5Case study SOASBloomsbury group of London libraries joined OLE In 2012BLMS Unified SpecificationCritical factorsEthos Collaboration Vision for Functionality Build, Commission or Buy?SOAS 2015 implementation

http://www.blms.ac.uk/development-of-our-lms-specification-part-1/ http://www.blms.ac.uk/development-of-our-lms-specification-part-2/

Credit to John Robinson Director of Library & Info Services, SOAS, U of London: Ethos: SOAS is committed to Open Access publication; principle of Open Data; This makes the use of Open Source software a logical choice. Concerns: vendor lock-in, preventing us from having full control over and access to our own data. our data is taken off-site and managed in an opaque manner. The contrast which Kuali OLE offers. Ownership of and control over our data remains with us.

Collaboration: Libraries are intrinsically collaborative and have been for many years. Inter-library loans, shared access rights, library associations have been around a lot longer than IT systems. Collaborating with other libraries to design and build systems is attractive, especially if we can share expertise and use the process to improve the way we work.

Functionality: The vision we have is that OLE is built on enterprise architecture which enables transparent, seamless and real-time data-exchange with the other systems in the enterprise with which the library system must interact. Open architecture of OLE has enabled us to configure a number of features.

"Build, Commission or Buy?: We did an options appraisal (a formal process in UK HE Governance, may also exist in US) to determine whether we were going to Build, Commission or Buy the software. Via a Horizon Scan method (comparing different systems against our functional requirement), we determined that Open Source/OLE was the best fit. This meant that Buy was ruled out. Joining Kuali was like any other membership arrangement. The procurement process from that point on was whether to Build (use in-house staff to put the system up) or Commission. We chose Commission and that meant that we got HTC via a recognized Procurement process. (We had to make the case for a single-vendor procurement because no other company at that time would have been able to answer an RFP.)

SOAS implementation 3rd overall; 1st outside of US6Case Study - PennOLE design phase OLE build phase2014 review of functionality2015 update must have listPlanning for 2016 Implementation

Key point: Penn made multiple decisions about OLE

Design phase 2008-09 (Mellon funded; led by Duke) Penn joined as partnerBuild phase 2010 (Mellon & Partner funded) Penn founding partner ; financial decision-staff participating on teams since then time commitment 2014 Penn review of OLE functionality looking at 1.5 in production (Chicago & Lehigh) and 2.0 scope-decision to delay implementation for another year2015 Penn updated must-have -landscape shift in 9 months-SOAS & Duke implementations-additional release 1.6 addressed a number of Penns concernsLaunching our implementation process with a target of July 2016 for go live (need to target FY change)-vendor support-support of OLE partners-local teams

7Rethinking the RFPSoftware functionality Software provider Software stackExit strategyDollars and sense

Open Source and RFP dont necessarily play well together. OLE is not a vendor; although we do work with vendors who can provide support and MIGHT bid on a RFP.

Molly Tamarkin blog post 2012 http://kualiole.tumblr.com/post/32887237076/rethinking-the-rfp

software functionality (okay, these are the boxes what does it do?) software provider: how enjoyable is it to work with them? how responsive are they to your needs? how do their customers get a seat at the table to provide input and to shape software development?software stack: how well do the component systems integrate with existing tools? if they dont integrate well, does working on integration carry you forward in new directions or tie you to a legacy system? how open is the environment to external development?breaking away: whats your exit strategy? how hard would it be to migrate to another system or to maintain your current system yourself without external support?dollars and sense: open source software isnt freewe all get this. But how do you want to pay to play? Do you want to write a check and get a support line? Do you want to build skills locally? Do you want a little of both?

If you choose OLE, you may not need an RFP (you already own the software)8You already own the software

How would your library make this kind of decision?

Open source vs Commercial -value of OS: real role in bldg the software; voice at the table -Integration with other tools that you already have; Your insts unique mix of tools, e.g. OLE did not build a discovery layer; you can keep your own (OS or Commercial)

-commercial lock-in; do you control your own data? Is it a black-box? Can you really integrate with tools (library or univ enterprise tools)?

OLE as communityLarge and small libraries; consortia; US and internationalPartners supporting each other

Vendor support of open source If you choose ; you dont need to have a large IT shop to go OS

9