Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Open Source Compliance at Twitter

Open Source Compliance at Twitter

Open source compliance at Twitter, presented at the Open Compliance Summit Asia 2012 hosted by the Linux Foundation.

Chris Aniszczyk

November 15, 2012
Tweet

More Decks by Chris Aniszczyk

Other Decks in Programming

Transcript

  1. Open Source Compliance at Twitter
    Philosophy, Governance and Best Practices
    Chris Aniszczyk (@cra)
    Open Compliance Summit Asia 2012

    View Slide

  2. Agenda
    Introduction and Brief History
    Open Source at Twitter
    Philosophy and Culture
    War Stories and Lessons Learned
    Best Practices
    Conclusion
    Q&A

    View Slide

  3. What is Twitter?
    “Instantly connect people
    everywhere to what is most
    meaningful to them...”

    View Slide

  4. 2006: A simple idea...

    View Slide

  5. 2008: Growing Pains

    View Slide

  6. 2009... Crazy Growth

    View Slide

  7. Miyazaki
    25,088 TPS
    BTW, Japan holds TPS Record!

    View Slide

  8. 2010+: Build a company!

    View Slide

  9. Now: Growth Continues...
    140M+ Active Users
    400M+ Tweets per Day
    33+ Languages Supported
    1300+ Employees Worldwide
    50% Employees are Engineers
    100+ Open Source Projects

    View Slide

  10. Open Source at Twitter
    We run and depend on it

    View Slide

  11. Twitter Runs on Open Source

    View Slide

  12. Engineers ran the asylum...

    View Slide

  13. Code dumping happens...

    View Slide

  14. Open Source Office
    "The Open Source Office directs all open source efforts
    (compliance, data and standards) at Twitter and supports
    all initiatives related to our engineering outreach and
    contributions to the broader software community."

    View Slide

  15. Created Open Source Office in 2011

    View Slide

  16. Open Source Review Process
    Simple, Comfortable and Audit-able
    Tools built on “JIRA Workflows”

    View Slide

  17. Where? Default to GitHub
    Also see http://twitter.github.com

    View Slide

  18. Licensing Guidelines: Outbound
    We prefer liberal licenses for adoption
    Default to APLv2 in most cases
    Prefer MIT license in front-end JS
    Compatible with respective community
    Clojure? EPL, NodeJS? MIT

    View Slide

  19. Licensing Guidelines: Inbound
    OSI Certified Licenses Only
    List of Approved and Banned Licenses
    Motto: Trust but Verify
    Extra Scrutiny at Distribution Points
    Less Scrutiny Elsewhere... (NOTICE)

    View Slide

  20. Development Guidelines
    Documentation
    README, LICENSE, CHANGELOG, ROADMAP, NOTICE, CONTRIBUTING
    Example code
    Communication
    There should be a mailing list, twitter account or a discussion forum
    Frequent Releases and Versioning
    Releases should be frequent and follow semantic versioning guidelines (http://semver.org)
    Deployment
    Releases should be easily consumable (e.g., available on maven central or rubygems)

    View Slide

  21. Philosophy and Culture
    “Default to open, think about what
    to keep closed that defines your
    secret sauce...”

    View Slide

  22. Open Source Philosophy

    View Slide

  23. Why?
    7 reasons we do it

    View Slide

  24. Community Feedback
    More usage translates into more bug reports and
    feature improvements. This translates into more
    stable code and helps prevent costly issues
    appearing in production.

    View Slide

  25. Attract Talent
    Smart engineers like to hang out with other smart
    engineers. Quality code will attract other smart
    engineers to move your company missions
    forward.

    View Slide

  26. Better Hiring
    What better way to find candidates than the ones
    who contribute to your open source projects?
    Consider this the best technical interview you
    can give a potential candidate. Plus it’s fun to
    look at their code in advance to review!

    View Slide

  27. Retain Talent
    Great engineers like working in the open and
    showing off their work. Sure, this may make
    them attractive to other companies but these are
    the people you want anyway, trust me!

    View Slide

  28. Reduce Duplication
    When you open source code, there’s a chance that
    someone on the inside or outside will let you
    know it’s been done in some way already.
    Embrace the new knowledge.

    View Slide

  29. Modularization
    When open sourcing internal code (especially if it
    was part of a larger code base), you tend to break
    it apart into smaller reusable and more
    maintainable pieces.

    View Slide

  30. The Right Thing To Do
    These days, it’s very difficult to build anything
    without benefiting from open source code in some
    fashion. Find ways to pay it forward as a “rising
    tide lifts all boats” in the industry.

    View Slide

  31. War Stories
    Some stories and lessons learned
    from the open source office

    View Slide

  32. Story 1: Bootstrap
    The legacy of GPLv2
    License: APLv2
    github.com/twitter/bootstrap

    View Slide

  33. View Slide

  34. Lesson Learned?
    Liberal license helped spur adoption
    Drupal, Wordpess, Jooma: GPLv2 legacy
    We made a mistake not choosing MIT
    Now we’re migrating to MIT... it’s a PITA

    View Slide

  35. Lesson Learned?
    Be diligent about potential
    communities who may adopt your
    code even if using liberal open
    source licenses.

    View Slide

  36. Story 2: Twemcache
    The fun of forking...
    License: BSD
    github.com/twitter/twemcache

    View Slide

  37. Lesson Learned?
    Avoid forking if possible. If not,
    reach out to existing communities
    before moving forward and making
    an announcement.

    View Slide

  38. Story 3: Clutch.IO
    M&A and open sourcing...
    License: APLv2
    github.com/clutchio

    View Slide

  39. Lesson Learned?
    Open sourcing code from an
    acquisition could be a win,
    especially if you’re going to shut
    it down or do nothing with it.

    View Slide

  40. Best Practices
    What works for us...

    View Slide

  41. Define Secret Sauce
    Don’t open source anything that represents a core
    business value. Define your secret sauce so
    there’s a shared understanding that can guide
    company decisions. Embed this secret sauce
    within your culture and company.

    View Slide

  42. Compliance in Eng
    When’s the last time you heard engineers have fun
    working with lawyers? Treat open compliance as
    an engineering problem and have it live in the
    engineering organization with a well trained
    staff. Educate everyone. Balance risk and speed.

    View Slide

  43. Facilitate Contributions
    Make it easy for engineers to contribute to
    outside projects with minimal bureaucracy.
    Setup simple guidelines and only be involved if legal
    issues come up (e.g., CLA)

    View Slide

  44. Transparency
    Make decisions around open sourcing code as
    transparent and accessible as possible.
    Awareness is great, you can also catch
    mistakes and duplication.

    View Slide

  45. Compliance Scanning
    Use custom or lightweight tools to scan for
    compliance on an ongoing basis. Share your
    compliance reports across the engineering
    organization so lessons can be learned. Better
    yet, integrate into your CI system.

    View Slide

  46. Blessed Repositories
    Have central repositories (e.g., Maven or
    RubyGems) for approved open source
    libraries. On top of making life better for engineers,
    this makes it easier to scan for compliance.

    View Slide

  47. Collaborate
    Join organizations such as FOSSology, Open
    Invention Network (OIN) or SPDX. Work together
    with companies and the community to tackle
    the problem of compliance.

    View Slide

  48. Measure Everything
    Establish metrics and measure yourself
    against them. Otherwise, how can you know
    what’s going on and how can you improve?

    View Slide

  49. Conclusion
    Twitter — Open Source
    Open compliance is important. Establish a
    efficient open compliance process that balances
    speed, risk and efficiency. Use or build tools to
    help make it easy and transparent.

    View Slide

  50. Q & A
    Thank you for listening!
    @cra
    [email protected]

    View Slide