Rise of the Open Source Program Office for LinuxCon 2016
•
4 gostaram•1,998 visualizações
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.
Recomendados
Recomendados
Mais conteúdo relacionado
Mais procurados
Mais procurados (19)
Destaque
Destaque (9)
Semelhante a Rise of the Open Source Program Office for LinuxCon 2016
Semelhante a Rise of the Open Source Program Office for LinuxCon 2016 (20)
Último
Último (20)
Rise of the Open Source Program Office for LinuxCon 2016
- 1. The Rise of the Open Source Program Office Gil Yehuda Sr. Director of Open Source @ Yahoo Inc. July 2016
- 2. We declare Open Source has won “Open Source is more secure” “Developers prefer Open Source” “Open Source attracts better talent” “Open Source means lower tech debt”
- 3. Yet… Most code written is not Open Source Most Open Source code is not in a thriving community Many companies lack an explicit strategy to get Open Source benefits
- 4. This is not a technology problem http://www.memecenter.com/fun/91608/Hat-Fail
- 5. Open Source offers the potential... • To reduce tech debt • To improve interoperability • To reduce costs • To make software more secure • To attract better talent • To create de facto standards • To “make the world a better place”
- 6. Realizing potential in a dynamic system requires coordination. Otherwise, expect chaos. CC-BY https://flic.kr/p/eZNHGh
- 7. THE RISE OF THE OPEN SOURCE PROGRAM OFFICE CC-BY https://flic.kr/p/mP9y6R
- 8. Consider the many players in the Open Source Ecosystem • Individual Developers • Software Foundations • Open Source Businesses • Academia • Governments • Vendors • … • and Corporate Open Source Individuals Companies Foundations Institutions
- 9. The Center of Thought for everything Open Source at your company • Horizontal • Senior • Staffed Strategy Governance Operations
- 10. You have a strategy, it might be implicit. Make it explicit. Strategy Governance Operations Technology strategy Technology assets Industry trends Technical debt Technology standards Business strategy Patent strategy Partnerships Acquisitions Foundations Talent strategy
- 11. Develop a consistent approach for each of the many cases you face Strategy Governance Operations Inbound Using Open Source code in projects Open Source Tooling Review of Acquisitions Outbound publications Publishing code to existing open source projects (CLA Review) Publishing code to new open source projects Outbound services Product pre- release obligation review Employee’s “private” publications Unauthorized publications
- 12. Inbound considerations: Web companies are also mobile companies; Mobile apps are distributed code.
- 13. Outbound considerations • Publishing code is only the first step to getting a community. CC-BY https://flic.kr/p/9Uw44G
- 14. Make Open Source part of the standard development process. Strategy Governance Operations Code Management Tooling Code scanning Code mirroring Incident Management Internal Security 3rd party Github.com Access and removals Teams and repos Metrics portals
- 15. Program Offices are governance, yet nobody wants governance Open Source Project Office is a service Educate with each interaction License and code whitelists don’t work Simplify: Ask & Get Help
- 16. How this impacts you: • Does your company have an Open Source Program? Are you the contact? • Do you wish to interact with corporate developers? • Open Source Program Offices help companies coordinate the activity of thousands of developers. • Eventually, we may help coordinate the many overlapping open source projects too.
Notas do Editor
- 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 competitive, 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 attention in the past, but as Jim said, we are beginning to pay more attention to it now, and we’ll discuss how it impacts the Open Source industry. In this presentation 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.
- Let us declare that Open Source has won the battle. We might all agree on this, or at least we agree that we hear these claims being made by many. That: Open Source is better: for developers, for users, for companies, for everyone. It is more secure and more desired. Companies who leverage open source can attract better talent and lower their software management costs. Some might even say the world becomes a better place if we all used Open Source software!!
- But isn’t is strange: Most code is not open source. Most code written 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 participating in Open Source in the most effective 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?
- They know that success in Open Source is not a technology problem. As engineers, we often look at problems and think of engineering solutions. But many of our problems are created by people, and solved by people. When putting technology aside for a moment, and looking at the cultural aspects of Open Source, we realize the following truths:
- Open Source is better because of its potential to be better. But to realize that potential, we have to do something to make it happen. Yes, Open Source can save money, improve code quality, make people happier and more productive, make companies more successful, and… Yes, it can even make the world a better place.
- But none of the these benefits happen automatically. The Open Source ecosystem is a complex dynamic system of many players with competing interests. Without coordination, these systems turn to chaos.
- For this reason, many tech companies are now formalizing a function 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 Foundation. 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 different things. So to be precise, I’ll focus on one type of participant, and one set of activities. Corporate Open Source is the code published and used by developers who work in a corporation. 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 solutions.
- 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 position. The program office sets the policies for how the company uses Open Source, how it publishes code, and how it participates in Open Source communities. For this reason, the program director is not simply a program manager or marketing person, but a senior technical leader within the company. The program office is also responsible for getting 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.
- 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 time addressing the decisions of the past, and you get more churn when you are constantly chasing new things but never getting complete benefit of the code you already have. We have to find a balance, and that balance comes from having a healthy conversation 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 activities have a direct relationship 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 questions about who owns the code that results from the projects. Your acquisition 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 attract talent. This is a nice goal, but requires coordination 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 Office is addressing the many situations 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 potential is there. To make open source work at your company, someone needs to coordinate things so that the potential becomes a reality.
- 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 attribution 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 software has changed so that the distribution 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.
- Let me share the questions we ask when we publish open source code: We often ask, “where should I publish the code in order to attract the community, so that we can be successful with the project?” Yahoo published Hadoop and developed one of the most effective communities around Big Data in the Apache community. We publish many projects there, but not all go there. Some projects have their own communities. Some expect that we run the community, and some want to make sure that we don’t run it. Getting good at open source publications is not only about putting 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.
- To make things work, the Open Source Program Office has to help developers deal with real code, not just policies. This includes getting people the proper access to code projects, and removing them when it’s time for them to move on. We deal with code that should not have been published – leaks, code theft, mistakes and other situations 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 situation where their builds fail if a project moves.
- 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.
- 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 effectively. If you 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 developing a small community of people who do this role and we share best practices 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 coordination in order to manage our growth. Open Source Program Offices help companies coordinate the activity of thousands of developers. We, along with foundations, user groups, and affiliate communities, are one of the many points of coordination that will help make a more coherent open source future. The TODO group is one point of coordination that we are using to make sure we are as effective as we can be. I thank the Linux Foundation 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 time 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.