Download
evaluating open source software elag 2009 n.
Skip this Video
Loading SlideShow in 5 Seconds..
Evaluating Open Source Software ELAG 2009 PowerPoint Presentation
Download Presentation
Evaluating Open Source Software ELAG 2009

Evaluating Open Source Software ELAG 2009

139 Vues Download Presentation
Télécharger la présentation

Evaluating Open Source Software ELAG 2009

- - - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

  1. Evaluating Open Source SoftwareELAG 2009 Edward M. Corrado ecorrado@binghamton.edu

  2. Outline • Introductions • What is Open Source Software (OSS) • What do we look for in OSS? • Evaluating OSS using the Open Source Maturity Model (OSMM) • OSS Square of Engagement • “Selling” OSS to management

  3. Introductions: About me • Head of Library Technology @ Binghamton University (USA) • User of Open Source for 15+ years • Former president of Linux Users Group/In Princeton (2000-2008) • ELUNA Steering Committee

  4. Introductions: About you • What is your involvement in Library Technology? • What is your involvement in Open Source? • What OSS do you use at work/pleasure? • What do you hope to et out of this workshop?

  5. Free/Libre/Open-Source Software • Free as in Speech (Libre) • Not necessarily Free as in Beer (gratis) • Free to redistribute • Access to the Source Code • Can modify the code • Can redistribute those modifications

  6. “Generically, open source refers to a program in which the source code is available to the general public for use and/or modification from its original design free of charge, i.e., open.” http://www.webopedia.com/TERM/O/open_source.html Open Source Defined

  7. Four Freedoms of Free Software • The freedom to run the program, for any purpose • The freedom to study how the program works, and adapt it to your need • The freedom to redistribute copies so you can help your neighbour • The freedom to improve the program, and release your improvements to the public, so that the whole community benefits Source: http://www.gnu.org/philosophy/free-sw.html

  8. Open Source does not (necessarily) mean... • Non-supported • Non-commercial • Made by a couple of geeks in a garage wearing “Duran Duran” t-shirts • Free Kitten? Duran Duran t-shirt photo by erik - bor i en juckapa: http://flickr.com/photos/erik_bor_i_en_juckapa/461997993. Cat photo by me.

  9. OSS for the Desktop • Has been strong in systems office • Linux • Apache • Database software • Mozilla Firefox Web browser • Mozilla Thunderbird e-mail • OpenOffice.org • Pidgin (IM)‏ • OpenDisc: http://theopendisc.com

  10. Advantages of Free/Open Source • Costs (initial and ongoing)‏ • Support fees, not license fees • Easier to evaluate • Modifiable / customizable • Interoperability • Eases license restrictions

  11. Advantages of Open Source (con't)‏ • Community for support and improvement • Better / more support options • Bridges information divide • No vendor lock-in • No determined life-cycle Photo by mcav0y: http://flickr.com/photos/mcav0y/451448348/

  12. OSS for Libraries • Digital library programs • ILS (Koha, Evergreen) • OPACs (VUfind, XC) • Federated search (LibraryFind)‏ • Non-library specific applications

  13. Why Open Source in Libraries? • Community • A long tradition of collaboration and sharing • More librarians/programmers = better software • Costs • Not paying for R&D for other offerings • Flexibility • Vision Photo from Daniel Y. Go: http://flickr.com/photos/danielygo/1144423426/

  14. Community • “Libraries are committed to the notion of community” - Joe Lucia • Product road map belongs to the community • Software that does what you want, not what a marketing department of some company wants • Responsiveness Image from RTPI

  15. Why Open Source in Libraries Now? • Uncertainty in the ILS marketplace • Vendor support issues • Costs • quality of support • Mergers and acquisitions of ILS vendors • Endeavor / Ex Libris • SirsiDynix (Horizon 8)‏ • Who's next? • Evolving Role of the ILS

  16. Why Open Source in Libraries Now? • Better methods of communication/collaboration • Open Standards • Building blocks in place • Web 2.0 • No need to have the burdens of development, support, maintenance thanks to Commercial Support • Equinox, LibLime • Major ILS vendors are already using it

  17. At a Tipping Point • Open Source in libraries is now a viable option for all organizations, not just those with developers and techies Image from Wikipedia

  18. Investment • By going to Open Source... • Libraries invest in themselves • Libraries invest in their staff • Libraries invest in their community Photo from http://www.ucfv.ca/__shared/printpages/page1020.htm

  19. “Free to All” Photo courtesy of http://www.flickr.com/people/informationgoddess29/

  20. What features do you look for in Open Source Software? How is this different from proprietary software? Or is it? Group Discussion #1

  21. Evaluating OSS using the Open Source Maturity Model (OSMM) • Developed by Geoffrey Moore in Crossing the Chasm. • Described in great detail in Succeeding with Open Source by Bernard Golden. • A framework to determine the level of maturity of an OSS product

  22. Two Types of Technology Users • Early Adopters • Use technology as a competitive advantage • Pragmatists • Look for technology to offer efficiency and cost advantage

  23. Libraries and Pragmatism • Libraries typically are pragmatic organizations • Traditionally, not competitive • Sharing organizations • World is changing • Information is ubiquitous • We might not be competing with each other, but others are competing with us • Future is bright, but only if we adapt

  24. Mature Software • Full feature set • High quality • Longevity in market • Ease of administration/installation • Good support and documentation • Safety blanket

  25. OSS and Maturity • Unique challenges by nature • Often, loosely coupled • Companies most evaluate OSS maturity on their own • Implementing OSS is much like acting as a general contractor

  26. OSMM Overview • Formal methodology that aids in assessment process • Assess maturity in 3 phases • Assess each product element’s maturity and assign a maturity score • Define a waiting for each element based on organizational requirements • Calculate products overall maturity

  27. Key Product Elements • Product software • Support • Documentation • Training • Product integrations • Professional Services

  28. Each element is assigned a maturity score in a 4 step process • Define organizational requirements • Locate resources • Assess element maturity • Assess element maturity on scale of 1 to 10

  29. OSMM Chart

  30. Phase I: Organizational Requirements • Key element of evaluating any product • In my experience, man libraries are not particularly good at doing this

  31. Phase I: Locate Resources • With most proprietary applications, the resources needed are provided by the same company that creates/sells the software • OSS resources may be scattered • Local resources may exist • Consulting firms

  32. Phase I: Assess Element Maturity & Assign Element Maturity Score • Assess Element Maturity • Anywhere from non-existent to production ready • Assign Element Maturity Score • Scale of 1 to 10, 10 being highest • Documents consensus of organization • Makes product comparisons easier

  33. Phase II: Assign weighting factors • Can vary based on organizational needs • Total weights add up to 10 • Default weightings:

  34. Phase III: Calculate Overall Score Templates available for download from: http://www.navicasoft.com

  35. Example from book: JBoss Note: Book was written in 2005, so the score would undoubtedly be different now

  36. Recommended Minimum OSMM Scores

  37. Assessing the OSS Product • Functionality • Quality of product • Longevity of product • Quality of engineering team

  38. Assessing Product Maturity • Define organizational requirements • Locate resources • Assess element maturity • Assign element maturity score on a 1-10 scale

  39. Organizational Requirements • Should be done with any software acquisition • Often short-changed • Not enough time to do it • However, if you don’t do it, you may need to do it over • Clear requirements are a key to success • Some aspects are unique to Open Source

  40. Organizational Requirements: Create a Task Force • Should include representatives from all areas • Usually more involved then proprietary solutions

  41. Identifying Product Requirements • Can’t always rely on marketing materials and account representatives to help • Materials from commercial companies selling similar products may aid the process • Examine any existing systems functionality • Review applicable standards • Look for prepared reports, white papers, etc, • Poll user community

  42. Document Functional Requirements • Don’t forget to do this! • Helps identify missed requirements that can be added latter • Helps preserve institutional memory • Used to evaluate products

  43. Locating Resources(i.e. Finding Software) • Not a one stop solutions • Search • Open Source project portals • Web • Journals • Ask • E-mail lists • Developers • Colleagues ?

  44. Create a Short List • Usually 3 to 5 products • User community can help in this process • Look at user and/or your interaction with developer team • Ranked-order list

  45. Assess Product Functionality • Match against functional requirements you created earlier • Keep in mind no product will completely meet all requirements • If one does, you didn’t do a good job defining requirements

  46. How to Assess the Product • Based on description • Ask developers • Make sure queries are to the point • Can help create good working relationship • Ask user community • This includes searching or browsing archives

  47. Assessing Product Longevity • Key product maturity indicator • Lifespan • Version numbers • Differs from most commercial software packages and may be misleading • Feature bloat may cause versioning (more often in proprietary than in OSS) • Look at usage • Downloads

  48. Assessing Product Quality • Proprietary software quality can be difficult to measure • What do we know about internal practices? • Testing? • Basically, one has to rely on brand recognition • Open Source is more transparent • You can find out who is on the development team • You can look at the source code • You can review Q&A procedures • No non-discloser agreements

  49. Assess Activity Level • Number of releases • Code check-ins • Outstanding bugs (and maybe more importantly fixed bugs) • Responsiveness to bugs