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. Bio 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 http://www.linaro.org http://connect.linaro.org

1. Corporate
Open Source
FAIL

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. 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. 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. 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. Open source means
transparencytransparency

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. 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. 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. Open source developers
release frequentlyrelease frequently

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. 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. 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. Open source developers
collaboratecollaborate

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. 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. Open source developers
define project directiondefine project direction

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. 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. 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. Open source projects
have release scheduleshave release schedules

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. 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. 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. Open source projects
accept contributionsaccept contributions

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. 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. 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. Open source encourages
the best technical solutionsthe best technical solutions
Joke: of course, everyone has different
opinions about what the “best” solution
is

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. Reinventing the Wheel
http://xkcd.com/927/
And that means developers have another
new project to evaluate

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. 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. 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. Thanks!
Sarah Sharp
Otter Tech
Open Source Training
sharp@otter.technology