A tale of two cities: Merging Yahoo and Aol’s open source programs
•Télécharger en tant que PPTX, PDF•
0 j'aime•223 vues
Every company needs to address how they manage open source. Verizon Media is the merger of Yahoo and AOL, and those two companies ran their open source programs quite differently. The result of bringing them together was surprisingly good, but the process to get there offers many insights into how you can structure your open source program office to address the biggest problems you may face. Ashley Wolf and Gil Yehuda explain how Verizon Media now addresses license compliance, community management, the publication process, and how to run a program office at scale. You’ll explore real-world examples of things that worked well and things that needed much repair—as well as details on how it was done—and get advice on how to apply these lessons to your businesses. Neglecting your open source program leads to problems. Ashley and Gil highlight some big ones, like when the wrong people have access to your code, license issues get you in hot water, and employees make well-meaning but incorrect decisions about code publications. Sometimes it takes a revolution to force you to step back and get a better hold on your open source program. But you don’t have to wait for a merger to force the changes. Better to set the processes right starting today; Ashley and Gil show you how. If you don’t have a formal open source program office, or if you have one that needs a boost with some new ideas about how to maximize your value to the company, join this talk.
Recommandé
Recommandé
Contenu connexe
Tendances
Tendances (20)
Similaire à A tale of two cities: Merging Yahoo and Aol’s open source programs
Similaire à A tale of two cities: Merging Yahoo and Aol’s open source programs (20)
Dernier
Dernier (20)
A tale of two cities: Merging Yahoo and Aol’s open source programs
- 1. A Tale of Two Cities: When Yahoo! + Aol. blended Open Source Programs July 22, 2019
- 2. 2 GilYehuda Senior Director Open Source & ExternalTechnology gyehuda@verizonmedia.com Twitter:@gyehuda AshleyWolf PrincipalTechnicalProgramManager Open Source & ExternalTechnology awolf@verizonmedia.com Twitter:@Meta_Ashley
- 3. 3 1. Stories 2. Details 3. Q&A Your company needs an Open Source Program No OSPO→ problems Yes OSPO → benefits Take-away message:
- 4. 4 It was the best of times Verizon acquired AOL. in 2016 Verizon acquired about 10% of Yahoo! in 2017 The unified business unit was called Oath: It is now called Verizon Media✓ The business combines media and consumer experiences with ad tech / B2B brands. Even cool companies have issues Tech press presents a distorted view of reality Culture is subjective and measurement is local Integrating two cultures gets political and ugly Stories arefun, but we’re here to inform / inspire about open source lessons. It was the worstof times...
- 5. 5 Whichis where the story gets complicated.This is not a story of two companies,but of 100 companiesand thousandsof people. Canmanybe brought togetherto make one? 5 E Pluribus Unum
- 6. How effective is your corporatetechnical governance? Whatis the role of engineeringw/r/tthe company? Whatdoes “Engineering Culture” mean? How do others perceive your engineeringculture? Is software created in anticipation of a need, or in response to a need?
- 7. 7 Photo Credit CC-BY-NC-ND-SA 2.0 www.flickr.com/photos/sharmilirakhit Why do bad things happenwith no central OSPO? ● Engineers have misconceptionsaboutlicenses and are afraidto ask for help. ● When engineers don’t trust the process,they invent their own rules; inviting more risk. ● It only takesa few peopleto create a lotof problems.
- 8. 8 In theory you might face these questions ● Who removespeoplefrom your GitHub org whenthey leavethe company? ● Should you use freeTravisCIby publishingyour proprietary code on GitHub? ● Are you one P4ssW0rd away frombeing hackedif you don’tturn on 2FAon the org? ● What if you buy a companyand distribute their codewithout M&A diligence? ● Would anyone actually publishcodethat is downrightembarrassingto your corporatebrand? ● Why is it bad to havecodeon GitHub with no ownerand no license?
- 9. 9 The people whocare about these problems are your allies. Holding an investmentin outdatedtech thatblock you from keeping current. Engineers tend to prefer working at companieswitha strongengineering culturethatsupportsopen source. TechDebtand Industry Misalignment Attractingand RetainingTalent Published projects withwrongor missing licenses. No open source terms in contacts.No license complianceon apps. Former employees withprivileged access to repos see your code. Employees publish whatthey wantanywhere. Legaland LicenseProblems Leaked Information
- 10. 10 Blending companies is hard, but... <Insertprofoundinsight:howto make it easyto blendcorporatecultures> Open Source Community Theory can help ○ Shared Fate: we face the same consequences ○ Shared Faith: we believe in the same mission ○ Efficiency: utility value > interaction costs
- 11. 11 We focused on shared objectives Control Tech Debt Open Source keeps us aligned with industry. Achieve Excellence By using opensource properly,we reduce abandonment and rework. Legal Compliance At least to avoid dealing with any legalproblems. Support Engineers Make it easy for engineersto interact with opensource and with any code for that matter. Help Hiring / Branding Leveraging opensource to attract talent and reclaim recognitionthat we’re a also a tech company. Be Good Citizens By givingback to the community, by sharing code and proveneffective practices. and shared values...
- 12. 12 The OSPO Team + Partners Gil Yehuda Sr.Dir Technology Washington, DC AshleyWolf OS Program Manager + YDN Product Owner LosAngeles, CA RosalieBartlett Sr.Community Manager Sunnyvale, CA Responsiblefor externalcommunity management Responsiblefor operationsandinternal engagements. Responsiblefor Yahoo DeveloperNetworkand the OpenSourceProgram at VerizonMedia. Legal Tech PR Developer tools Paranoids HR/ Talent Acquisition External Technology Partners YOUR FACE HERE We’re hiring!
- 13. 13 Whatdoes the OSPO do? Program Management Community development License inboundreview Newproject publication Reviewing publication steps completed prior to publication Reviewing the use of open source in our products and platforms Promoting projects via blogs, podcasts, and speaking events Supporting internal engineering groups with open source issues Contributions toprojects Issuesupport and resolution Compliance Management Unauthorized coderemoval Bug Bounty alerting us of unauthorized code published Responsible for mobile and TV app compliance engineering and automation Ensuring issues are addressed on our external repos Reviewing contribution policies and CLAs OpenSource partnerships Security Alerts GitHub alerting us about vulnerable dependencies Reset membership with foundations, partner companies
- 14. 14 At the initial,tacticallevel Program Management Community development License inboundreview Newproject publication Publish process: lightweight and graduated Take them as they come Create content & events, partner with PR Set up and communicate Contributions toprojects Issuesupport and resolution Compliance Management Unauthorized coderemoval Do a ton of cleanup and tracking Initial tools and run baseline Get visibility to the problem and triage Set up CLA review process with legal OpenSource partnerships Security Alerts Set up process and automate it Do the minimum
- 15. 16 So whathappened? ● We reviewed the combined assetsand found ○ projects that should not have been on GitHub ○ people with accessto those repos that should not been there. (No 2FA) ○ unlicensed, poorly licensed, lacking readmes, abandoned, and some contained embarrassing content. ● We createdan inventory of everything, got admin accessto everything ● Implemented policies, created spreadsheets and jira tickets. Lots of spreadsheetsand jiras. ● For each project, we have contact information, license, readmes, etc. ● Projects that werenot updated were archived. Aggressively. ● It took over a year to clean up the mess and we’re in a pretty good statenow.
- 19. 20 In fact, opensourceisthe technology leadershipwe can talk about externally.It iswhat peopleuse to developan impressionof ourtech savvy and leadership. Open Source News helps withtechbranding
- 20. 21 Unlike the original Tale of Two Cities, we end with no beheadings ● Blending companiesis not easy. ● Pointing out the mistakes helpsdemonstrate the need to fix things ASAP. ● It takes a team. ● OSPO valuemust be greater than interaction costs. ● Eventuallyshared fate leadsto shared faith and collaborationon outcomes.
- 21. 22 Takeaway messages: 1. Your company might need an Open SourceProgram. 2. Findthe executiveswho care about techdebt, legal, security, talent, and engineering culture. 3. Align ongoals and shared values, and you’ll be able to build an OSPO for a blendedcompany.
- 22. Thank You Find us on LinkedIn, follow us on Twitter. Slide content licensed under cc-by-nd. Kindly share with attribution. AshleyWolf PrincipalTechnicalProgramManager Open Source & ExternalTechnology awolf@verizonmedia.com @Meta_Ashley GilYehuda Senior Director Open Source & ExternalTechnology gyehuda@verizonmedia.com @gyehuda
Notes de l'éditeur
- If you only take one slide from this preso -- it’s this. Having an OSPO is good, not having one is bad. I’ll share some stories to support this assertion. So stay for the stories. I’ll also share the update where we are in this drama.
- It’s actually more than two. This is the United States motto--and it means out of many one. Even though the title of our presentation is a tale of two cities the story of Aol and Yahoo is actually more because each company was comprised of 50 startups eat and thousands of people. As we tried to merge the companies and integrate the culture the story gets complicated.
- We use the term as a proxy for something. Let me try to refine this into specifics -- like how we expect engineering to operate, do they drive things? Are they decision makers? What is the reality and what is the perception?
- Most engineers will do the right things. But it takes just a couple of people to get it wrong and you have big problems..
- Some of the questions that go unanswered: Who is responsible for removing employees from having access to GitHub repos after they leave? How do we know everyone has 2FA turned on? And is it OK to publish code with an owner of unlicensed?
- Now, if you want to start an OSPO you should start with the people that care most about these issues. There’s at least four people at your company that wish you had an open source program office. Even if they didn’t know it. CTO cares about reducing tech debt Legal cares about minimizing legal risk and having an OSPO as the front line of defense for license questions HR or even your CTO again because Open Source is the thing in tech you can share and talk about. CISO cares that people are not publishing things they shouldn’t.
- Blending two companies is hard -- but it’s even harder when one has an OSPO and one no longer does. The nature of governance becomes a political problem. We had two engineering cultures. There’s no magic here. It’s hard. Having great leaders help. But we’re not always so lucky. Having immediate successes help. But you can’t bank on it -- in fact it’s irrational to think this would be easy.
- So we focused on our mission -- it’s less about declaring that we should have an OSPO and more about getting agreement that we want these outcomes. Once we agree on the goal, then we can use what we have to get there.
- We do all things related to open source. run a fairly typical open source program office. Here’s a summary of the services we provide (pause).
- And operationally here’s how we run things: we have the open source program where we manage requests for contributions, publishing, and using third party code Community management Compliance program We also found we spend about a quarter of our time focused on security alerts on projects
- A little bit about our numbers. We engage with about 600 engineers which is 10% of our engineer base. Quarterly our volume of tickets is about 300. We have a bunch of projects that we provide various levels of support and promotion for and we manage about 200 mobile apps and tv apps in our compliance program.
- Let’s list the ones we think are really important and why
- Presence and engagement
- We even have a podcast
- And this creates good buzz since you can talk about open source in public. This helps with tech branding and hiring. Also good to show appreciation to those who make your projects great.
- End on a positive
- Takeaway Messages First and foremost, you probably need an open source program office. It’s not one size fits all…. Find the executives that care about tech debt, information security, engineering culture, and attracting talent And get alignment on values and goals you’ll be able to build a blended OSPO.
- THANK YOU