Open Source: What is It?

3,948 views

Published on

A discussion of the advantages, risks, and rewards of Open Source by Jonathan Markow, DuraSpace.
Presented June 2, 2011

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,948
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
36
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

Open Source: What is It?

  1. 1. Open Source: What is it? Practices, Processes, Advantages, and RisksJonathan Markow DuraSpace Webinar SeriesChief Strategy Officer June 2, 2011
  2. 2. The Rise of Open SourceGartner Survey Reveals More thanHalf of Respondents Have AdoptedOpen-Source Software Solutions asPart of IT Strategy - February 8, 2011 • http://www.gartner.com/it/page.jsp?id=1541414
  3. 3. The Rise of Open Source
  4. 4. The Rise of Open Source“Worldwide more than 350 million consumers use open source software products and thousands of enterprises use open source code.” http://www.ifosslr.org/ifosslr/article/view/11/37
  5. 5. The Rise of Open Source“Open Source Software Hits a Strategic Tipping Point”-Harvard Business Review Blog March 9, 2011 http://blogs.hbr.org/cs/2011/03/ open_source_software_hits_a_st.html
  6. 6. What is Open Source? Open vs. Open Source
  7. 7. The Open Source Definition The Open Source Initiative (opensource.org)“Open source is a development method for softwarethat harnesses the power of distributed peer reviewand transparency of process.”“The promise of open source is better quality, higherreliability, more flexibility, lower cost, and an end topredatory vendor lock-in.”
  8. 8. Vendors are our Friends! (…but lock-in is bad!)More on this later…
  9. 9. What BestCharacterizes Open Source
  10. 10. Community
  11. 11. Open Source Values Collaboration
  12. 12. Transparency
  13. 13. Meritocracy
  14. 14. Generosity
  15. 15. Innovation
  16. 16. The Source Code is Free
  17. 17. Source Code Is Not Enough…Distribution of the software has tocomply with some importantrequirements…
  18. 18. Open Source Requirements• Free Distribution• Access to Source Code
  19. 19. Open Source Requirements• Derived works allowed• Integrity of author’s source
  20. 20. Open Source Requirements• No Discrimination! …against people …against groups, fields of endeavor• All rights applied equally
  21. 21. Open Source Requirements• License must not restrict other software• License must be technology neutral
  22. 22. LicensesRestrictive vs. Permissivehttp://opensource.org/licenses/category
  23. 23. Advantages• More freedom to make decisions about how to use the software
  24. 24. Advantages• High Quality “Given enough eyeballs, all bugs are shallow” -Eric Raymond The Cathedral and the Bazaar
  25. 25. Advantages• Excellent Security
  26. 26. Advantages• Responsive to the Community
  27. 27. Advantages• Ease of Customization
  28. 28. Advantages• Lower Cost (?)
  29. 29. Myth #1“If we adopt open source software,we’ll be at the mercy of crazedhackers!”
  30. 30. • Contributors earn trust and build reputation• Developers usually have the support of their employers• Communities are self-policing
  31. 31. Myth #2“If we go with open source, I won’thave a throat to choke!”
  32. 32. • Options for throat-chokers• Commercial service providers
  33. 33. Myth #3“Open source is more risky because the project/software/community could just disappear!”
  34. 34. • Not likely, but loss of momentum is a risk• Consider the mitigating factors…• And don’t forget the track record of proprietary systems!
  35. 35. Myth #4• “Open source must be less secure. Anyone could just add malicious code!”
  36. 36. • That’s not the way it works! • Protected repository • Trusted committers • Many eyes on the code• Malicious code is hard to inject. (Unintentional vulnerabilities are easier.)
  37. 37. Myth #5“We can’t implement open source software because we don’t have the resources to contribute back to the project!”
  38. 38. • Consumer vs. Creator• Many options for helpful participation
  39. 39. Myth #6• “If it’s open source, I won’t be able to get support!”
  40. 40. • Plenty of companies earn a living providing service for open source products• Service level agreements
  41. 41. Open Source Models1. Traditional Community-Driven • Meritocracy • Transparency • Open to all • Volunteer • User/corporate sponsorships • Key risk: Deliverables not iron-clad
  42. 42. Open Source Models2. Traditional Community-Driven with Commercial Partners • Vendors are part of the community • Contribute to projects • Provide service • May license proprietary plugins
  43. 43. Open Source Models3. “Community Source” • e.g., Kuali Model • Decision makers invest in a seat at the table • Managed resources • Hierarchical, directed development structure with more predictable outcomes. • Vendor partners contribute • Key Risk: Diversity might be limited
  44. 44. Open Source Models4. “Open Core” • For-profit vendor owns the intellectual property • Core open source application is accompanied by proprietary version, which comes with licensing or support fee • e.g., “Community” vs. “Enterprise” versions • Requires dual licensing • Key risk: Could be insular, self-interest outweighs community
  45. 45. The DuraSpace Model• Traditional open source• Community driven; non-profit• Diverse committers, users; international participation• Registered service providers• Community sponsorship (Soon: Corporate sponsorship)• Service revenue (DuraCloud)
  46. 46. Pathways to Success with Open Source• …For the Project• …For the Institution
  47. 47. Project Success• Be welcoming; be generous • Attract and mentor new talent • Create an easy entry to the project (e.g., list of potential patches) • Attract diversity of committers • Maintain a responsive mailing list
  48. 48. Project Success• Be transparent • (Almost) all discussions are open • Everything goes on the mailing list • Code exposed to all • Publicize project roadmap
  49. 49. Project Success• Adopt well-understood processes • How is code contributed? • How are decisions made?
  50. 50. Project Success• Committers decide • But everyone is invited to the conversation • New committers selected by current group • Consensus decision-making
  51. 51. Project Success• Include techies, users, administrators, writers, managers into project • There are many useful roles for people who want to contribute
  52. 52. Project Success• Get the word out! • Communication is key • Web site • Wiki • Blogs • Social media • Visibility • Present at conferences, other • Marketing
  53. 53. Project SuccessProducing Open Source Software-Karl Fogelhttp://producingoss.com/html-chunk/index.html
  54. 54. Institutional Success• Do your due diligence • Product Comparisons • Assess costs • Insist that your purchasing department gives Open Source a fair hearing during an RFP process • Focus on pilot functionality more than RFP check lists
  55. 55. Institutional Success• Evaluate the Open Source project • What is the sustainability model? • Subscribe to the mailing lists • Look at the web sites, wiki • Is there documentation? • Are there options for third-party support?
  56. 56. Institutional Success• Evaluate the project (cont.) • What is the governance model? • How many users? • Does the project have momentum? • Regular releases? • Are there options for third-party support?
  57. 57. Institutional Success• Evaluate the project (cont.) • Consult with peer institutions • Attend conferences • Attend webinars • Any recognition in trade press, online?
  58. 58. Institutional Success• Evaluate the project community • Diverse set of committers? • Open, transparent, respectful of newcomers? • Subscribe to the mailing lists • How active are the developers?
  59. 59. Institutional Success• Internal project management is critical • Treat the implementation as you would any other product • What role will your technical staff play? • Active development? • Implementation partners? • Manager of third-party services?
  60. 60. Protect Your Investment• Do you use the product?• Does it meet your needs?• If so, support the community!
  61. 61. Support the Community• Commit developer resources• Commit code• Contribute patches
  62. 62. Support the Community• Be active on the mailing lists (offer help where you can)• Contribute documentation• Contribute training material• Host a developer meeting, a user meeting, a regional meetup
  63. 63. Support the Community• Attend conferences• Present at conferences• Be a product reference• Join user groups• Volunteer for a case study
  64. 64. Support the Community Be an Advocate!
  65. 65. QuestionsJonathan Markow * jjmarkow@duraspace.org

×