KEMBAR78
Open Source: What is It? | PDF
Open Source: What is it?

            Practices, Processes, Advantages, and Risks




Jonathan Markow                        DuraSpace Webinar Series
Chief Strategy Officer                             June 2, 2011
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
The Rise of Open Source
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
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
What is Open Source?

      Open
        vs.

  Open Source
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.”
Vendors are our Friends!
              (…but lock-in is bad!)




More on this later…
What Best
Characterizes
    Open
   Source
Community
Open Source Values
    Collaboration
Transparency
Meritocracy
Generosity
Innovation
The Source Code is Free
Source Code Is Not
       Enough…

Distribution of the software has to
comply with some important
requirements…
Open Source Requirements

• Free Distribution

• Access to Source Code
Open Source Requirements


• Derived works allowed

• Integrity of author’s source
Open Source Requirements

• No Discrimination!
  …against people
  …against groups, fields of
   endeavor

• All rights applied equally
Open Source Requirements


• License must not restrict
  other software

• License must be technology
  neutral
Licenses




Restrictive vs. Permissive

http://opensource.org/licenses/category
Advantages

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

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

• Excellent Security
Advantages

• Responsive to the Community
Advantages

• Ease of Customization
Advantages

• Lower Cost (?)
Myth #1

“If we adopt open source software,
we’ll be at the mercy of crazed
hackers!”
• Contributors earn trust and
  build reputation
• Developers usually have the
  support of their employers
• Communities are self-policing
Myth #2
“If we go with open source, I won’t
have a throat to choke!”
• Options for throat-chokers
• Commercial service providers
Myth #3

“Open source is 
more risky 
because the 
project/software
/community 
could just 
disappear!”
• Not likely, but loss of
  momentum is a risk
• Consider the mitigating
  factors…
• And don’t forget the track
  record of proprietary systems!
Myth #4

• “Open source must be less secure.
  Anyone could just add malicious
  code!”
• 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.)
Myth #5
“We can’t implement open source
 software because we don’t have
 the resources to contribute back
 to the project!”
• Consumer vs. Creator
• Many options for helpful
  participation
Myth #6
• “If it’s open source, I won’t be
  able to get support!”
• Plenty of companies earn a
  living providing service for
  open source products
• Service level agreements
Open Source Models

1. Traditional Community-Driven
 •   Meritocracy
 •   Transparency
 •   Open to all
 •   Volunteer
 •   User/corporate sponsorships
 •   Key risk: Deliverables not iron-clad
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
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
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
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)
Pathways to Success with
     Open Source

• …For the Project
• …For the Institution
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
Project Success

• Be transparent
 •   (Almost) all discussions are open
 •   Everything goes on the mailing list
 •   Code exposed to all
 •   Publicize project roadmap
Project Success

• Adopt well-understood processes
 • How is code contributed?
 • How are decisions made?
Project Success

• Committers decide
 • But everyone is invited to the
   conversation
 • New committers selected by current
   group
 • Consensus decision-making
Project Success

• Include techies, users,
  administrators, writers, managers
  into project
 • There are many useful roles for
   people who want to contribute
Project Success

• Get the word out!
 • Communication is key
   •   Web site
   •   Wiki
   •   Blogs
   •   Social media
 • Visibility
   •   Present at conferences, other
 • Marketing
Project Success

Producing Open Source Software
-Karl Fogel

http://producingoss.com/html-chunk/index.html
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
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?
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?
Institutional Success

• Evaluate the project (cont.)
 •   Consult with peer institutions
 •   Attend conferences
 •   Attend webinars
 •   Any recognition in trade press,
     online?
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?
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?
Protect Your Investment

• Do you use the product?
• Does it meet your needs?
• If so, support the community!
Support the Community

• Commit developer resources
• Commit code
• Contribute patches
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
Support the Community

•   Attend conferences
•   Present at conferences
•   Be a product reference
•   Join user groups
•   Volunteer for a case study
Support the Community


   Be an Advocate!
Questions




Jonathan Markow * jjmarkow@duraspace.org

Open Source: What is It?

  • 1.
    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
  • 3.
    The Rise ofOpen Source
  • 4.
    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
  • 6.
    What is OpenSource? Open vs. Open Source
  • 7.
    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…
  • 9.
  • 10.
  • 11.
    Open Source Values Collaboration
  • 12.
  • 13.
  • 14.
  • 15.
  • 16.
  • 17.
    Source Code IsNot 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.
  • 24.
    Advantages • More freedomto 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.
  • 27.
  • 28.
  • 29.
  • 30.
    Myth #1 “If weadopt open source software, we’ll be at the mercy of crazed hackers!”
  • 31.
    • Contributors earntrust and build reputation • Developers usually have the support of their employers • Communities are self-policing
  • 32.
    Myth #2 “If wego with open source, I won’t have a throat to choke!”
  • 33.
    • Options forthroat-chokers • Commercial service providers
  • 34.
  • 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 • “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
  • 54.
    Project Success Producing OpenSource Software -Karl Fogel http://producingoss.com/html-chunk/index.html
  • 55.
    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!
  • 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