How Adobe is Changing Its Culture Around Open Source

Our journey to open source

In late 2016, we started investigating what open source looked like across Adobe. First, we conducted an audit of all the open source resources and programs across the company, and we wanted to hear from Adobe developers in the process.

At the end of 2016, we founded the Adobe Open Source Office. It was initially a grassroots effort with three of us working on it part-time. The original members were essentially volunteers as we all still had “day jobs” and other responsibilities. The thing that brought us together was a shared love of open source and a desire to have Adobe give back to the community.

The open source office had one clear goal: to further open source at Adobe by helping teams open source projects and contribute back to community open source projects.

One huge benefit of how we started the open source office was the diverse representation we had from all areas of the company.

Now that we had a centralized presence, we opened up communication channels to learn from Adobe developers what were the obstacles preventing them from contributing back to open source.

So what did we hear? We divided feedback into two categories: one was more organizational so things like lack of tools, confusing processes, lack of resources; and the other was cultural, so things like lack of executive buy in and support, no recognition, no awareness.

We started by tackling the organizational problems

Overwhelmingly, we heard that the process for contributing to open source was confusing. The process was email-based, and emails were getting lost or buried in inboxes along the way. Each team that was part of the process ran their own siloed processes and it was up to the submitter to keep track of where things were. It was normal for the process to take months in total.

Because of this, employees avoided and ignored the process, and many gave up on contributing halfway through. Teams who still contributed started to avoid legal at all costs — they did everything they could to not initiate contact. The end result was pushing code into the public domain without approval, which, if you ask your legal friends, is a BIG risk.

Additionally, there was no guidance on how best to utilize GitHub. The easiest way forward for teams was to create and manage their own org, which led to 35 Adobe-related GitHub orgs. With no commitment to continued support, many of those 35 orgs were abandoned without any notice. Issues and pull requests were ignored, and there was no central authority to provide guidelines around archiving repos.

The first thing we did was revamp the open source submission process. We started by gathering all of the requirements from all of the various teams involved in the open source process. We then took those requirements and created a checklist for teams to follow.

We went back and forth on what tool to use to manage the process (survey, build our own, etc.), and settled on creating a repo on our internal GitHub. The checklist of submission requirements was saved as an issue template.

One big benefit of this new process meant that it was open and transparent; anyone could view previous submissions. We wanted to remove the mystery behind the approvals.

Over time and many discussions with various stakeholders, the checklist grew to 53 items. The process was still daunting and only slightly less confusing.

Our intent was for the checklist to be a first pass. It was quick to get set up and it allowed us to build relationships with the stakeholders and submitters. It gave us, at the open source office, time to learn the nuances of contributing to and open sourcing code.

After using that process for the first year, we took our findings and launched a radically simplified open source submission form (thanks to Steve Gill, Fil Maj, and Joni Rustulka). To do this, we:

1. Removed ambiguous questions and replaced them with more simple, direct questions
2. Made the language easier for developers to understand (i.e., not written by lawyers)
3. Created categories of open source projects to help simplify what submissions needed what approval (e.g., ones that would have to involve legal and ones that could just be a conflict of interest review from the open source office)

The rest of the process was largely familiar and stayed the same. 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 to simplify the existing process.

We also created an approvelist of previously approved projects, as well as a denylist of projects that were out of bounds. This meant that if one employee received approval for contributing to a project, all other Adobe employees could do so as well without needing to fill out forms or ask for permission. We integrated these lists right into our submission form to give instant approvals or denials. This significantly sped up our approval times.

The next step was a major cleanup of the Adobe GitHub org

We removed 100 inactive members on GitHub.com/Adobe, most of whom were employees that don’t work at Adobe anymore. We worked with the enterprise security team to automate onboarding and offboarding for the org moving forward, creating a mapping of Adobe IDs to GitHub usernames. We also created a list of all the Adobe-related orgs that exist on GitHub, so we could begin consolidating them into the main GitHub.com/Adobe org.

We also launched an Adobe-wide contributor license agreement (CLA), for both company contributions and individual contributions. (Previously, we only had a few project-specific CLAs.) We set it up with Adobe Sign, so everything could be done digitally in a single interface.

