Open source compliance at Twitter, presented at the Open Compliance Summit Asia 2012 hosted by the Linux Foundation.
Open Source Compliance at Twitter
Philosophy, Governance and Best Practices
Chris Aniszczyk (@cra)
Open Compliance Summit Asia 2012
Introduction and Brief History
Open Source at Twitter
Philosophy and Culture
War Stories and Lessons Learned
What is Twitter?
“Instantly connect people
everywhere to what is most
meaningful to them...”
2006: A simple idea...
2008: Growing Pains
2009... Crazy Growth
BTW, Japan holds TPS Record!
2010+: Build a company!
Now: Growth Continues...
140M+ Active Users
400M+ Tweets per Day
33+ Languages Supported
1300+ Employees Worldwide
50% Employees are Engineers
100+ Open Source Projects
Open Source at Twitter
We run and depend on it
Twitter Runs on Open Source
Engineers ran the asylum...
Code dumping happens...
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."
Created Open Source Ofﬁce in 2011
Open Source Review Process
Simple, Comfortable and Audit-able
Tools built on “JIRA Workﬂows”
Where? Default to GitHub
Also see http://twitter.github.com
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
Licensing Guidelines: Inbound
OSI Certiﬁed Licenses Only
List of Approved and Banned Licenses
Motto: Trust but Verify
Extra Scrutiny at Distribution Points
Less Scrutiny Elsewhere... (NOTICE)
README, LICENSE, CHANGELOG, ROADMAP, NOTICE, CONTRIBUTING
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)
Releases should be easily consumable (e.g., available on maven central or rubygems)
Philosophy and Culture
“Default to open, think about what
to keep closed that defines your
Open Source Philosophy
7 reasons we do it
More usage translates into more bug reports and
feature improvements. This translates into more
stable code and helps prevent costly issues
appearing in production.
Smart engineers like to hang out with other smart
engineers. Quality code will attract other smart
engineers to move your company missions
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!
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!
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.
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
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.
Some stories and lessons learned
from the open source office
Story 1: Bootstrap
The legacy of GPLv2
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
Be diligent about potential
communities who may adopt your
code even if using liberal open
Story 2: Twemcache
The fun of forking...
Avoid forking if possible. If not,
reach out to existing communities
before moving forward and making
Story 3: Clutch.IO
M&A and open sourcing...
Open sourcing code from an
acquisition could be a win,
especially if you’re going to shut
it down or do nothing with it.
What works for us...
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.
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.
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)
Make decisions around open sourcing code as
transparent and accessible as possible.
Awareness is great, you can also catch
mistakes and duplication.
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.
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.
Join organizations such as FOSSology, Open
Invention Network (OIN) or SPDX. Work together
with companies and the community to tackle
the problem of compliance.
Establish metrics and measure yourself
against them. Otherwise, how can you know
what’s going on and how can you improve?
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.
Q & A
Thank you for listening!