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.

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

3. The Rise of Open Source

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

6. What is Open Source?
Open
vs.
Open Source

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…

9. What Best
Characterizes
Open
Source

10. Community

11. Open Source Values
Collaboration

12. Transparency

13. Meritocracy

14. Generosity

15. Innovation

16. The Source Code is Free

17. Source Code Is Not
Enough…
Distribution of the software has to
comply with some important
requirements…

18. Open Source Requirements
• Free Distribution
• Access to Source Code

19. Open Source Requirements
• Derived works allowed
• Integrity of author’s source

20. Open Source Requirements
• No Discrimination!
…against people
…against groups, fields of
endeavor
• All rights applied equally

21. Open Source Requirements
• License must not restrict
other software
• License must be technology
neutral

23. Licenses
Restrictive vs. Permissive
http://opensource.org/licenses/category

24. Advantages
• More freedom to make decisions
about how to use the software

25. Advantages
• High Quality
“Given enough eyeballs, all bugs are
shallow”
-Eric Raymond
The Cathedral and the Bazaar

26. Advantages
• Excellent Security

27. Advantages
• Responsive to the Community

28. Advantages
• Ease of Customization

29. Advantages
• Lower Cost (?)

30. Myth #1
“If we adopt open source software,
we’ll be at the mercy of crazed
hackers!”

31. • Contributors earn trust and
build reputation
• Developers usually have the
support of their employers
• Communities are self-policing

32. Myth #2
“If we go with open source, I won’t
have a throat to choke!”

33. • Options for throat-chokers
• Commercial service providers

34. Myth #3
“Open source is
more risky
because the
project/software
/community
could just
disappear!”

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

54. Project Success
Producing Open Source Software
-Karl Fogel
http://producingoss.com/html-chunk/index.html

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!

62. Support the Community
• Commit developer resources
• Commit code
• Contribute patches

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

65. Support the Community
Be an Advocate!

66. Questions
Jonathan Markow * jjmarkow@duraspace.org