Download to read offline
More Related Content
Similar to How To (Not) Open Source - Javazone, Oslo 2014
How To (Not) Open Source - Javazone, Oslo 2014
- 2. Blueflood: A casestudy in turning a large piece of infrastructure software into an open source project Javazone 2014 • Rackspace • @gdusbabek
- 3. Blueflood:" How Ilearned the hardest problems are not technical Javazone 2014 • Rackspace • @gdusbabek
- 4.
- 5.
- 6.
- 7.
- 8. About Me OpenSource Veteran
- 9.
- 10.
- 11.
- 12.
- 13.
- 14. About Blueflood Opensource 2013
- 15. About You Contemplating releasing a project
- 16. About You Havingtrouble with open sores
- 17. About You Havingtrouble with open source
- 18. YOU ARE IN THE RIGHT PLACE
- 19.
- 20.
- 21.
- 22.
- 23. Objectives History 101 Business 101
- 24.
- 25. We made thisthing
- 26. We did somethings right
- 27. We did somethings wrong
- 28.
- 29. We Learned Somethings
- 30.
- 31.
- 32.
- 33. In the beginningit was ALL open source
- 36. In 1953 theA-2 shipped with all of its source code
- 37.
- 38. Changed by late1960s
- 39.
- 40.
- 41. 2. Growing Market (Fewer engineers)
- 42. Natural Scarcity +More Work To Do ______________________________ Expensive
- 43.
- 44.
- 45. Not much opensource activity
- 46.
- 47. Modern open sourceadvocacy
- 48.
- 49. Continued growth wellinto 2000s
- 50.
- 51. Open source workis appealing Good for publicity Trendy
- 52. Hacker News Cycle Y 1. ▲ Release Something 2. ▲ Post it on HN 3. ▼ See interest in the project 4. ▲ Secondary interest in your business
- 53. Hacker News Cycle Not conducive to a healthy ecosystem Y
- 54. So Many Waysto Collaborate
- 55. I " ♥" PULL REQUESTS
- 56. I " ♥" PULL REQUESTS
- 57. Stimulating Professional Conversations 140 Characters at a time
- 59.
- 60.
- 61. Releasing a projectis easy
- 62. Making it successfulis very hard
- 63. What is “successful” anyway?
- 64. “We reviewed andmerged 10 pull requests in our OS project this week. It was a lot of work. It was beautiful and awesome!”
- 66. “You didn't mergeany features we needed to run our business this week. I’m going to eat your family!”
- 68. Success is in the eyes of the beholder
- 69.
- 70. Current State Differentways of releasing a project
- 71. Code Dump (SeaTurtle Approach)
- 72. Lay a bunchof eggs, then run off.
- 73. Code Dump (SeaTurtle Approach) What you see: • code • Probably no wiki • Little to no-code activity • "Throw it over the wall"
- 74. Code Dump (SeaTurtle Approach) What you get: • Very little community • Infrequent support • No real ownership
- 75. worst kind ofopen source only adds noise
- 76.
- 77. Let someone elsesit on our eggs.
- 78. Primary Sponsorship (Cuckooapproach) One entity does most of the work • Free for everybody to use • Good stewards • Could be a good community and support • Not welcoming to outside contributors
- 79.
- 80. Incubation Recruit committers Build community Real Work
- 81. Incubation Most difficult Long lasting Provides for lifecycle Meritocracy
- 82. Good News: Noneof these are wrong
- 83. Bad News: Noneof these are wrong
- 86. Why is project X open source?
- 87.
- 88. Type 1 Itmakes money • Profit center • AdWords, Github hosting
- 89. Type 2 Itdoesn't make money • Cost center • Your database • Your queueing software
- 90. Reduce the expenseof cost centers Increase profitability of profit centers
- 91. Nobody will releasesource for profit centers.
- 92. Everybody wants to release the source of their cost centers.
- 93.
- 94.
- 95. Free doesn’t makeit less expensive.
- 96. Ok. That washarsh. (End of business lesson)
- 97. What kind offuture?
- 98. Think about what you really want.
- 100. Software should befrictionless.
- 101.
- 102.
- 103. My Theorem 1.Easy to use 2. Community 3. Quality
- 104. CEQ? QEC? Itprobably will not catch on.
- 105. 10 minute test Too many projects fail this
- 106. Proposition We canimprove the experience of using open source software by improving the process of creating it.
- 107. Our Humble Goal We can improve the experience of using open source software by improving the process of creating it.
- 108. DO THESE THINGS (7)
- 109. 1. Understand yourmotivations
- 110. Why are you releasing this code?
- 111. For the recognition? Don't do it!
- 112. You want tohelp others? Why?
- 113. I dunno. Don’tdo it!
- 114. Because it’s goodfor business Ok. Do it!
- 115. You wan tocommoditize something? That’s interesting.
- 116.
- 117.
- 118. Offload Others willdo the work Commoditize Reduce the cost for everybody
- 119. Yes, do it,definitely!
- 120. 2. Then focuson execution
- 121. Code dump ==Bad
- 122. Primary sponsorship: Works,but still expensive for you.
- 123. Incubate: Works, butso much initial effort!
- 124. Clearly this iswhere things get Hard™
- 125. 3. Define howyou will measure success
- 126. Can be anything But make it explicit And write it down Publicly
- 127. WARNING: The followingcontains controversial opinions. Viewer discretion is advised.
- 128. 4. Split YourTeam Team Foo: Production Team Bar: Open Source
- 130. Case α: Bugin Production All hands on deck Open source work grinds to a halt
- 131. Case β: BigOS Feature Focus, Focus, Focus Product work becomes a distraction
- 132. 5. Invest indocumentation
- 133. More than aday Ok. At least a week. Maybe more
- 134. Landing Website Wiki 10 minute guide
- 135. And practice the 10 minute guide!
- 136. 6. Set upcommunication channels
- 137. Mailing lists IRC Twitter
- 138. RESPOND TO EVERY BIT OF COMMUNICATION
- 139. Black Hole ==Bad Nobody is using it Reflection of quality
- 140. 7. Participate &Advocate
- 141. Tell your story Like minds will find you
- 142. Difficult for some Just keep practicing You can get good at it even if you don’t like doing it.
- 143. Wait, what wereall those things? 1. Understand your motivations 2. Focus on execution 3. Measure Measure Measure 4. Split your team 5. Document all the things 6. Communicate with all the things 7. Participate & Advocate
- 144. How will weknow when we’re there?
- 145. Our Humble Goal Change the experience of using software by improving the process of creating it.
- 146. Evidence of Success What will our success look like? How shall we measure it?
- 147. Evidence of Success When open source no longer hinders us
- 148. Evidence of Success When you and others are able to leverage open source projects to run your business with: – More speed – Less resources – Greater focus
- 149. Evidence of Success:A Casualty Fewer open source projects.
- 150. Evidence of Success:A Casualty What about the bazaar?
- 151. Evidence of Success Healthier Ecosystems
- 152. Evidence of Success Easily identified lifecycle Young: growing & changing Mature: less risk
- 153. Evidence of Success You know how to engage the community and support channels
- 154. Evidence of Success Your split team does not feel compromised or stretched They aren't riding two horses Your leadership is comfortable with this.
- 155. This all soundsreally good, but…
- 156. Return on investment Staffing engineers who work on 100% on open source Perception: expensive cost centers
- 157. One Approach: Changethat perception Dubious proposition
- 158. The Problem: Thiswill probably not last long. Not a good approach.
- 159.
- 160. Split your team, but don’t tell anybody.
- 161. Sneaky, but that doesn’t prove ROI.
- 162. Measure Everything Provethat that things are better Use science!
- 163. Support tickets Monitoringalerts Days spent fixing bugs
- 164. Prepare for unexpectedresults Measurements may indicate that you’re wasting time or other resources.
- 165. Be honest withyourself
- 166.
- 167. History 101 +Business 101 _______________ Undeniable Insight
- 168. • Things arechanging like they never have • Commoditization of software + hardware • Accelerating pace
- 169. • Become adept • Less friction • More time • Time is money • Solid return on investment
- 170. Observed Trend! TheOpen Source Startup Model Venture Backed Great supporters of open source ROI easily justified
- 171.
- 172. It’s the leastbad thing.
- 173. Product of prevailingattitudes in non VC companies 1. Contributing to open source is a drain on resources 2. Companies are being short sighted
- 175. The Choice IsOurs
- 176.
- 177. Consider carefully yourchoice to release a project.
- 178.
- 179.
- 180. Some images requiredattribution boring https://www.flickr.com/photos/phoenixdailyphoto/1467681879 professor https://www.flickr.com/photos/judy-van-der-velden/4468986943 tank https://www.flickr.com/photos/defenceimages/14465175042 tools https://www.flickr.com/photos/75905404@N00/7126147125 businessmen https://www.flickr.com/photos/sgis/6532363 rainbow https://www.flickr.com/photos/liesforaliar/6057583336 trash https://www.flickr.com/photos/en321/14611573210 skunk https://www.flickr.com/photos/i_am_just_a_cloud/1079804050 inspire https://www.flickr.com/photos/mikeyphillips/14654963066
Editor's Notes
- #19 By the end of this presentation, you should be able to confidently answer several questions.
- #25 This would be a boring presentation if I only told you about my experience with releasing Blueflood as an open source project. https://www.flickr.com/photos/phoenixdailyphoto/1467681879
- #28 We did some things wrong
- #31 First, I want you to be able to see the big picture.
- #34 In the beginning, just about all software was open source
- #162 Brings me back to the point of demonstrating that open source is good for business. Still, at some point, you need to prove that either releasing code or contributing to a project yields a return on the investment.