Your SlideShare is downloading. ×
  • Like
To Open Source or Not to Open Source...Where is the ROI?
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

To Open Source or Not to Open Source...Where is the ROI?

  • 945 views
Published

This presentation is from Evans Data Corp's 2009 Developer Relations Conference. …

This presentation is from Evans Data Corp's 2009 Developer Relations Conference.

It is about how to approach code sharing (Open Source) to enable a developer community.

(We do not confuse Open Source with Free Software. You shouldn't Either.)

Published in Technology , News & Politics
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
945
On SlideShare
0
From Embeds
0
Number of Embeds
2

Actions

Shares
Downloads
15
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide
  • Alex intro Ted intro

Transcript

  • 1. To Open Source Or not to Open Source... Where's the ROI? Alex Barnett Group Manager, Developer Relations [email_address] Twitter: alexbarnett Ted Haeger Manager Touchatag Developer Network [email_address] Twitter: reverendted
  • 2. What We’re Going to Talk About
    • Terminology
    • Considerations
    • ROI & Open Source
    • Risks to manage
    • Groundwork to maximize benefits
  • 3. Terminology Open Source Free Software Copyright (Free Software) Licenses Copyleft
  • 4. Considerations for this Decision
    • Choose wisely
      • What to open
      • What not to open
    • Identify where value lies
    • Take the Outsider’s View
    Benefit to Company Benefit to Developers Open source is not a Strategy Mutual Value
  • 5. Considerations for this Decision
    • Ask not what your open source strategy should be…
    • Ask how you can enable developers to…
      • Use your services more effectively
      • Create more value for themselves, and for you
      • Do more, faster
        • Better API(s)?
        • Better documentation?
        • Better community infrastructure?
        • Open Source?
          • Open Source must support a broader strategy and goals
  • 6. Two Paths You Can Go By
    • Participate
      • Share Your Own Code with your Community
      • Requires
        • Actual demand
        • Care in planning & execution
      • Possible Objection
        • Let’s address them over the rest of the session…
      • Examples
        • Mozilla Foundation
        • Linux distro vendors
        • Intuit Partner Platform
    • Facilitate
      • Enable Community Members to Share Code
      • Requires
        • Loyal, established community
        • Value in what could be shared
      • Possible Objection
        • “ You want us to share our code, but you don’t share yours?!”
      • Examples
        • Microsoft CodePlex
        • Google Code
        • Intuit Partner Platform
  • 7.
    • Real risks vs. real benefits
    How to Think About ROI for OSS Are these related to “Participate” or “Facilitate”? Real Risks Real Benefits
    • 1. Surrendering IP by blunder
      • Too permissive a license destroys corporate value
      • Don’t actually own what you are about to OS
    1. Broader developer appeal 2. Poor commitment or follow-through will cause loss of credibility
    • 2. Non-code contributions
      • - bug reports
      • - features suggestions
      • - great ideas
    3. It flunks…no uptake
    • 3. Code contributions
      • - but keep your expectations realistic
    • 4. Exposes flaws in the product
      • - No more “security by obscurity”
    4. Talent self-identification
    • 5. Underestimating the commitment required
      • - Inundation overwhelms personnel
  • 8.
    • Bogus risks vs. bogus benefits
    How to Think About ROI for OSS These are all education & communication issues Are these related to “Participate” or “Facilitate”? Bogus Risks Bogus Benefits 1. “It gives away all our IP for no benefit!”
    • 1. “Large-scale code contributions”
      • - “Look ma, free work!”
    2. “No one will pay us anymore” 2. “Everyone will love us!” 3. “Security concerns make it impossible” 3. “Everyone will use our product!”
  • 9. Don’t Be Fooled Reality The cost of running an open source project well will offset any labor saved through engineering contributions. Biggest Myth of Open Source? Free engineering! Your engineers will still do all of the major work! But you may get significant long tail benefits, such as bug reports, feature suggestions, the occasional patch
  • 10. Mitigating the Risks Are these related to “Participate” or “Facilitate”? Real Risks Mitigation 1. Surrendering IP by blunder
    • Determine what IP matters
    • Due diligence
    • Use Licenses wisely
      • Understand Permissive vs. Strong Copyleft
    2. Lack of commitment and follow-through
    • Get management buy in & commitment
    • Manage expectations (inside & outside)
    • Plan beyond 12 months
    • Assign the required resources (people)
    • Involve passionate, experienced employees
    3. It flunks — no take up
    • Design outside-in, not inside-out
    • Get early external validation – pilot project
    • Create Advisory Council
    4. Exposes flaws in the product
    • Schedule engineering for full code review
    • Hire a black hat
    5. Underestimating the commitment required
    • Listen to advisory council
    • Staff accordingly
  • 11. Groundwork to Maximize Benefits
    • Don’t use a proprietary process to plan an OSS
      • Be open & overt about your goals
      • Consider what are not your goals
      • Execute on clear communications regimen
      • Listen to external advisors
      • Develop a pilot program, validate and seed
  • 12. Groundwork to Maximize Benefits
    • Find the Right People
      • Identify & Involve passionate, experienced employees
      • If opening your own code, assign a maintainer
      • Plan to handle volume
        • Prioritize people; don’t let trolls bait you
    • Use the Right Infrastructure
      • Where/how to host code, what software, etc
    • Decide on the Right Licenses
      • Define how you will handle copyright
      • (e.g. Sun’s Contributor License Agreement)
  • 13. Big Take-Aways
    • Is OSS the best way to help your developers?
    • Is it “Facilitate” or “Participate”
    • Distinguish between Real Risks vs. Bogus Risks
    • Do the groundwork
  • 14. Q & A
    • Alex Barnett
    • Email: alex_barnett@intuit.com
    • Blog: alexbarnett.net/blog
    • Twitter: alexbarnett
    • Web: developer.intuit.com
    • Ted Haeger
    • Email: [email_address]
    • Blog: reverendted.wordpress.com
    • Twitter: reverendted
    • Web: developer.touchatag.com
  • 15. Scapbook
    • Don’t use a proprietary process to plan an Open Source project!
      • Use external advisors…a mix of:
        • Licensing specialist
        • Free software “zealot”
        • Free and Open Source “pragmatist”
        • Industry analyst
        • Peers in your position with successful OS experience
  • 16. Scrapbook II
    • Long tail of code contributions
      • Show 90% of code contribution made by <5% of community
      • Show how the tail is the broad developer appeal
  • 17. Scrapbook III What you want What they want What they create
  • 18. Scrapbook IV Know your licenses