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.

8ccf2bfccb6b570c4fae81e50dd80ed8?s=128

Chris Aniszczyk

November 15, 2012
Tweet

Transcript

  1. Open Source Compliance at Twitter Philosophy, Governance and Best Practices

    Chris Aniszczyk (@cra) Open Compliance Summit Asia 2012
  2. Agenda Introduction and Brief History Open Source at Twitter Philosophy

    and Culture War Stories and Lessons Learned Best Practices Conclusion Q&A
  3. What is Twitter? “Instantly connect people everywhere to what is

    most meaningful to them...”
  4. 2006: A simple idea...

  5. 2008: Growing Pains

  6. 2009... Crazy Growth

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

  8. 2010+: Build a company!

  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
  10. Open Source at Twitter We run and depend on it

  11. Twitter Runs on Open Source

  12. Engineers ran the asylum...

  13. Code dumping happens...

  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."
  15. Created Open Source Office in 2011

  16. Open Source Review Process Simple, Comfortable and Audit-able Tools built

    on “JIRA Workflows”
  17. Where? Default to GitHub Also see http://twitter.github.com

  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
  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)
  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)
  21. Philosophy and Culture “Default to open, think about what to

    keep closed that defines your secret sauce...”
  22. Open Source Philosophy

  23. Why? 7 reasons we do it

  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.
  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.
  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!
  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!
  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.
  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.
  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.
  31. War Stories Some stories and lessons learned from the open

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

  33. None
  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
  35. Lesson Learned? Be diligent about potential communities who may adopt

    your code even if using liberal open source licenses.
  36. Story 2: Twemcache The fun of forking... License: BSD github.com/twitter/twemcache

  37. Lesson Learned? Avoid forking if possible. If not, reach out

    to existing communities before moving forward and making an announcement.
  38. Story 3: Clutch.IO M&A and open sourcing... License: APLv2 github.com/clutchio

  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.
  40. Best Practices What works for us...

  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.
  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.
  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)
  44. Transparency Make decisions around open sourcing code as transparent and

    accessible as possible. Awareness is great, you can also catch mistakes and duplication.
  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.
  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.
  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.
  48. Measure Everything Establish metrics and measure yourself against them. Otherwise,

    how can you know what’s going on and how can you improve?
  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.
  50. Q & A Thank you for listening! @cra zx@twitter.com