The Evolution of Open Source at Dropbox

The open source program at Dropbox was initially just a mailing list, where some interested engineers wanted to open source projects and develop with open source. Over time, things became more formalized, with a focus on ensuring that the company was consistent about what code it would release versus what code was best kept internal.

They also wanted to ensure that the things they were releasing were things that would actually provide value.

“We set minimum standards for what we would release as open source projects, including a review process, and our program just started to drive a lot of value,” said Luke Faraone, Security Engineer at Dropbox.

What drives Dropbox’s open source program

It’s important to ensure that the metrics and goals you track are not just related to volume, such as measuring the number of open source projects that you’re releasing or the number of lines of code you’re releasing. Those sort of metrics don’t necessarily provide business value or community value.

“We make sure to be thoughtful with our program’s goals, focusing on things that either provide back some business through external contributions or otherwise indicate that others are getting value out of our projects,” said Faraone. “We want to make sure that the community is connected back to us. Also, it is good to make sure to have fun and not have a process that is too onerous. We want people to feel comfortable working with us, and we want to be partners with folks as they work on projects. Ensuring that we have good relationships is really important.”

How Dropbox measures community success with open source

One of the most important things when building an open source community is making sure that your own processes are open.

“The more transparent you can make your decision-making processes, the more of a sense of ownership your community will have. You also want to make sure that your process doesn’t become a blocker. If your open source process for either inbound or outbound contributions is onerous, people will look to bypass the process or simply decide that contributing is too difficult,” said Faraone.

How Dropbox tracks contribution and release metrics with open source

It is important to track metrics related to contributions to projects, including such questions as:

• What rate of contribution are you getting on a per-contributor basis?
• Do people tend to come back to contribute to particular projects or would they also be interested in contributing to other projects that we are involved with?
• How likely is a contributor who provides one patch to come back?

At Dropbox, according to Faraone, they also monitor the time between releases and the amount of churn that occurs between releases, where the goal is to encourage releases early and often. They also check in with teams if they have gone several months without committing to a new version.

Zulip stands out

Among Dropbox’s open source successes — if you look at the number of contributions — a project called Zulip stands out. Zulip was an open source chat system that the company acquired in 2014, but eventually they decided that they wanted to release it to the community.

“As an open source project, members of the community had set up hosting services for the chat system, and we eventually sunsetted our hosted service. We offered all of our users an opportunity to elect to have their data migrated to one of the community-operated hosting providers. What’s really impressive is that the Zulip open source project has a higher commitment velocity than it did when it had 10 or 15 employees working on it full time,” said Faraone.

Key lessons for open source program managers

Faraone offers the following tips to help ensure success when developing an open source program.

• Community involvement can often give a project higher commitment velocity than dedicating a lot of full time employees to the project.
• In driving community around projects, it is critical to make sure that your own processes and decisions are open and not too onerous.
• Track metrics related to community contributions closely, including whether contributors participate in more than one project, and whether releases are arriving early and often.
• When compared to tracking community ecosystem health and evaluating whether your program is creating business value, tracking metrics such as lines of code created has less value.
• Evaluate whether you are choosing highly restrictive licenses, and if you are, what impact that will have as you start receiving external contributions.

You can read more TODO group case studies on GitHub.