In 2015 Target quickly changed its policy, making it okay for developers to contribute to open source. This talk is a collection of all things that a team of self organized individuals did to make this happen bottoms up. The lessons we learned and the protips we share can be applied at other big companies to make the same kind of change happen. Dan will cover things like: * The low friction processes we put in place for contributing to existing open source and for open sourcing whole projects * Getting executive support * Getting all the peripheral stakeholders organized (public relations, legal, IP, etc) * Standing up a proper open source office * Incentivising developers * Seamlessly applying what you do with open source to your company's inner source efforts * Measuring your open source goals * And much more

1. How Target Made It Super Easy for
Developers to Contribute to Open Source
Dan Cundiff (pmotch), Target Corporation

2. The early days

3. A pivot using open source

4. If you use it, naturally you’ll
want to contribute as well

5. Pre-sell to as many
influencers and decision
makers as you can

6. Find an executive who will
back it

7. Draft a position on paper

8. Get legal, security,
communications involved

9. Make the barriers as low as
possible

10. Two choices:
1. Contributing to existing project
2. Open source a new project

11. Contributing to existing projects
• Things like bug fixes, features, etc
• Get a +1 from a coworker
• Make it good code (reputation is on the line)
• Don’t reveal company IP
• Ask contributor to use their @target.com email
• Larger contributions should have another person review the
work

12. Open sourcing whole projects
does require a process (but
it’s not too bad)

13. Open source a new project
• Everything from the other approach, plus…
• Reviewed by the Open Source Panel
• Purge git history
• Use appropriate license
• Be ready to own it going forward (community, issues, PRs,
etc)
• Have a backup
• Write and blog about it

14. Open Source Panel is a set of
volunteers + legal who get it
and are willing to execute the
process

15. Panel meets once a week and
“mobs” the backlog together

16. Use a GitHub repo issues list
to track new project intake

17. Project organization
• Use GitHub org (https://github.com/target)
• If it’s a big enough project, separate out into its own org
(https://github.com/k8guard)
• Use issues, releases, etc
• Good README, CHANGELOG, LICENSE,
CODE_OF_CONDUCT, CONTRIBUTING
• Use all the features of GitHub too (PR templates, etc)
• Stitch up CI

18. Simple wiki page for the
process

19. Getting a proper legal policy
doc in place

20. Repeat on the inside with
Inner Sourcing

21. Establishing an open source
office

22. Open Source Office
• Be a clearing house for updates (inner source and open
source)
• Groom projects
• Manage common tools/SaaS used across projects (Pypi,
DockerHub, TravisCI, etc)
• Court new projects
• Help establish partnerships
• Manage CCLAs (ones we sign and ones we have others
sign)
• Run the Open Source Panel mob
• Measure success
• License matters

23. Retiring projects the Etsy way

24. Challenges
• If you’re selling it now, be prepared that it will take time
• Keep the process simple as reasonable
• Volunteers running the panel needs dedicated time
• Finding volunteers that actually want to help execute the
process
• Vetting the author make sure they’re up for the required
maintenance
• Measuring things is hard

25. Summary
• Passionate individuals will sell the idea of using an
contributing to open source; join them or help their cause
• Get organized and establish a process and policy
• Start doing it, learn from each experience, and keep making
it better
• Enjoy the benefits and share results with others in the
community