Considering Community and Open Source A Decision Framework

Considering Community and Open Source A Decision Framework for Selecting Software Lois Brooks Stanford lbrooks@stanford. edu Terry Ryan UCLA tryan@library. ucla. edu

Decision Framework Product Evaluation Identity Management and Architecture Authentication: who are you? Guest Wireless Guest SUNet. ID Shibboleth Application Campus Readiness The Decision Network Workgroups Granular levels of access Signet Campus Priorities Authorization: Building you what are supportto do? allowed Engagement

Our context The UCLA story • Campus decision to converge on a common open source solution for learning and collaboration • Evaluated field • Reduced to 2 • Selected Moodle The Stanford story • Entered the Sakai project as a founding school and development partner • Considering Kuali Research Administration as an adopter

Campus Priorities • Both product and community must match campus priorities • Important for any software decision but especially crucial for open source. • Are there clear goals and priorities? • Do they match any existing open source products?

Campus Priorities UCLA • Driven by teaching and research collaboration requirements • Developer community with similar needs • Integration and customizability at local & campus level • Internal investment vs. turnkey solution Stanford (Sakai) • Driving features and requirements matters; already committed to build • Cost leveraging is compelling • Drive product features thru contribution vs receive thru adoption • Internal investment vs turnkey solution

Evaluating Campus Culture and Readiness Is the campus ready to be part of a community, and what kind of community is the best fit? • • Available staff skills and expertise Value of collaboration for its own sake Vendor and internal integration requirements Community/vendor evaluation; interest in engagement Regulatory requirements Decision making and governance Funding process Opt-in or mandate?

Evaluating Campus Culture and Readiness UCLA • No single entity charged with supporting this • 26 separate systems, some feature rich • High user expectations • Need quick wins for buy -in, license deadlines • Divergent processes; little shared experience Stanford (Sakai) • Existing system heavily used; needed update • One organization supporting • Mandate for smooth transition Research administration • No system • Huge need • No mandate to use

Architectural fit • Do the products fit with institutional goals? Is the ante higher for open source? • Are some products a better fit than others? How will you compensate for weaknesses? • Considerations include: security, hardware and software environments, system administration harmony

Architectural fit UCLA • Single sign-on, Shibboleth aware • No campus application architecture • Decision factor was time to develop new functionality vs. framework for integration Stanford (Sakai) • Single sign on, Shibboleth aware, fit with hardware platform • This is part of a larger whole, catalyst to make campus architecture emerge • Abstraction of service layers, e. g. , storage, middleware

Picking the product • Software is software • What are the key assessment criteria for your campus? • How will you evaluate against the criteria? Will you use current or anticipated versions? • Learning how products work in practice: installation and pilots, vendor supported trials, other schools with similar scope and scale • Focus on key discriminators. What will you need to believe to select one over another?

Picking the product UCLA differentiators • Product maturity • Peer institutions • Ease of use • Accessibility • Suite of functions • Extended language support UCLA non-differentiators • Scalability • Integration with campus systems • Ability to swap components (UI, DB) • Many core functions

Picking the product Stanford Research Administration • Determined functions, e. g. , proposal and grant tracking, conflict of interest • Choice of accepting or building: – Product lifecycle – Interest in getting to features quickly; negotiated with vendor for additional features

Building and sustaining enthusiasm and support • Open source takes commitment; resources are vital; be realistic • How will you nurture and sustain support? • Selling in every direction • Listening to end users, developers, and the community (internal and larger) • Outreach to faculty, students and staff

Building and sustaining enthusiasm and support Project Team Campus Adopters Working system begins to realize potential Heady days of early Using system effectively engagement Deployment grind Adoption blues

Engagement in the community • Decide if you will be a silent adopter, an influencer or a doer • Community source about community governance and coordination, open source about contributing to the product • Interest, patience and discipline to work with the community and its priorities • Readiness to change process to fit product • Committed to community code and standards or expect to go your own direction?

Engagement in the community UCLA • Assist local community in working with larger community: mimic the process • First priority is building shared processes within campus Stanford (Sakai) • Wanted to drive features to start, but a keen interest in adopting others’ work • Now need to involve larger Stanford community in Sakai

Decision Framework Product Evaluation Identity Management and Architecture Authentication: who are you? Guest Wireless Guest SUNet. ID Shibboleth Application Campus Readiness The Decision Network Workgroups Granular levels of access Signet Campus Priorities Authorization: Building you what are supportto do? allowed Engagement

The Decision is Made: Don’t stop now… • Getting to a complex decision with campus support is a vast undertaking • But it pales compared with what it takes to make your choice successful • Consider a combination of approaches -build, buy, borrow, contract, out source, etc. • Focus on interoperability as a mitigating strategy, getting real value from the investment • Exit strategy

Ripple Effects • What we’re learning now that we’re into it • Creating campus architecture; opening discussions and interest • Focus attention on enterprise level academic systems • Community/open source as staff development, both technical and soft skills

Thanks! What’s on your mind? Terry Ryan, tryan@library. ucla. edu Lois Brooks, lbrooks@stanford. edu