The document discusses the rise and significance of open source software, highlighting its adoption by consumers and enterprises, and defining key open source principles and community characteristics. It addresses common myths about open source, outlines various models for community-driven projects, and emphasizes the importance of transparency, participation, and risk management in ensuring project and institutional success. Additionally, it provides strategic recommendations for evaluating and supporting open source projects to enhance their sustainability and contribution to the community.
Open Source: Whatis it?
Practices, Processes, Advantages, and Risks
Jonathan Markow DuraSpace Webinar Series
Chief Strategy Officer June 2, 2011
2.
The Rise ofOpen 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
The Rise ofOpen 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 ofOpen 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
The Open SourceDefinition
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 ourFriends!
(…but lock-in is bad!)
More on this later…
• 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
• “Opensource must be less secure.
Anyone could just add malicious
code!”
37.
• That’s notthe 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’timplement 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
• “Ifit’s open source, I won’t be
able to get support!”
41.
• Plenty ofcompanies 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 Successwith
Open Source
• …For the Project
• …For the Institution
48.
Project Success
• Bewelcoming; 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
• Betransparent
• (Almost) all discussions are open
• Everything goes on the mailing list
• Code exposed to all
• Publicize project roadmap
50.
Project Success
• Adoptwell-understood processes
• How is code contributed?
• How are decisions made?
51.
Project Success
• Committersdecide
• But everyone is invited to the
conversation
• New committers selected by current
group
• Consensus decision-making
52.
Project Success
• Includetechies, users,
administrators, writers, managers
into project
• There are many useful roles for
people who want to contribute
53.
Project Success
• Getthe word out!
• Communication is key
• Web site
• Wiki
• Blogs
• Social media
• Visibility
• Present at conferences, other
• Marketing
Institutional Success
• Doyour 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
• Evaluatethe 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
• Evaluatethe 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
• Evaluatethe project (cont.)
• Consult with peer institutions
• Attend conferences
• Attend webinars
• Any recognition in trade press,
online?
59.
Institutional Success
• Evaluatethe project community
• Diverse set of committers?
• Open, transparent, respectful of
newcomers?
• Subscribe to the mailing lists
• How active are the developers?
60.
Institutional Success
• Internalproject 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!
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