changing open source culture @adobe

Changing
Open Source
Culture @Adobe

Adobe & Open Source === ???

What does it mean to be "an open source company?"
— Tobie Langel (@tobie) June 6, 2018

Employees contribute to OS projects on company time
Company sponsors OS events
Company OS internal code & is responsible for OS project stewardship

Is @mozilla an "open source company?"
— Tobie Langel (@tobie) June 6, 2018

Is @Microsoft an "open source company?"
— Tobie Langel (@tobie) June 6, 2018

Is @Adobe an "open source company?"
— Tobie Langel (@tobie) June 6, 2018

Our journey to Open Source

Adobe Open Source Office

- We formed the OSO at the end of 2016.
- Linux leadership summit.
- It was a grass roots type effort, with us only working on it part time.
- The 3 original members were essentially volunteers as they had other responsibilities as part of their day jobs.
- The thing that brought us together was a shared love of open source and a desire to have Adobe give back to the community.
- OSO had one clear goal and that was to help grow OS at Adobe.
- Help teams open source projects and contribute back and to make OS a key pillar to Adobe's development culture

What did we hear?

Organizational vs. Cultural problems

Confusing process to contribute to OS

Email based process
Composed of Legal, Compliance, Patent, Branding
Took months to complete

Employees avoided or ignored the process

Gave up on existing OS submissions
Legal became the "boogyman"
Started pushing to GitHub without approval (Big Risk)

Wild West on GitHub

35 Adobe related GitHub Orgs
Repos abandoned, issues and PRs ignored

Revamped OS Submission Process

- We went back and forth on what tool to use to manage the process.
- We settled on creating a git repo on our internal github. We put the checklist of all of the requirements into a issue_template.
- Every submitter could then create an issue in our repo and start filling out the checklist in the issue template.
- One big benefit of this new process meant that it was open and transparent. Anyone could view previous submissions and see how they went. We wanted to remove the mystery behind the approvals.
- Over time and many discussions with various stakeholders, the list grew to 53 items. The process was still daunting and a little confusing.
- Our plan was for the checklist to be a first pass. It was quick to get up and it allowed us to build relationships with the stakeholders; to find out what the various stakeholders' goals were.
- It gave us at the open source office time to learn the nuances of contributing to and open sourcing code.
- So earlier this year, from our learnings, we launched the new open source submission form.

The new submission form is radically simpler.
- We decided to remove the ambiguous questions for more simple and direct ones - easier to understand for developers (i.e. not written by lawyers).
- We created categories of open source submissions that would require different levels of approval.
- Some that would only require the OSO approval, some that would require all stakeholders.
- If there was one needing conflict of interest review (that the OSO can do) they wouldn't need to fill out the entire 53 item checklist.
- It bolted on top of the existing process - Users logged in with their enterprise Git account, and issues were submitted to the existing issue tracker. No surprises for anyone already involved, just a nice UI on top of existing process.

New Approvelist and Denylist

Checklist Approval Close Rate (Feb-April 2018)

Form Approval Close Rate (May-July 2018)

... and we're just getting started

Clean up Adobe GitHub Org

Removed 100 inactive users
Automated onboarding and offboarding
Reduce number of Adobe Orgs in the wild

Adobe CLA

opensource.adobe.com/cla.html

Handbook

- Next, we wanted to create an open, centralized place for OS questions so we created a handbook.
- Essentially: any questions that tend to come up from newcomers, we make a note of it and see if the info can fit into the handbook. In this way it organically grows and becomes more useful over time.
- Opensource.google.com/docs is a huge inspiration for this. It is gold standard.
- Today, our handbook contains centralized releasing documentation(npm, docker, maven central, chef). Info about how we manage github.com/adobe and how to get access. Also contains info about our CLA.
- The handbook started out with a focus open source, but has been bleeding into a generic engineering handbook.
- Goal is to open source it and hand it out to new hires as part of onboarding

Starter Repo

https://github.com/adobe/starter-repo

What are the cultural problems?

No community around Open Source
No recognition (i.e. patents)
Lack of communication
No executive buy in

Community

Adobe Open Source Summits

Recognition

Top OS Contributor
Outstanding Open Source contributor
Employee Recognition Program

Communication

Internal developer newsletter
#guild-opensource

It was really important for us to have ways to communicate with our internal OS community as well as promote Adobe OS projects to external developer communites.
- This one made a huge difference for us and one I'm particularly passionate about What good is all the work we do, the things we build, the projects we OS if no one knows about it?
- First we created the internal developer newsletter. We added every developer and PM at the company to the list and made it like no other corporate communication. We keep it simple and useful
- We use a git repo to take submissions for what to include so it functions like an OS project
- We also created #guild-opensource. A company wide slack channel to for all of the os enthusiests to gather and discuss whatever is on their mind.

Perception

Internal developer newsletter
Adobe Tech Blog
Adobe I/O Twitter

Executive Buy In

Get creative

Change the narrative
Tie Open Source to a pressing business need
Create case studies
Enlist allies (HR)
Identify enthusiasts

- Like I said, our narrative was originally that OS saved development time, created better software, etc. and we still got fast no's - So we got creative and changed the narrative. We talked about OS as another channel to engage with developers.
- We talked about OS as a way to lend legitimacy and authenticity to our developer offerings
- We found teams who had benefited in some ways from Open Source and talked about those constantly
- We talked to HR about attracting and retaining talent through OS.
- And we found and leveraged enthusiasts from around the company. Employees, especially executives, who understood and were enthusiastic about OS. We now have several executives that blog consistently, speak at our conferences, recognize employees in their orgs and demo new programs for the OSO.

Top 25 company at GitHub

OSS-Contributors project

Scan GitHub every month to get company-to-user associations as reported by people's Company field on their GitHub profile
We cross-reference that with commit activity on GitHub
Original Idea from a blog post by Felipe Hoffa, Developer Advocate at Google

We have yet to open source this project, but it's an attempt at quantifying our ranking among other companies.
- every month we pound the github REST API and keep track of user to company associations in our own DB
- we cross reference this information with commit activity on GitHub
- we stole Felipe Hoffa's (dev advocate at Google) approach from his blog post on this topic, and expanded on it a bit
- In 2017, we were ranked 56th with 38 unique contributors across 55 repositories
- Only 38 contributors?! Original approach used GitHub user's git configuration email, but who puts their company email in their git config?
- Now we use the "company field" in GitHub profiles and use our internal communication channels to encourage employees to add Adobe to their company field
- Beginning of 2018 we sat at 34th with 115 unique contributors to projects w at least one star