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.
BTW, Japan holds TPS Record!

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

9.
2010+: Build a company!

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

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

12.
Twitter Runs on Open Source

13.
Engineers ran the asylum...

14.
Code dumping happens...

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

16.
Created Open Source Office in 2011

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

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

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

20.
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)

21.
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)

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

23.
Open Source Philosophy

24.
Why?
7 reasons we do it

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

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

27.
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!

28.
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!

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

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

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

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

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

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 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 a
service 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.
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.

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

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

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

49.
Q&A
Thank you for listening!
@cra
zx@twitter.com