This document discusses the need for companies to establish an Open Source Program Office (OSPO) to manage their open source governance processes. It outlines six key governance areas an OSPO must consider, including using open source in projects, publishing code to existing or new projects, and reviewing employee publications. The document also provides examples of common questions that arise regarding inbound and outbound open source activities and notes that an effective OSPO process involves cross-functional partners like legal and engineering. The overall message is that mid-to-large tech companies require an OSPO to successfully navigate open source governance, but each company can structure their OSPO differently depending on their needs.

1. By: Gil Yehuda
*But were afraid to ask

2. My Presentation Goals
Share corporate perspective on Open Source
Highlight non-tech aspects of governance
Invite you to consider how this works at your company

3. Why an open source program office?
Companies with OSPO’s are more successful at managing Open Source
Diverse developer skills requires consistency in corporate approach
Having no process will create chaos and risk
Corporate contributions to open source is essential
You will have open source goals that don’t get met magically
Questions come up all the time requiring someone to own the issue

4. 6 governance areas you must consider when
developing your Open Source Program Office
Inbound
Using Open
Source code
in projects
M&A deals
Outbound (publications)
Publishing code to existing open
source projects
Publishing code to new open
source projects
Outbound (per request for services)
Product pre-release
obligation review
Employee’s “private”
publications

5. Larger Open Source Program Office Context
Technology strategy
Assets
Trends
Business strategy
Patent strategy
Research
Partners
Talent strategy
Code Management Tooling
Scanning
Mirroring
Incident Management
3rd party
Github
Access
Management
Team
Management
Metrics portals
Inbound
Using Open
Source code in
projects
M&A deals
Outbound (publications)
Publishing code to existing open
source projects
Publishing code to new open source
projects
Outbound (per request for services)
Product pre-release
obligation review
Employee’s “private”
publications
Strategy
Governance
Operations

6. Inbound Questions: what I’m thinking, what I’m asking
License
issues
Technical
Suitability
Engineering
Standards
1. Where’s the code?
2. What’s the license?
3. To use in which project?
4. Does this code leave our servers (e.g. a
mobile app, JavaScript, desktop?)
5. Would we modify this code?
6. Any reason not to contribute to this project?
7. Does this replace technology we already
use?
8. Who else reviewed this?

7. Inbound code via an acquisition
Are we buying
their
mistakes?
What’s in their
code?
What can we
learn about
their
engineering?
Can we help
with a “special
issue”
situation?
We can’t see their code, but we can ask them to
list open source code and ask to run a code scan.
Note:
1. Self-disclosures are never accurate, but they
are a good start.
2. Mobile apps should have a credits UI.
3. Scan results reveal engineering sloppiness.
4. Some deals have special (legal) issues where
the scan process can help.

8. Inbound Process is more than open source
license checking
Involve other partners:
• Legal - license questions
• Engineering - code suitability
• Architects - tech standards
• Paranoids - what’s in the code
• BizDev - if we acquire code
Inbound
Process
Approval
Usage
instructions
Complicating
factors
Approval filters
Code /
License

9. Let’s focus on the Outbound cases…
Inbound
Using Open
Source code
in projects
M&A deals
Outbound (publications)
Publishing code to existing open
source projects
Publishing code to new open
source projects
Outbound (per request for services)
Product pre-release
obligation review
Employee’s “private”
publications

10. Outbound Questions: what I’m thinking, what I’m asking
Creating a
new Open
Source
project
• Should we?
• How to
best
position it
Publishing
to a
existing
project
• Why not?
• How to do
it well
1. Was all the code written by an employee?
2. Was it written for a work related project?
3. It is in production?
4. What license will your code use?
5. Did you prepare the code for publication?
• Does it have license and copyright text?
• Is there a full README?
• What’s the PR plan?
6. Why do you want to publish this?

11. Questions following initial Outbound Request
Small like a bug fix or
a big-deal project?
Any legal
concerns?
Would
anyone
get upset?
How do we do this
properly?
CLA Copyright
Are we ready to lead another
community or dump code?
Who’s the
community?
Do they
want this
new
project?
Do we have
a PR plan?
Is the code
inviting?
README,
installer?
Is this ours
to publish?
Is it cleaned
up for
publication?
Is this novel?
Did we file a
patent
disclosure?

12. Outbound Process
requires a lot more
context to discuss
Involves other partners:
• Legal – License, CLA, Patent questions
• Engineering – code reviewed and prepared
• PR – is this something we promote, and how?
Outbound
Process
Approval
Publication
instructions
Complicating
factors
Approval filters
Code
Desired
outcome

13. Product Pre-release
• Before publishing a distributed app you need to verify you’ve
attributed the code properly.
App Credits:
AFNetworking
Project code: https://github.com/AFNetworking…
Copyright (c) 2011, Gowalla (http://gowalla.com)
License (MIT) https://github.com/AFNetworking...
… • In rare situations you discover the need to
publish code you did not expect to publish.
Launch Process
(OSS Step)
Attribution UI
Oops code
Complicating
factors
Code scan
Product
(e.g. Mobile app)

14. Employee Questions
• Pre-hires ask to work on open source.
• Engineers publish “their own” code.
• Engineers leaving want to take code.
• We discover our code somewhere.
Copyright
Assignment
Business
Priorities
Ethical
behaviors
When is my
code, my code?
IANALBUT
Here’s how
to do this
properly.

15. Summary and Takeaway
• Mid to large tech companies
need an OSPO to manage
governance processes.
• The //TODO Group companies
each run an OSPO, but we run
them differently. That’s OK.
• Ask me/us for help.
OSPO is a service
Educate
with each
interaction
License
and code
whitelists
don’t
work
Simplify:
Ask & Get
Help

16. Thanks!
Now come over and say hi.
gyehuda@yahoo-inc.com
www.gilyehuda.com