Choosing The Right Open Source Project

1
Choosing The Right Open Source Project

• Presentation by Scott Leslie, Edutools.info for
• SREB Educational Technology Cooperative
• Information Technology Task Group, February 15,
  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 American 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
• An effort to detail work to develop framework to
  understand OS project suitability in relation to
  institutional capacities
• Want to help people chose the right OS projects

7
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

8

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

9
The irony is that

• OPEN SOURCE CODE
• -
• OPEN SOURCE COMMUNITY
• Conventional, in-house, ad hoc legacy software

10
Development/Acquisition Evolution
SHARE
BUILD
VS.
VS.
BUY
BUY
11
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

12
Suitability Maturity vs. Capability
13
Group Qualities of Organizations and Projects
around

• Initial Development
• Deployment and Integration
• Ongoing Maintenance and Support
• Overall Institutional or Project Attributes

14
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

15
Development Example

• CMS - Good Fit
• R1 Institution with defined project budget,
  developer with J2EE skills could fit well with
• Sakai
• CMS Not-so-Good-Fit
• 2 year community college, limited CMS needs and
  no defined project budget, some in-house HTML and
  PHP skills trying to adopt
• .LRN

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
Deployment and Integration Examples

• Eportfolios - Good Fit
• smaller institution trying to integrate with
  an existing CMS, with some CMS integration
  experience but no Java skills could fit well
  with
• OSPI, in part because of groups like R-Smart
• Eportfolios -Not-so-Good-Fit
• the same institution trying now to deploy the
• ELG portfolio system

18
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

19
Ongoing Maintenance and Support Examples

• LOR Good Fit
• mid-sized university with 3 year commitment
  to ongoing development budget and progressive
  roll out might fit well with
• COL LOR project (http//lor.colfinder.org/collor/)
  
• LOR Not-so-Good-Fit
• a smaller college with very little ongoing
  development budget and no formal bug fixing
  process in place trying to deploy
• PlanetDR (http//ants.etse.urv.es/planetdr/)

20
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

21
Suitability Maturity vs. Capability
22
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

23
Questions? Discussion

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