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