Overcoming Obstacles to Mainlining

From eLinux.org
Jump to: navigation, search

Information about overcoming obstacles to mainlining.

Tim Bird gave a presentation about overcoming obstacles to mainlining, at ELC Europe 2014 in Düsseldorf, Germany.

Here are the slides for the talk: Media:Overcoming_Obstacles_to_Mainlining-ELCE-2014-with-notes.pdf

Please note that a few cosmetic errors were fixed, as well as 2 pages were added at the end with notes or suggestions from people I talked to at the event.


Here is the abstract for the talk:

Many companies struggle with contributing to Open Source projects. This talk will identify key difficulties that many large companies face in making contributions, and provide tips and lessons learned for overcoming these obstacles. Some of the difficulties discussed will be: version gap, expertise problems (an example of which is the "proxy problem"), wrongly-abstracted code, process mismatch, and social and attitudinal barriers. This will not be yet another talk on CodingStyle, but a more high-level look at structural problems inside companies and the industry that prevent meaningful engagement within the open source community.

The goal of this talk is to help individual developers and companies identify and implement practices that will accelerate their participation in open source, so that they can enjoy more of the value of open source besides just the open code base.


  • Intro
    • Anna Karenina Principle
      • "Happy families are all alike; every unhappy family is unhappy in its own way"
      • There are lots of ways to fail, but only a few ways to succeed
1. Identify obstacles
2. ???
3. Profit
(replace step 2 with "overcome obstacles"
  • Obstacles
    • no recognition of upstream at all
      • waterfall and squirtgun metaphor
    • Version Gap
      • You can't actually help if you're working on the wrong thing
      • The kernel changes more quickly than you think
    • Expertise problems
    • Quick Hacks
      • It takes longer to write good code
      • Good code might not be better for you!
    • Bad abstractions
    • Process mismatch
      • Not using git - you're doomed
      • SubmittingPatches - death by a thousand cuts
    • Social barriers
      • misunderstanding the currency - see "And then there were none"
      • fear of failure
    • Lack of support
      • Middle managers don't get it, Execs won't prioritize it.
  • Survey results
  • Overcoming them
  • Words from the sages
  • Summary of Best Practices

Key Points