Exploring the Future Potential of AI-Enabled Smartphone Processors
Kuali OLE: Making the Decision for Community-Source Software
1. Beth Picknally Camden
University of Pennsylvania
ALA Heads of Cataloging June 2015
Kuali OLE:
Making the Decision for Community-Source
Software
2. A community within a community—Part of the Kuali
Foundation
Designed for libraries by librarians!
KOLE is building to meet the following requirements:
Flexibility in design
Community ownership with an open source license and
strong vendor support
Modular Service-Oriented Architecture
Enterprise-level integration
6. Case study – SOAS
Bloomsbury group of London libraries joined
OLE In 2012
BLMS Unified Specification
Critical factors
Ethos
Collaboration
Vision for Functionality
Build, Commission or Buy?
SOAS – 2015 implementation
7. Case Study - Penn
OLE design phase
OLE build phase
2014 review of functionality
2015 update “must have” list
Planning for 2016 Implementation
8. Rethinking the RFP
Software functionality
Software provider
Software stack
Exit strategy
Dollars and sense
9. You already own the software
How would your library make this kind
of decision?
Notes de l'éditeur
quick overview – what is OLE?
OLE = Open Library Environment
A community within a community
Part 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 design
Community ownership with an open source license and strong vendor support
Modular Service-Oriented Architecture
Enterprise-level integration
Software
Enterprise Java with services middleware; Built to integrate & interoperate; A platform for library services
U Chicago – implemented summer 2014
Lehigh – implemented summer 2014
SOAS – implemented Spring 2015
Up next for implementation: Duke (winter 2015/16); Penn, Villanova (summer 2016)
Board: Library directors
Functional Council – AULs; mix of IT, TS, others; role: scope of releases; functionality
Technical Council—IT ; role: infrastructure; architecture
Subject-matter experts (SME) groups—closer to work; role: specs, testing, etc.
This is what community source development is about –> Doing this as community
-work involved
-financial and people commitment
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 US
Key point: Penn made multiple decisions about OLE
Design phase 2008-09 (Mellon funded; led by Duke) – Penn joined as partner
Build 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 year
2015 Penn updated “must-have”
-landscape shift in 9 months
-SOAS & Duke implementations
-additional release 1.6 – addressed a number of Penn’s concerns
Launching 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
Open Source and RFP don’t 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 don’t 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: what’s 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 isn’t free–we 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)
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 inst’s 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 community
Large and small libraries; consortia; US and international
Partners supporting each other
Vendor support of open source
If you choose ; you don’t need to have a large IT shop to go OS