Evaluating Open Source Software ELAG 2009

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

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

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

40. 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

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

42. 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

43. 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

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

45. 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

46. 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

47. 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

48. 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

49. 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

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