Gil Yehuda, Open Source Program Office, Oath

1. Open Source
Horror Stories
How to manage the open source process to get desired results
Gil Yehuda
November 2017

2. About me
● I run the open source program office at Oath: Inc.
● Oath is basically Yahoo! + Aol. and part of Verizon
● Long ago I worked at Fidelity Investments where I opposed
our move to create an open source program.
● I was mistaken and overruled by smarter people.
● I write about open source too.

3. Today’s Agenda
True stories
Simple lessons
A takeaway

4. Sample
vs.
Scale
● Imagine a bug that has a 1/billion chance
of causing a catastrophic failure.
● Imagine the bug is in your transaction
processing server.
● Failure occurs three times a day.

5. The
Takeaway
● Horror stories almost never happen. When you
manage a lot of open source, you are more likely
to face problems. Think about scale, not sample.
● Positive outcomes require coordinated efforts.
Believing doesn’t make open source work. You
need allies who see tangible benefit to help.
● Even luddite companies can overcome their
self-imposed obstacles. It takes work and
someone to lead that effort. Perhaps that's you.

6. Stories of pessimism and optimism
Engineers decide
Should you sign that CLA?
Trusting the Source
Me? Insecure?

7. When
engineers
don’t ask
● Mark took code from his last company and
put in our project. We found out during a
review when we going to publish the code in
an open source project.
● A company open sourced a project and we
noticed our code in it, and our former
employee's name too.
● Divya took code she wrote as an intern and
posted it on Github to show her work (for
future employers). Sadly she hardcoded
server names and passwords.

8. Engineers who don't trust the process
make their own rules.
Their rules are based on how they think code sharing should work.
They are often mistaken.

9. Create practices that
match your policies
Inconsistent practices erode trust and
drive engineers to disclose less.

10. Making engineers sign
terms they will them be
asked to violate?!

11. Trusting the
source to
do no evil
● Someone moved their code from github
and broke my build
● A dependency added to their project, it’s
now in my product
● We forked a project which got a DMCA
takedown

12. When things work well we
become less paranoid

13. github/them/foo github/us/foo
gitcorp/us/foo
A 3rd party issues a DMCA
takedown on /foo

14. Conduct a rational audit of
your build/mirror process
Consider DMCA of forks, code injection, and dependency bugs

15. CLAs that ask for
too much
Most CLAs are OK

16. No one reads the fine print

17. Should you agree to this?

18. Worth a healthy conversation about scope before you sign this one

19. Create a fast path to
CLA approval

20. Me
insecure?
● Without 2FA, you are one
p4ssw0rd away from a leak.
● Adding people to your org is easy.
When do you remove them?

21. Your open source program office
is also a Github ops group.
Automate!

22. The Real
Horror
Story
The tech-dependent company that
● does not have an open source program
● filled with engineers who don’t ask for help
● yet face the reality of bad actors, poorly
written legal documents,
● but make overly optimistic decisions.

23. How do Open Source Programs
add processes that enable speed?
By providing trusted guidance about publication rights,
effective code protection strategies, fast support for legal
questions, ensuring better long term technical outcomes.

24. Processes get
in the way

25. Help the
runners go the
distance

27. Thank you
Gil Yehuda
Work: gyehuda@oath.com
Home: gil@gilyehuda.com