Tweet
Tweet

Slide 1

Slide 1 text

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

Slide 2

Slide 2 text

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

Slide 3

Slide 3 text

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

Slide 4

Slide 4 text

2006: A simple idea...

Slide 5

Slide 5 text

2008: Growing Pains

Slide 6

Slide 6 text

2009... Crazy Growth

Slide 7

Slide 7 text

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

Slide 8

Slide 8 text

2010+: Build a company!

Slide 9

Slide 9 text

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

Slide 10

Slide 10 text

Open Source at Twitter We run and depend on it

Slide 11

Slide 11 text

Twitter Runs on Open Source

Slide 12

Slide 12 text

Engineers ran the asylum...

Slide 13

Slide 13 text

Code dumping happens...

Slide 14

Slide 14 text

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."

Slide 15

Slide 15 text

Created Open Source Office in 2011

Slide 16

Slide 16 text

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

Slide 17

Slide 17 text

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

Slide 18

Slide 18 text

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

Slide 19

Slide 19 text

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)

Slide 20

Slide 20 text

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)

Slide 21

Slide 21 text

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

Slide 22

Slide 22 text

Open Source Philosophy

Slide 23

Slide 23 text

Why? 7 reasons we do it

Slide 24

Slide 24 text

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.

Slide 25

Slide 25 text

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.

Slide 26

Slide 26 text

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!

Slide 27

Slide 27 text

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!

Slide 28

Slide 28 text

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.

Slide 29

Slide 29 text

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.

Slide 30

Slide 30 text

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.

Slide 31

Slide 31 text

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

Slide 32

Slide 32 text

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

Slide 33

Slide 33 text

No content

Slide 34

Slide 34 text

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

Slide 35

Slide 35 text

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

Slide 36

Slide 36 text

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

Slide 37

Slide 37 text

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

Slide 38

Slide 38 text

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

Slide 39

Slide 39 text

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.

Slide 40

Slide 40 text

Best Practices What works for us...

Slide 41

Slide 41 text

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.

Slide 42

Slide 42 text

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.

Slide 43

Slide 43 text

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)

Slide 44

Slide 44 text

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

Slide 45

Slide 45 text

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.

Slide 46

Slide 46 text

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.

Slide 47

Slide 47 text

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.

Slide 48

Slide 48 text

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

Slide 49

Slide 49 text

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.

Slide 50

Slide 50 text

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