Rise of the Open Source Program Office for LinuxCon 2016

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.

Transcript

1. 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 Offices
   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 find that companies,
   in order to remain compePPve, are gearing up with formal approaches toward open
   source.
   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
   Offices 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
   source projects.
   1
   

   View Slide

2. 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
   by many.
   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
   soWware!!
   2
   

   View Slide

3. 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 benefit from Open Source, the reality is
   that most companies fail to have an explicit strategy to get those benefits. Who in
   the company is responsible to ensure that they are parPcipaPng in Open Source in
   the most effecPve way?
   To be fair, some companies do have a strategy, and some do have a way to get to the
   benefits of Open Source.
   What do they do that others don’t? What do they know that we can learn?
   3
   

   View Slide

4. 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:
   4
   

   View Slide

5. 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.
   5
   

   View Slide

6. But none of the these benefits happen automaPcally.
   The Open Source ecosystem is a complex dynamic system of many players with
   compePng interests.
   Without coordinaPon, these systems turn to chaos.
   6
   

   View Slide

7. For this reason, many tech companies are now formalizing a funcPon in their
   company called the Open Source Program Office.
   Moreover, many of the Open Source Program Offices 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?”
   7
   

   View Slide

8. When we say that a company “does Open Source” or “is an Open Source friendly
   business” we mean one of many very different 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 benefit 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.
   8
   

   View Slide

9. To help us publish code and use code properly, tech companies create Open Source
   Program Offices. These are the center of thought for everything related to Open
   Source in the company.
   The program office is responsible for strategy, and must have a horizontal view
   across the technology groups at the company. For this reason, some open source
   program offices report into a CTO or Chief Architect posiPon.
   The program office 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 office is also responsible for ge\ng things done. They must have at
   least a small staff, or the ability to work with others in the company, to execute and
   report on their work.
   9
   

   View Slide

10. It may help to share some details. The Open Source Program Office sets the strategy
    for Open Source. This encompasses many different 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 benefit of the code you
    already have. We have to find a balance, and that balance comes from having a
    healthy conversaPon about our current assets and resources as a technology
    company.
    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
    they made.
    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.
    10
    

    View Slide

11. The central role for the Open Source Program Office 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 fix 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
    Github?”
    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
    difficult 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.
    11
    

    View Slide

12. Let me share a specific example about decisions you make when you use code in your
    products:
    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 find 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
    before.
    I think this is good for the state of technology, but it adds an extra step to the
    deployment process.
    12
    

    View Slide

13. 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 effecPve 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
    they are.
    13
    

    View Slide

14. To make things work, the Open Source Program Office 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.
    14
    

    View Slide

15. Most importantly, the Open Source Program Office 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.
    15
    

    View Slide

16. What this means to you: If you work at a tech company, you should have an Open
    Source Program Office. 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 effecPvely. If you run an open source project or foundaPon and
    seek to interact with corporate developers, use a company’s Open Source Program
    Office 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 Office – either in the formal sense as your official 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 Offices help companies coordinate the acPvity of
    thousands of developers. We, along with foundaPons, user groups, and affiliate
    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 effecPve 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.
    16
    

    View Slide

17. Thank you for taking the Pme to listen about the growing importance of the Open
    Source Program Office 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.
    17
    

    View Slide