What!s In It For Me?
How Your Company Can Benefit
  from Open Sourcing Code

Ben Collins-Sussman & Brian W. Fitzpatrick
   ...
Overview
  These are our opinions
•
• Target audience: corporations and folks in them
• Different strategies for open sour...
Why Go Open Source?

  Some sort of net gain
•
• Create better software
• Create a real relationship with your users
• Cho...
Measuring “Health” of Open Source

  Lots of usage (not users!)
•
• A number of active developers
• Constant improvements ...
Open Source Strategies
0. “Fake Open Source” Approach

  “Open Source” your code, but don!t use an OSI-
•
  approved license
• Pros:
  – PR splas...
1. “Throw Code Over Wall” Approach

  Post tarball of the code, then walk away.
•
• Pros:
  – PR splash (maybe)
  – Effort...
2. Develop Internally, Post Externally
  In-house development, public repository
•
• Pros:
  – PR splash
  – Occasional vo...
3. Open Monarchy

  Public discussion, public repository
•
• Committers are mostly employees, occasionally a
  volunteer i...
3. Open Monarchy

  Pros:
•
  – PR splash
  – Even more cred from techies
  – Better quality volunteers; they can particip...
4. Consensus-Based Development

  Almost everything is public
•
• Decisions are based on consensus of the committers
• Com...
4. Consensus-Based Development
  Pros:
•
  – Continuously increasing PR benefits
  – Long-term, sustainable communities
  –...
Why We Think This Is Best
  Traditionally companies isolate developers from
•
  users
  – “They can be more productive”
• ...
BUT BUT...
        I Don!t Want To Lose Control!

•   “Strangers will force me to do things!”

•   “Nasty people will hija...
Answer: Craft your Community

  Choose a well-scoped mission
•
• Have your devs establish a strong, respectful culture
• S...
What about Forking?

  Extremely rare in consensus-based development
•
• Majority always moves in one direction
• Really h...
How To Build
a Consensus-Based
Open Source Project
1. Come up with a Goal.
  Something useful
•
• Something people can be excited about
• Might only benefit your company indi...
2. Write a Mission Statement

  Be very careful about scoping
•
  – too broad: attracts the wrong contributors
  – too nar...
3. Prepare your Team

  Read Karl!s book!
•
  Discuss it
• Learn how to set
  community tone
• Decide on process for
  adm...
4. Move all Development to Public

  Launch public mailing lists, repository, bug tracker
•
• Minimize use of internal mai...
Summary
  Choose strategy based on your goals
•
• There are tradeoffs
• We think consensus-based creates the best software
Q&A
Ben Collins-Sussman & Brian W. Fitzpatrick
          sussman@google.com
             fitz@google.com
Upcoming SlideShare
Loading in...5
×

Os Fitzpatrick Sussman Wiifm

2,050

Published on

Published in: Economy & Finance, Technology
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
2,050
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Os Fitzpatrick Sussman Wiifm

  1. 1. What!s In It For Me? How Your Company Can Benefit from Open Sourcing Code Ben Collins-Sussman & Brian W. Fitzpatrick Google OSCON: July 27, 2007
  2. 2. Overview These are our opinions • • Target audience: corporations and folks in them • Different strategies for open sourcing code • Pros and cons of each • Prescribe best practices
  3. 3. Why Go Open Source? Some sort of net gain • • Create better software • Create a real relationship with your users • Choose your goals – PR? – Goodwill from techies? – Free labor? – Change the industry, take over world?
  4. 4. Measuring “Health” of Open Source Lots of usage (not users!) • • A number of active developers • Constant improvements and releases • Remember: no community == dead software
  5. 5. Open Source Strategies
  6. 6. 0. “Fake Open Source” Approach “Open Source” your code, but don!t use an OSI- • approved license • Pros: – PR splash – Effortless • Cons: – You!re not open source – You!re missing the benefits – Open Source zealots may burn your house down
  7. 7. 1. “Throw Code Over Wall” Approach Post tarball of the code, then walk away. • • Pros: – PR splash (maybe) – Effortless • Cons: – No community to keep software alive (bit-rot) – Real techies give little cred
  8. 8. 2. Develop Internally, Post Externally In-house development, public repository • • Pros: – PR splash – Occasional volunteers can send patches – A bit of cred from real techies • Cons: – Community & momentum is wholly internal – External community likely to form elsewhere – Attracts only “follower” developers. (No bus keys!) – General distrust: only care about corporate agenda
  9. 9. 3. Open Monarchy Public discussion, public repository • • Committers are mostly employees, occasionally a volunteer is given the keys • One entity (corporation, lead developer) “rules” project and makes all decisions
  10. 10. 3. Open Monarchy Pros: • – PR splash – Even more cred from techies – Better quality volunteers; they can participate in discussions, sometimes commit directly – Results in better software • Cons: – Community not long-term sustainable – High risk of angry revolutions and forking – General distrust: only care about corporate agenda
  11. 11. 4. Consensus-Based Development Almost everything is public • • Decisions are based on consensus of the committers • Commit privilege must be earned by everyone
  12. 12. 4. Consensus-Based Development Pros: • – Continuously increasing PR benefits – Long-term, sustainable communities – Complete techie cred – High quality volunteers (full bus keys) – Trust from other companies and participants – Results in even better software • Cons: – Little short-term benefit – In the short-term, project agenda must come first – Hard Work – You need to hire strong leaders
  13. 13. Why We Think This Is Best Traditionally companies isolate developers from • users – “They can be more productive” • Results in better software • If done right, internal developers will see the benefits
  14. 14. BUT BUT... I Don!t Want To Lose Control! • “Strangers will force me to do things!” • “Nasty people will hijack the project!”
  15. 15. Answer: Craft your Community Choose a well-scoped mission • • Have your devs establish a strong, respectful culture • Set the discussion tone carefully • Have a well-defined process for making decisions • Watch our quot;poisonous people! talk ;-) Remember, you can set the stage, but it takes effort •
  16. 16. What about Forking? Extremely rare in consensus-based development • • Majority always moves in one direction • Really hard for a hive to swarm without at least 50% of the bees
  17. 17. How To Build a Consensus-Based Open Source Project
  18. 18. 1. Come up with a Goal. Something useful • • Something people can be excited about • Might only benefit your company indirectly, or in the long-term Examples: Collabnet, Google. •
  19. 19. 2. Write a Mission Statement Be very careful about scoping • – too broad: attracts the wrong contributors – too narrow: attracts no interest at all • Non-goals are important Examples: Subversion, GWT •
  20. 20. 3. Prepare your Team Read Karl!s book! • Discuss it • Learn how to set community tone • Decide on process for admitting new committers • Learn how to diffuse poisonous people • Thicken everyone!s skin
  21. 21. 4. Move all Development to Public Launch public mailing lists, repository, bug tracker • • Minimize use of internal mailing lists! – Develop policy for working with internal devs • Do some PR to attract volunteers • Start with one mailing list if possible, split later
  22. 22. Summary Choose strategy based on your goals • • There are tradeoffs • We think consensus-based creates the best software
  23. 23. Q&A Ben Collins-Sussman & Brian W. Fitzpatrick sussman@google.com fitz@google.com

×