changing open source culture @adobe

Changing
Open Source
Culture @Adobe

Adobe & Open Source === ???

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

What are the 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

Adobe's Open Source Office

Grow Open Source at Adobe

Starter Repo

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

Revamped OS Submission Process

Steve:
- To manage the process, we created a git repo on our internal github. We put the checklist of all of the requirements into a issue_template.
- Every submitter was required to 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. 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. (Hand it off to Fil to talk about that)

Fil: 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 categorizes of open source projects that the open source office would be able to approve without going through all of the stakeholders.
- 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 anynone already involved, just a nice UI on top of existing process.
- Shout out to Joni to helping us make the experience much better.

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

Fil: 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 cotains 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

Open Development Template

https://github.com/adobe/open-development-template

Fil: The intent is to answer the questions: “how can I create a project that is open to newcomers, easy to involve yourself in, and scales as it grows in size?” Main areas, with a focus on answering why and how to document:
- Mission: what are the goals of the project?
- Licensing: what is it, what kinds exist out there?
- Governance: how do we add people to the project? Who has permissions in the project? What are the social rituals in the project?
- Process: how does the project get work done?
Developed internally to help teams grow cross-organizational projects that involve people from all across the company. It is a grass-roots effort to subvert the typical corporate hierarchical organization form and its limitations.
- We are dogfooding this process within the office, in order to make it more open and inviting for anyone to jump in and help out. We've made a few things about the way we work explicit, such as:
- 2 week sprints - everything in the open - self-assigned issues - accountability around what's assigned each sprint meeting

Internal Open Source Summits

OS Awards

Top OS Contributor
Outstanding Open Source contributor
Employee Recognition Program

Communication and Promotion

Internal developer newsletter
#guild-opensource
Adobe Tech Blog
Adobe I/O Twitter

Steve: 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.
- First we created the internal developer newsletter. It wasn't focused on just open source, but all internal tech news. We added every developer at the company to the newsletter. We use a git repo to take submissions for what to include.
- 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.
- Tech Blog and twitter for external promotion of OS work Adobe employees are doing. New projects + community contributions.

Executive Buy In Needed

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

Fil: 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 approach from his blog post on this topic, and expanded on it a bit
- there are many flaws of this approach: we only count commits as contributions (whereas we want to count comments, PRs, reviews, etc.). the company-to-user associations are rough at best. but that's ok.

open source

+

business strategy

Thanks!

@stevesgill

@filmaj