Considering Community and Open Source

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

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

3. 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 Our context

4. 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?

5. 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 Campus Priorities

6. 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?

7. 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 Evaluating Campus Culture and Readiness

8. 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

9. 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 Architectural fit

10. 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?

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

12. 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 Picking the product

13. 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

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

15. 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?

16. UCLA Assist local community in working with larger community: mimic the process First priority is building shared processes within campus Engagement in the community 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

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

18. 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

19. 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

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