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

Loading in 2 Seconds...

play fullscreen
1 / 90

Evaluating Open Source Software ELAG 2009 - PowerPoint PPT Presentation

  • Uploaded on

Evaluating Open Source Software ELAG 2009. Edward M. Corrado ecorrado@binghamton.edu. 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.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

Evaluating Open Source Software ELAG 2009

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

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