Kuali OLE: Making the Decision for Community-Source Software
•Transferir como PPTX, PDF•
1 gostou•710 visualizações
Presentation at the ALCTS Heads of Cataloging Interest Group June 2015. http://alaac15.ala.org/node/29195
Recomendados
Recomendados
Mais conteúdo relacionado
Mais de Beth Picknally Camden
Mais de Beth Picknally Camden (7)
Último
Último (20)
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
- 3. OLE Partners and Implementations
- 5. OLE Roadmap 1.6 (May 2015) FY rollover; Internationalization; SIP2 2.0 (Q3 2015) ERM; GOKb integration 3.0 (Q1 2016) Circ upgrades (bills, requests); authorities; MARC holdings; license editor; account query https://www.kuali.org/ole/roadmap
- 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?
Notas do Editor
- 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