As things progressed, we realized we needed an easy, centralized place for internal open source questions, so we created an engineering handbook for Adobe employees. Any questions that tend to come up from newcomers, we make a note of them and try to include it in the handbook. This means the handbook organically grows and becomes more useful over time. Opensource.google.com/docs was a huge inspiration for this. It is the gold standard. Today, our handbook contains centralized release documentation (NPM, Docker, Maven Central, Chef); information about how we manage GitHub.com/Adobe, and how to get access; and an overview of our CLA.

The handbook started out with a focus on open source, but has been broadening into a multi-purpose engineering handbook. The goal now is to open source it and hand it out to new hires as part of onboarding.

Knowing that a lot of new hires (and newcomers to open source) might be intimidated or not know where to start, we created a starter repo with all the necessary files for open source projects including:

• a readme file describing the basics
• a contributing.md file to help newcomers get involved
• a code of conduct (based on the popular Contributor Covenant code of conduct)
• a license file (Apache 2 or MIT), which is mandatory
• and optional issue and pull request templates

Next step: the cultural problems

What were the cultural obstacles for open source? This one is and has been much harder to tackle. How do you shift culture at such a large company?

The main things we heard were that:

1. There was no community around open source

2. “Who said” and “Why open source” were questions that came up too often, indicating a lack of executive and manager buy-in, understanding and support. (For many, it wasn’t clear how open source ties back to business strategy.)

3. Patents are heavily rewarded and recognized internally, while open source contributions have been less visible.

To address this, we’ve decided to tackle three aspects: community, communication, and perception.

Community

About three years ago, we started hosting internal Open Source Summits to get all open source enthusiasts and those new or interested in open source under one roof. We’ve hosted four of these events, with our fifth coming up this week. We hold the Open Source Summits in various regions each year, starting with the U.S. and Europe, and expanding to India next year. These summits have become a great way to share talks, expertise, and updates and to get feedback and build a community around open source at Adobe. As part of the summits, we present open source awards for outstanding contributors. There are two main categories for the awards: one is for the top contributor, based on data we pull from GitHub; the other is for an outstanding open source contributor, based on peer nominations. This is the beginning of a more formal employee recognition program for open source, which we hope to launch this year.

Communication

It was really important for us to have ways to communicate with our internal open source community as well as to promote Adobe open source projects to external developer communities. This area of emphasis made a huge difference for us and is one that I’m particular passionate about. What good is all the work we do, the things we build, the projects we open source, if no one knows about it?

First, we created our internal developer newsletter. We added every developer and product manager in the company to the list and made it like no other corporate communication. It wasn’t focused just on open source, but all internal tech news. Each newsletter is limited to four or five highlights, to keep it really simple and useful. And we wanted developers to enjoy this mass communication, so we pick a theme every release, like cows or rainbows or springtime. We use a Git repo to take submissions for what to include, so the newsletter itself also functions like an open development project.

We also created #guild-opensource, a company-wide Slack channel for all open source enthusiasts to gather and discuss whatever is on their mind.

Perception

This one is both internal and external. How do we tell a better story around open source? Externally we decided to talk about everything we do in open source, constantly. Every issue submission for an open source contribution or new open source project in our issue tracker gets flagged for promotion before it is closed. We use the Adobe Tech Blog and Twitter for external promotion of open source work Adobe employees are doing.

Internally, changing perception boils down to executive buy-in. This might sound familiar to those in open source program offices. We have tried a myriad of things. Building open source into our overall developer strategy at Adobe became a huge influence, and we are gaining more executive buy-in. When we first started talking about open source more publicly within Adobe, we got fast “NOs.” It was too risky, too time-consuming, etc. So we got creative about the way we talked about it. For example, one area of focus for the company is engaging developers and getting more developers building on our products. Open source is a great channel to engage developers. With that, we found a way to tie open source to a pressing business need: If Adobe wants to become a platform company, what good is a platform without developers building on it? We see open source as a great channel to connect with one of our most important audiences at Adobe: developers. Participating in open source lends legitimacy and authenticity to Adobe’s perception amongst developers.

We also started finding mavens across the company — particularly executives who understood and were enthusiastic about open source. We now have several executives who blog about these efforts consistently, speak at our open source summits, and recognize employees in their org for open source contributions.

Conclusion

As with everything, open source at Adobe is a work in progress. We’ve seen some amazing progress over the last few years and we’re excited for what’s ahead. This post outlines some of the things we have found helpful in growing open source. We’d love to hear what other companies are doing to become more open, collaborative, and community-driven.