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

What We’re Going to Talk About Terminology Considerations ROI & Open Source Risks to manage Groundwork to maximize benefits

Terminology

Considerations

ROI & Open Source

Risks to manage

Groundwork to maximize benefits

Terminology Open Source Free Software Copyright (Free Software) Licenses Copyleft

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

Choose wisely

What to open

What not to open

Identify where value lies

Take the Outsider’s View

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

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

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

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

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

Real risks vs. real benefits

1. Surrendering IP by blunder

Too permissive a license destroys corporate value

Don’t actually own what you are about to OS

2. Non-code contributions

- bug reports

- features suggestions

- great ideas

3. Code contributions

- but keep your expectations realistic

4. Exposes flaws in the product

- No more “security by obscurity”

5. Underestimating the commitment required

- Inundation overwhelms personnel

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!”

Bogus risks vs. bogus benefits

1. “Large-scale code contributions”

- “Look ma, free work!”

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

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

Determine what IP matters

Due diligence

Use Licenses wisely

Understand Permissive vs. Strong Copyleft

Get management buy in & commitment

Manage expectations (inside & outside)

Plan beyond 12 months

Assign the required resources (people)

Involve passionate, experienced employees

Design outside-in, not inside-out

Get early external validation – pilot project

Create Advisory Council

Schedule engineering for full code review

Hire a black hat

Listen to advisory council

Staff accordingly

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

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

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)

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)

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

Is OSS the best way to help your developers?

Is it “Facilitate” or “Participate”

Distinguish between Real Risks vs. Bogus Risks

Do the groundwork

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

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

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

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

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

Long tail of code contributions

Show 90% of code contribution made by <5% of community

Show how the tail is the broad developer appeal

Scrapbook III What you want What they want What they create

Scrapbook IV Know your licenses