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 Isnt

• 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-technol
  ogy.com/news_article.asp?id10299typeid155
• Randy Metcalfe, Software Choice Decision Making
  in a Mixed Economy, http//www.ariadne.ac.uk/issu
  e42/metcalfe/
• Patricia Gertz, Open Your Eyes Open
  Architecture, Open Source, Open Projects,
  http//www.educause.edu/content.asp?page_id666ID
  MAC0510bhcp1
• Coppola and Neely, Open source - opens
  learning, http//www.opensourcesummit.org/open-so
  urce-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. OSIs 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
SHARE
BUILD
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
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/dat
  a/anlz.html?cust731846.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
Project-based Developer Resources Good but not great the more they can bootstrap, the better
Ongoing Developer Resources Risk area long term
Existing Software Development Process and Environment Some, but could use more formal environment
Existing framework, architecture or e-learning infrastructure Desire to replace existing CMS
Institutional Tolerance for Beta Products Have been done this road before can keep existing CMS in place
Preferred Project Management Style History of project-based work, distributed, multi-unit work teams
Past Experience with Open Source projects Have been done this road before
Related Institutional Networks and affiliations Unknown
Desire to commercialize derivative or related works No desire to spin off derivative work
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
Project-based Developer Resources Could use more
Ongoing Developer Resources Could use more
Existing Software Development Process and Environment Problematic for engaging with other organizations contributing back
Existing framework, architecture or e-learning infrastructure High risk as they require something soon to come out of this process
Institutional Tolerance for Beta Products Used to COTS
Preferred Project Management Style Not strong on project-based work
Past Experience with Open Source projects Are intrigued by the prospect but no real experience
Related Institutional Networks and affiliations Entire State System
Desire to commercialize derivative or related works No desire to spin off derivative work
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
Number of releases Over 10 major releases
Project Reputation (for stability, rapidity of bug fixes) Fixes bundled as part of quarterly release cycle
developers/Organizations 8 / 1 main, many peripheral
Explicit OS Development Roles Some
Activity within the development community, forums and mailing lists Very active
Dependencies/ Standards LAMP, so few concerns
Developer documentation / support community Very active
Explicit and implicit developer education and socialization paths Informal at best
End-user documentation / support community Good but could be improved
3rd party support providers / vendors None
Governance Model Initial developers still control process comm
Licensing Model GPL
25
OS Software Package 2 HOLMS

• Open Source Course Management System
• Started in 2004 very few (lt3) 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
Number of releases Under 3 releases
Project Reputation (for stability, rapidity of bug fixes) No apparent schedule or roadmap
developers/Organizations 3/ 1 main
Explicit OS Development Roles Not evident
Activity within the development community, forums and mailing lists No aparent developer forums
Dependencies/ Standards All OS, so few concerns
Developer documentation / support community Not much
Explicit and implicit developer education and socialization paths Informal , if at all
End-user documentation / support community Not much
3rd party support providers / vendors None
Governance Model Initial developers still control process comm
Licensing Model GPL
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
Organizations 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?
  id10299typeid155

31
Questions? Discussion

• Feel free to contact me at sleslie_at_edutools.info
• Stay tuned to http//www.edutools.info/ for more
  news on this project