The 7 Things I Know About Cyber Security After 25 Years | April 2024
Open Source: What is It?
1. Open Source: What is it?
Practices, Processes, Advantages, and Risks
Jonathan Markow DuraSpace Webinar Series
Chief Strategy Officer June 2, 2011
2. The Rise of Open Source
Gartner Survey Reveals More than
Half of Respondents Have Adopted
Open-Source Software Solutions as
Part of IT Strategy
- February 8, 2011
• http://www.gartner.com/it/page.jsp?id=1541414
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. 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
7. The Open Source Definition
The Open Source Initiative
(opensource.org)
“Open source is a development method for software
that harnesses the power of distributed peer review
and transparency of process.”
“The promise of open source is better quality, higher
reliability, more flexibility, lower cost, and an end to
predatory vendor lock-in.”
8. Vendors are our Friends!
(…but lock-in is bad!)
More on this later…
35. • Not likely, but loss of
momentum is a risk
• Consider the mitigating
factors…
• And don’t forget the track
record of proprietary systems!
36. Myth #4
• “Open source must be less secure.
Anyone could just add malicious
code!”
37. • 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.)
38. Myth #5
“We can’t implement open source
software because we don’t have
the resources to contribute back
to the project!”
39. • Consumer vs. Creator
• Many options for helpful
participation
40. Myth #6
• “If it’s open source, I won’t be
able to get support!”
41. • Plenty of companies earn a
living providing service for
open source products
• Service level agreements
42. Open Source Models
1. Traditional Community-Driven
• Meritocracy
• Transparency
• Open to all
• Volunteer
• User/corporate sponsorships
• Key risk: Deliverables not iron-clad
43. Open Source Models
2. Traditional Community-Driven
with Commercial Partners
• Vendors are part of the community
• Contribute to projects
• Provide service
• May license proprietary plugins
44. Open Source Models
3. “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
45. Open Source Models
4. “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
46. 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)
47. Pathways to Success with
Open Source
• …For the Project
• …For the Institution
48. 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
49. Project Success
• Be transparent
• (Almost) all discussions are open
• Everything goes on the mailing list
• Code exposed to all
• Publicize project roadmap
50. Project Success
• Adopt well-understood processes
• How is code contributed?
• How are decisions made?
51. Project Success
• Committers decide
• But everyone is invited to the
conversation
• New committers selected by current
group
• Consensus decision-making
52. Project Success
• Include techies, users,
administrators, writers, managers
into project
• There are many useful roles for
people who want to contribute
53. Project Success
• Get the word out!
• Communication is key
• Web site
• Wiki
• Blogs
• Social media
• Visibility
• Present at conferences, other
• Marketing
55. 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
56. 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?
57. 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?
58. Institutional Success
• Evaluate the project (cont.)
• Consult with peer institutions
• Attend conferences
• Attend webinars
• Any recognition in trade press,
online?
59. 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?
60. 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?
61. Protect Your Investment
• Do you use the product?
• Does it meet your needs?
• If so, support the community!
63. 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
64. Support the Community
• Attend conferences
• Present at conferences
• Be a product reference
• Join user groups
• Volunteer for a case study