Choosing The Right Open Source Project

1. Choosing The Right Open Source Project Scott Leslie, Edutools.info CADE, May 10, 2005

2. You are here? Outer Hebrides?

3. The Hype • Depending on who you ask Open Source represents • Greatest thing since sliced bread • The cure to all your ills • The Next ‘Insanely Great’ Thing • Salvation • The ONLY Way Forward • A threat to the Canadian way of life

4. Promises of Open Source • Get the solution you want; greater pedagogical flexibility • Avoid Vendor Lock-in • No Perpetual License Costs • Control over Product Development/Release Cycle • Increase Operating System and Other Platform Flexibility • Non-Proprietary/Open Standards

5. What this Presentation Isn’t • Not a presentation on the value of adopting open source • For some good work in this regard refer to • Chris Coppola, “Will Open Source Unlock the Potential of eLearning?” http://www.campus-technology.com/news_article.asp?id=10299&typeid=155 • Randy Metcalfe, “Software Choice: Decision Making in a Mixed Economy,” http://www.ariadne.ac.uk/issue42/metcalfe/ • Patricia Gertz, “Open Your Eyes: Open Architecture, Open Source, Open Projects,” http://www.educause.edu/content.asp?page_id=666&ID=MAC0510&bhcp=1 • Coppola and Neely, “Open source - opens learning,” http://www.opensourcesummit.org/open-source-200408.pdf

6. What this presentation is • ‘Open Source’ is a moniker applied to a HUGE variety of software projects • Not all Open Source projects are equally suitable to every institution • Details an effort to develop a framework to understand OS project suitability in relation to institutional capacities • Want to help people in choosing the right/appropriate OS projects

7. About Edutools – http://www.edutools.info • Site dedicated to assisting decision makers in higher education • Past claim to fame the CMS comparison site • Originated with BC-developed ‘Landonline’ site • Redeveloped in 2001-2 with funding from Hewlett foundation • Scope expanded to include comparative analysis of e-learning policies & other student service technologies, and recently Learning Object Repository technology

8. Defining Open Source • Fundamental to definitions of Open Source are a set of freedoms enabled by a software license • Freedom to • View and learn from source code • Distribute copies • Use the software for any purpose • Modify and Share the modifications • Cf. OSI’s Definition of ‘Open Source’ - http://www.opensource.org/docs/definition.php

9. Definition very much centers around freedoms of what you can do with the code BUT…

10. The irony is that… OPEN SOURCE CODE - OPEN SOURCE COMMUNITY = Conventional, in-house, ad hoc legacy software

11. Development/Acquisition Evolution BUILD SHARE VS. VS. BUY BUY

12. 3rd Try… Open Source can be defined as always having the right to ‘fork’ the source code BUT Exercising that right to ‘Fork’ is fraught with challenges and often not desirable For the most part, part of the definition is that ongoing participation is VOLUNTARY

13. Suitability = Maturity vs. Capability ‘Freeloading’ Very Mature Low Risk Decisions OS ‘Sweet Spot’ What makes OS communities thrive ‘Maturity’ of Project / Community Project Originator Real Risk of Failure Immature Low High Organization’s Capability for Development

14. Group Qualities of Organizations and Projects around… • Initial Development • Deployment and Integration • Ongoing Maintenance and Support • Overall Institutional or Project Attributes

15. Development Organizational Factors Project-based Developer Resources experience with specific technologies willingness to learn; interest in specific technologies under consideration willingness of institution to support learning through development Existing Software Development Process and Environment Project Factors Age of project Number of releases Project Reputation (for stability, rapidity of bug fixes) Number of existing developers extent to which OS development roles are explicit and filled Activity within the development community, forums and mailing lists

16. Deployment and Integration Organizational Factors Existing framework, architecture or e-learning infrastructure into which new project must fit existing open source components in use exiting commercial components in use Project Factors Dependencies/ Standards open source dependencies commercial dependencies support of open standards existence within a larger suite of OS applications or architecture Well documented API 3rd party support for deployment

17. Ongoing Maintenance and Support Organizational Factors Ongoing Developer Resources Institutional Support Structures Existing Bug tracking, testing and fixing processes Institutional Tolerance for Beta Products Project Factors Documented procedure for becoming a new developer Developer documentation / support community Explicit and implicit developer education and socialization paths End-user documentation / support community 3rd party support providers / vendors

18. Overall Institutional or Project Attributes Organizational Factors Institution Type/Size Preferred Project Management Style Past Experience with Open Source projects History of being risk takers or risk adverse Related Institutional Networks and affiliations Desire to commercialize or otherwise spin off derivative or related works Project Factors Governance Model One guiding leader (cf. Moodle) Hierarchical with different captains Inner circle (cf. Sakai, http://kb.indiana.edu/data/anlz.html?cust=731846.98763.30) None? others… Licensing Model BSD-like GPL-like Apache, Linux-like Educational Community License others… (cf. http://www.opensource.org/licenses/) Open source “market share”

19. Example Organization 1 • R1 University with history of development but no funding • Clearly identified requirements with some initial funding and no ongoing funding • Multiple OS supported on campus • Already using Linux and Apache extensively, and have history of “pushing the envelope” • Ed Tech team has some formal software development methodology, but no quality assurance systems in place

20. Capability Profile 1 – “R1 Uni”

21. Example Organization 2 • Community College System with Funding in Place but little experience • Need to implement new CMS, no standard CMS across system; some initial funding and ongoing funding • Standardized on Windows across system • Already using Apache in a few small instances; typically part of the “late majority” of adopters • Ed Tech team has no formal software development methodology, but do have a help-desk system in place that routes calls back to this team

22. Capability Profile 2 – “CommCollege”

23. OS Software Package 1 – “APooter” • “Open Source Course Management System” • Started in 1999; typically releases quarterly • Core development at one university, but open forums and evidence that work from other developers is being adopted back into project • ‘LAMP’ based project

24. OS Software Maturity Profile 1

25. OS Software Package 2 – “HOLMS” • “Open Source Course Management System” • Started in 2004; very few (<3) releases • Core development at one university; no evidence of developer forums but some evidence of inter-institutional partnerships emerging • Tomcat/MySQL/Jakarta Struts Application Framework based project

26. OS Software Maturity Profile 1

27. Scenarios • #1 - “Low Risk Choices” – Org1 & Software1 • #2 - “Adoption, not adaption” – Org2 & Soft2 • #3 - “Major Boost” – Org1 & Soft2 • #4 - “Risky choice/Good Luck!” – Org2 & Soft2

28. Suitability = Maturity vs. Capability Very Mature Low Risk Decisions #2 #1 ‘Maturity’ of Project / Community #4 #3 Real Risk of Failure Immature Low High Organization’s Capability for Development

29. Goal of Decision Tool • Provide a means of self-identification for institutional decision makers to recognize their capabilities and the projects they are well suited to • Identify areas of likely risk in choosing particular kinds of projects in an effort to address them before the projects are engaged

30. Final Thoughts • Beyond this question of ‘suitability’ there do seem to be some essential qualities of OS aligned with higher ed • in relying on local innovation rather than market forces to drive progress, it fosters diversity / increases pedagogical innovation • often results in increased learning for staff within institution • “The collaborative nature of open source has a strong cultural affinity to higher education and its mission to advance and share knowledge for the greater public good” Coppola, http://www.campus-technology.com/news_article.asp?id=10299&typeid=155

31. Questions? Discussion Feel free to contact me at sleslie@edutools.info Stay tuned to http://www.edutools.info/ for more news on this project