Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.

LAS16-200K2: Corporate Open Source Fail – Sarah Sharp

768 Aufrufe

Veröffentlicht am

LAS16-200K2: Corporate Open Source Fail – Sarah Sharp
Speakers: Sarah Sharp
Date: September 27, 2016

★ Session Description ★
Title: Corporate Open Source Fail

What makes companies with good intentions fail so miserably at open source? How can we (as engineers and managers) influence our bosses to “do the right thing”?

“We’ll just make a new open source community.”
“You can fix up that code later.”
“It’s taking too long to get this upstream.”

Many companies have good intentions of being productive open source citizens. However, those good intentions often get thrown under the bus when product deadlines or legal issues loom. This talk will walk through a series of common corporate open source pitfalls and the executive and manager thinking behind those decisions. We’ll discuss ways engineers and managers can develop empathy for their corporate overlord’s needs, in order to influence their strategies around open source.


Sarah is the founder of Otter Tech, a consulting company offering open source training, software development, and diversity consulting. http://otter.technology

Sarah Sharp is a Linux and open source developer, and has been running Debian-based Linux systems since 2003. She was a Linux kernel developer from 2006 to 2013, and is the original author of the Linux USB 3.0 xHCI host controller driver.Sarah is also a co-coordinator for Outreachy, a paid internship program for increasing diversity in open source programs. Applications are open to women (cis and trans), trans men, and genderqueer people, and United States residents of any gender who are Black/African American, Hispanic/Latin@, American Indian, Alaska Native, Native Hawaiian, or Pacific Islander.

★ Resources ★
Etherpad: pad.linaro.org/p/las16-200k2
Presentations & Videos: http://connect.linaro.org/resource/las16/las16-200k2/

★ Event Details ★
Linaro Connect Las Vegas 2016 – #LAS16
September 26-30, 2016

Veröffentlicht in: Technologie
  • Als Erste(r) kommentieren

  • Gehören Sie zu den Ersten, denen das gefällt!

