Open Source Program Offices collaborate on open source, policy, governance, and github to help developers improve successful outcomes for open source strategy. We describe why OSPOs are emerging, how they work, and what this means to the open source industry. We highlight a Linux Foundation sponsored collaboration called the TODOGroup where program office directors are meeting to coordinate efforts and ideas.
The presentation was delivered at LinuxCon and ContainerCon in Tokyo, Japan in July 2016.
Thank You. My name is Gil Yehuda and I am responsible for Open Source at Yahoo.
In this morning’s keynote, Jim Zemlin said that if there was one thing to remember
about his talk, it was this. Does anyone remember what that was? Anyone!?
He said to remember the growing importance of the Open Source Program Oﬃces
within the Corporate sector of the Open Source movement. Not only are we seeing
the rise of the “Open Source professional” as a formal role, we ﬁnd that companies,
in order to remain compePPve, are gearing up with formal approaches toward open
So today I will speak about this important role in the overall Open Source Ecosystem.
It is the role of Corporate Open Source Projects, and the Open Source Program
Oﬃces that enable them to happen. This role has not drawn much aSenPon in the
past, but as Jim said, we are beginning to pay more aSenPon to it now, and we’ll
discuss how it impacts the Open Source industry.
In this presentaPon I’ll share why we see what we see, how these programs work,
and what you need to know about this to improve your company and your open
Let us declare that Open Source has won the baSle.
We might all agree on this, or at least we agree that we hear these claims being made
That: Open Source is beSer: for developers, for users, for companies, for everyone.
It is more secure and more desired. Companies who leverage open source can aSract
beSer talent and lower their soWware management costs.
Some might even say the world becomes a beSer place if we all used Open Source
But isn’t is strange:
Most code is not open source. Most code wriSen this year will not be published as
open source. The legal default for code is that it is closed.
Even when it comes to code published as Open Source, most of that code is simply
published somewhere as a forked project on Github. It’s not actually integrated into a
community-managed project. It probably can’t be found.
And although we agree that companies can beneﬁt from Open Source, the reality is
that most companies fail to have an explicit strategy to get those beneﬁts. Who in
the company is responsible to ensure that they are parPcipaPng in Open Source in
the most eﬀecPve way?
To be fair, some companies do have a strategy, and some do have a way to get to the
beneﬁts of Open Source.
What do they do that others don’t? What do they know that we can learn?
They know that success in Open Source is not a technology problem.
As engineers, we oWen look at problems and think of engineering soluPons. But many
of our problems are created by people, and solved by people.
When pu\ng technology aside for a moment, and looking at the cultural aspects of
Open Source, we realize the following truths:
Open Source is beSer because of its poten*al to be beSer.
But to realize that potenPal, we have to do something to make it happen.
Yes, Open Source can save money, improve code quality, make people happier and
more producPve, make companies more successful, and…
Yes, it can even make the world a beSer place.
But none of the these beneﬁts happen automaPcally.
The Open Source ecosystem is a complex dynamic system of many players with
Without coordinaPon, these systems turn to chaos.
For this reason, many tech companies are now formalizing a funcPon in their
company called the Open Source Program Oﬃce.
Moreover, many of the Open Source Program Oﬃces are now working together in
the TODO Group, thanks to the Linux FoundaPon.
We see more companies hire Open Source Program Directors, and more of them are
working together to improve the state of Corporate Open Source.
What do I mean by “Corporate Open Source?”
When we say that a company “does Open Source” or “is an Open Source friendly
business” we mean one of many very diﬀerent things. So to be precise, I’ll focus on
one type of parPcipant, and one set of acPviPes.
Corporate Open Source is the code published and used by developers who work in a
corporaPon. The code is “work for hire” and is part of the company’s intellectual
property. However, many companies realize value in publishing that code to be open.
This is not code that an individual publishes on her own. This is not code that
underlies a product being sold by an open source company. Rather, this is code that
companies publish for the beneﬁt of the Open Source industry, as well as themselves.
This is code that employees write to solve problems that have not yet been solved,
and we want to share those soluPons.
To help us publish code and use code properly, tech companies create Open Source
Program Oﬃces. These are the center of thought for everything related to Open
Source in the company.
The program oﬃce is responsible for strategy, and must have a horizontal view
across the technology groups at the company. For this reason, some open source
program oﬃces report into a CTO or Chief Architect posiPon.
The program oﬃce sets the policies for how the company uses Open Source, how it
publishes code, and how it parPcipates in Open Source communiPes. For this reason,
the program director is not simply a program manager or markePng person, but a
senior technical leader within the company.
The program oﬃce is also responsible for ge\ng things done. They must have at
least a small staﬀ, or the ability to work with others in the company, to execute and
report on their work.
It may help to share some details. The Open Source Program Oﬃce sets the strategy
for Open Source. This encompasses many diﬀerent aspects of your company strategy.
On the technology side of things, we consider the current technology standards
within the company as well as the market trends. Working with the CTO, we want to
leverage Open Source to help reduce debt and churn. You get debt when you spend
more Pme addressing the decisions of the past, and you get more churn when you
are constantly chasing new things but never ge\ng complete beneﬁt of the code you
already have. We have to ﬁnd a balance, and that balance comes from having a
healthy conversaPon about our current assets and resources as a technology
We are also responsible for those parts of the business strategy that intersect with
Open Source. For example: Patents. Your Open Source acPviPes have a direct
relaPonship with your patent assets – and your company’s patent strategy needs to
be coordinated with your Open Source strategy. Your partnerships with others will
involve quesPons about who owns the code that results from the projects. Your
acquisiPon of other companies means that you now own the Open Source decisions
You also know that companies want to use Open Source to aSract talent. This is a
nice goal, but requires coordinaPon with the people in your company who do the
hiring in order to make this actually happen.
The central role for the Open Source Program Oﬃce is addressing the many
situaPons your engineers deal with when using open source code.
We get asked: “Can we use this Open Source code in our project?” The answer is
probably “yes” - but are there are any licensing issues we need to be aware of?
We get asked: “Can I publish this ﬁx to a project?” again the answer is probably “yes”
- but does the project have a CLA? Is it being supported or abandoned?
We get asked: “Who owns this code?” or “why is our proprietary code published on
We get asked: “When we release a product, have we complied with the license
terms? Who is responsible to verify?
Engineers and project managers have a lot on their plate already. License compliance
can get rather complex, but with a simple set of processes in place, it’s not that
diﬃcult to get it right. This is very do-able. But much like many things in Open Source,
the potenPal is there. To make open source work at your company, someone needs
to coordinate things so that the potenPal becomes a reality.
Let me share a speciﬁc example about decisions you make when you use code in your
When using open source code in your mobile apps, you are obligated to give
aSribuPon to the code in your app. You must know what is in your app. You can’t cut
and paste code you ﬁnd on the Internet and put it in your products. Someone makes
sure that your open source credits are correct and on every app you publish.
For many web companies, this is new. We used to publish websites without worrying
about open source credits. But now the way we deliver soWware has changed so that
the distribuPon requirements on the licenses apply to things we did not consider
I think this is good for the state of technology, but it adds an extra step to the
Let me share the quesPons we ask when we publish open source code: We oWen ask,
“where should I publish the code in order to aSract the community, so that we can
be successful with the project?”
Yahoo published Hadoop and developed one of the most eﬀecPve communiPes
around Big Data in the Apache community. We publish many projects there, but not
all go there. Some projects have their own communiPes. Some expect that we run
the community, and some want to make sure that we don’t run it.
Ge\ng good at open source publicaPons is not only about pu\ng code on Github,
but also about becoming an excellent Open Source partner. Becoming a good partner
means that you learn to understand your community and work with them, wherever
To make things work, the Open Source Program Oﬃce has to help developers deal
with real code, not just policies.
This includes ge\ng people the proper access to code projects, and removing them
when it’s Pme for them to move on.
We deal with code that should not have been published – leaks, code theW, mistakes
and other situaPons where code was not supposed to be open.
We also help projects with a code scanning and code mirroring strategy so that they
have what they need to be successful in using updated open source, without risking a
situaPon where their builds fail if a project moves.
Most importantly, the Open Source Program Oﬃce is a service, not government
bureaucracy. Our job is to enable developers at our company to be successful with
open source. This means we have the lightest and least invasive processes.
We don’t block, we educate. We don’t publish outdated guidelines, but we work with
projects to make sure that each one is doing the best they can do.
At Yahoo, I have a two-step process for everything open source:
Step 1: ask me for help. Step 2: get help
It’s never more complicated. If it were, the engineers would avoid it.
What this means to you: If you work at a tech company, you should have an Open
Source Program Oﬃce. Maybe it’s only one person, but it’s the one person who has
the role to help everyone with open source. It’s the person who thinks beyond the
license, beyond risks, and sees the opportunity to make your company successful
using open source eﬀecPvely. If you run an open source project or foundaPon and
seek to interact with corporate developers, use a company’s Open Source Program
Oﬃce as an entry point to our developers. We are usually very well connected and
are looking to work with others in open source. If you are the person who is running
your Open Source Program Oﬃce – either in the formal sense as your oﬃcial role, or
in the informal sense, since it is what you do at work anyway, then visit the TODO
Group online at TODOGroup.org. We are a small community of people who do this
role and we share best pracPces with each other. We believe in open source and we
believe in being open with each other. What this means to the industry: Open Source
is at the point of maturity where we need more coordinaPon in order to manage our
growth. Open Source Program Oﬃces help companies coordinate the acPvity of
thousands of developers. We, along with foundaPons, user groups, and aﬃliate
communiPes, are one of the many points of coordinaPon that will help make a more
coherent open source future. The TODO group is one point of coordinaPon that we
are using to make sure we are as eﬀecPve as we can be. I thank the Linux FoundaPon
for their leadership and support of the TODO group. I see this as an important part of
building our open future together.
Thank you for taking the Pme to listen about the growing importance of the Open
Source Program Oﬃce at your company and the role of professional, corporate open
source in general.
My name is Gil Yehuda, you can read my answers about open source on Quora and
reach out to me online.
Thank you again.