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
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."
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)
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.
33. Story 1: Bootstrap
The legacy of GPLv2
License: APLv2
github.com/twitter/bootstrap
34.
35. 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
36. Lesson Learned?
Be diligent about communities who
may adopt your code even if using
liberal open source licenses
37. Story 2: Twemcache
The fun of forking...
License: BSD
github.com/twitter/twemcache
38. Lesson Learned?
Avoid forking if possible. If not,
reach out to existing communities
before moving forward and making
an announcement.
42. 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.
43. 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.
44. 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)
45. Transparency
Make decisions around open sourcing code as
transparent and accessible as possible.
Awareness is great, you can also catch
mistakes and duplication.
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 individuals 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.