LAS16-200K2: Corporate Open Source Fail – Sarah Sharp

  1. 1. Corporate Open Source FAIL
  2. 2. What motivates business decision makers: $$$ Is there a big enough market? How do we get our customers to pay us? What's the minimum viable project to get them to pay us? How do I protect my "turf" from competitors?
  3. 3. Why do companies do open source? ● Competitive advantage ● Common shared resources ● Sell hardware, services, or data ● Customers require it Why do companies do open source? Competitive advantage They sell hardware, services, or data and give away software Their customers demand it $$$ thinking leads to common pitfalls that violate key principals of the open source community
  4. 4. CC-BY Jeroen van Luin https://www.flickr.com/photos/-jvl-/10277663944/ Open source devs see repeating patterns in corporations that try to participate in open source Is there a way for developers (and product managers, evangalists, tech writers, etc) convince the business decision makers how to do open source right? Yes and no, because it's very slow to change corporate culture and...
  5. 5. CC-BY-SA Liz Henry https://www.flickr.com/photos/lizhenry/8067929583/in/photostream/ “Process is scar tissue from past failures.” - @bridgetkromhout ...sometimes people have to get burned a couple times. Explain hazards and BKMs Won't help until they get burned Cultural change is hard Unless things get painful, they will stick with what they know How do you motivate decision makers to change?
  6. 6. Open source means transparencytransparency
  7. 7. Binary Blobs CC-BY Dan Lingard https://www.flickr.com/photos/idleman/3603842242 Closed source binaries in open source projects The locked box where you keep your secrets Licensing, FCC regulations, or IP concerns Fear of competition - "If we share this secret sauce, our competitors will win!"
  8. 8. Binary Blobs CC-BY-SA Micah Elizabeth Scott https://www.flickr.com/photos/micahdowty/4317055158/ Reverse engineering (tracing with debuggers or packet sniffers, disassembling, hijacking the firmware update process, poking at security holes) good luck explaining this to managers
  9. 9. Binary Blobs CC-BY Marco Bellucci https://www.flickr.com/photos/marcobellucci/3534516458 Socratic questioning - What exact IP are we hiding? Are there patents for that IP we need to protect? Would someone "versed in the art" be able to recreate our IP? What is the business impact if that IP was leaked? Are there already open source projects available that do most of the same things? Work with lawyers to understand your legal requirements - break through the FUD of what "might happen"
  10. 10. Open source developers release frequentlyrelease frequently
  11. 11. Upstreaming Technical Debt CC-BY-SA Christoph Strässler https://www.flickr.com/photos/christoph_straessler/10106410603 “We'll just fork it" Effort to upstream and rewrite or rearchitect is an unnecessary cost in biz dev's eyes If you're always building a new product, it's easy to fork and forget. Upstreaming is more cost-effective for businesses that build on the same code base for future projects, or re-use features in a fast-moving code base.
  12. 12. Upstreaming Technical Debt CC-BY i ♥ happy!! https://www.flickr.com/photos/ilovehappy/606583152/ Hard to update older designs, if you have technical debt. Technical debt builds up Customers don't get the latest software, impacting their security and time to market Unhappy customers go elsewhere, impacting your bottom line
  13. 13. Upstreaming Technical Debt CC-BY StockMonkeys.com Short term: convince your boss to eliminate the technical debt that's most difficult to maintain. Long term: build a relationship with upstream to make code submissions easier
  14. 14. Open source developers collaboratecollaborate
  15. 15. Creating perfection... CC-BY Kristian Dela Cour https://www.flickr.com/photos/the-majestic-fool/2919204371/ Many developers are worried about their code being public They spend a lot of time polishing their code and trying to get it to be “perfect”
  16. 16. Creating perfection... or polishing turds? CC-BY Living Off Grid https://www.flickr.com/photos/knowmybackyard/5314350215 Many developers are worried about their code being public They spend a lot of time polishing their code and trying to get it to be “perfect”
  17. 17. Open source developers define project directiondefine project direction
  18. 18. Short term: convince your boss to eliminate the technical debt that's most difficult to maintain. Long term: build a relationship with upstream and get your code in early, not during product release crunch time.
  19. 19. Don't treat open source like a release manager Short term: convince your boss to eliminate the technical debt that's most difficult to maintain. Long term: build a relationship with upstream and get your code in early, not during product release crunch time.
  20. 20. Don't treat open source like a release manager Treat open source like an architect Short term: convince your boss to eliminate the technical debt that's most difficult to maintain. Long term: build a relationship with upstream and get your code in early, not during product release crunch time.
  21. 21. Open source projects have release scheduleshave release schedules
  22. 22. URGENT!!! RELEASE NOW!!! CC-BY-ND Nick Perla https://www.flickr.com/photos/thewhitewolves/6286763069/ Management and project managers are often pushing engineers to release In English, we have a saying, “Your fire is not my emergency.”
  23. 23. URGENT!!! RELEASE NOW!!! CC-BY-SA Bill Burris https://www.flickr.com/photos/billburris/3630019483/ Your corporate timeline is not something the open source community cares about Project managers often treat open source as release managers, not partners They imagine that once the code is merged or even made public, everyone suddenly has it. Takes time to get into distros.
  24. 24. URGENT!!! RELEASE NOW!!! Apr 2016 Mar 2016 Feb 2016 Jan 2016 Dec 2015 Nov 2015 Oct 2015 Sep 2015 Aug 2015 16.04 Release 4.4 Release 4.4 Code Freeze 4.4 Merge Window Code Review Need to educate management about FOSS code freeze & release deadlines Example: get a webcam kernel driver in Ubuntu 16.04 (April 2016 release) Kernel 16.04 shipped with was 4.4 based v4.4.0 shipped in Jan 2016 4.4 code merge window start Nov 1 2015 code approved 4.3-rc4 - Oct 4 2015 Need 3-8 weeks code review & re- architecting - August or Sept 2015 9 months from start of code review to in a Linux distribution
  25. 25. Open source projects accept contributionsaccept contributions
  26. 26. Available Source != Open Source CC-BY-SA Gui Carvalho https://www.flickr.com/photos/gcarvalho/29457378 Open source is more than a license. It's about collaboration. Some customer wants it to be "open source" to use, but doesn't care about giving back Throw it over the wall: Open in name only, no external contributions accepted. One or two companies participating in a project "Minimum viable product" to satisfy the "open source requirement"
  27. 27. Available Source != Open Source CC-BY Katherine Riley https://www.flickr.com/photos/rileyssmiling/9482508646/ Failure to bring outside perspective Missed market opportunity from narrow thinking or insular requirements
  28. 28. Available Source != Open Source CC-BY Pete Birkinshaw https://www.flickr.com/photos/binaryape/2915056465/ What can we do to change this? Internal pressure to collaborate more often doesn't work Need external motivation: Product flops because it doesn't address all customer needs Other companies start a competing group or project Bad press and constant pressure from external communities crucial to biz needs
  29. 29. Open source encourages the best technical solutionsthe best technical solutions Joke: of course, everyone has different opinions about what the “best” solution is
  30. 30. Reinventing the Wheel CC-BY Health Gauge https://www.flickr.com/photos/healthgauge/8183527181/ Everyone is trying to invent the next big thing Customers will try out the latest shiny new watch just for fun Companies often assume open source is like that VPs and marketers think developers will try out a new open source project, fall in love, and immediately switch to the latest web framework
  31. 31. Reinventing the Wheel http://xkcd.com/927/ And that means developers have another new project to evaluate
  32. 32. Reinventing the Wheel CC-BY Robert Couse-Baker https://www.flickr.com/photos/29233640@N07/14859431605/ Disrupting an existing open source community is hard. Developers are quick to experiment with a new open source project, but uptake in shipping products is very slow. You need to have a track record of support, consistent updates, and the features your customers really need.
  33. 33. No amount of marketing $$$ will buy developer trust in your open source community It takes years of hard work (writing articles and blog posts, answering questions on hackernews and IRC, and a constant community presence) in order to make an open source project successful. No marketing $$$ can duplicate that Instead, companies are buying core developers to promote their products. Good? Bad? Discuss
  34. 34. Avoiding Corporate Open Source Fail ● Question hiding info ● Reduce technical debt ● Treat open source as architects ● Submit early, submit often ● Disruption takes time & community
  35. 35. Thanks! Sarah Sharp Otter Tech Open Source Training sharp@otter.technology