Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Your Open Source Program Office

1,003 views

Published on

My talk at the Linux Foundation Collab Summit 2016 (March 30, 2016). I suggest that mid to large size tech companies need an Open Source Program Office to manage their involvement with Open Source.

http://events.linuxfoundation.org/events/collaboration-summit/program/agenda

Published in: Leadership & Management

Your Open Source Program Office

  1. 1. By: Gil Yehuda *But were afraid to ask
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 16. Thanks! Now come over and say hi. gyehuda@yahoo-inc.com www.gilyehuda.com

×