Open Source Maturity and Suitability

Choosing The Right Open Source Project Scott Leslie, Edutools.info SFU, July 28, 2005

You are here? Outer Hebrides?

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

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

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

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

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

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

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

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

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

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

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

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

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

Deployment and Integration
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
3 rd party support for deployment

Ongoing Maintenance and Support
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

Overall Institutional or Project Attributes
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”

Suitability = Maturity vs. Capability Organization’s Capability for Development ‘ Maturity’ of Project / Community Very Mature Immature Low High Real Risk of Failure #1 “ Low Risk Choice” #2 “ Adoption, not adaptation” #3 “ Major Boost” #4 “ Good Luck!”

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

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

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

Capability Profile 1 – “R1 Uni” No desire to spin off derivative work Desire to commercialize derivative or related works Unknown Related Institutional Networks and affiliations Have been done this road before Past Experience with Open Source projects History of project-based work, distributed, multi-unit work teams Preferred Project Management Style Have been done this road before; can keep existing CMS in place Institutional Tolerance for Beta Products Desire to replace existing CMS Existing framework, architecture or e-learning infrastructure Some, but could use more formal environment Existing Software Development Process and Environment Risk area long term Ongoing Developer Resources Good but not great; the more they can bootstrap, the better Project-based Developer Resources

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

Capability Profile 2 – “CommCollege” No desire to spin off derivative work Desire to commercialize derivative or related works Entire State System Related Institutional Networks and affiliations Are intrigued by the prospect but no real experience Past Experience with Open Source projects Not strong on project-based work Preferred Project Management Style Used to COTS Institutional Tolerance for Beta Products High risk as they require something soon to come out of this process Existing framework, architecture or e-learning infrastructure Problematic for engaging with other organizations & contributing back Existing Software Development Process and Environment Could use more Ongoing Developer Resources Could use more Project-based Developer Resources

OS Software Package 1 – “ALooter”
“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

OS Software Maturity Profile 1 GPL Licensing Model Initial developers still control process & comm Governance Model None 3rd party support providers / vendors Good but could be improved End-user documentation / support community Informal at best Explicit and implicit developer education and socialization paths Very active Developer documentation / support community LAMP, so few concerns Dependencies/ Standards Very active Activity within the development community, forums and mailing lists Some Explicit OS Development Roles 8 / 1 main, many peripheral # developers/Organizations Fixes bundled as part of quarterly release cycle Project Reputation (for stability, rapidity of bug fixes) Over 10 major releases Number of releases

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

OS Software Maturity Profile 1 GPL Licensing Model Initial developers still control process & comm Governance Model None 3rd party support providers / vendors Not much End-user documentation / support community Informal , if at all Explicit and implicit developer education and socialization paths Not much Developer documentation / support community All OS, so few concerns Dependencies/ Standards No aparent developer forums Activity within the development community, forums and mailing lists Not evident Explicit OS Development Roles 3/ 1 main # developers/Organizations No apparent schedule or roadmap Project Reputation (for stability, rapidity of bug fixes) Under 3 releases Number of releases

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

Open Source Maturity and Suitability

by Scott Leslie

Accessibility

Categories

Upload Details

Usage Rights

3 Embeds 15

Statistics

Open Source Maturity and Suitability Presentation Transcript

http://www.slideshare.net	8
http://www.techgig.com	4
http://webexconnect.dev.mnl.com	3