Posts

open source program

Gil Yehuda, Senior Director of Open Source at Oath (which owns the Yahoo and AOL brands), describes the company’s open source goals.

For seven years and counting, Gil Yehuda, Senior Director of Open Source at Oath Inc. (which owns the Yahoo and AOL brands), has led the open source program at Yahoo. Now with an expanded scope, he is gearing up to grow his team and improve the program. The company’s formal open source program office serves as a hub to connect all open source activities across the company, he says, but it didn’t start out that way.

As with many other companies, the open source program started informally with a group of diligent engineers and a few legal people. But the ad hoc group soon realized it needed a more formal program if it was going to be able to scale to address more issues and achieve specific business goals. With a formal program in place, they are poised to achieve its goals.

The top five of Oath’s numerous open source goals, according to Yehuda, are:

  1. Keep aligned with the industry on open source technology standards by avoiding creating unique tech stacks that Oath alone would have to manage at its own expense.
  2. Make it easy for engineers to interact with open source as users and as contributors.
  3. Be viewed as an open source friendly company for partnerships and collaborations.
  4. Be known as a great place for engineers to work on open source projects.
  5. Give back to the Open Source community by sharing code and practices.

Measuring and monitoring success requires the right tools and attitudes. Yehuda says at Oath they actively solicit and listen to the needs of their many engineering teams, track all their work transparently in Jira, and spread the work across many teams who help with the process.

“We have custom tools we use to check code and manage projects, but we’re hoping to work more with our peers in the TODO Group on tooling we can share across many of our peer open source program offices,” he said.

Success comes from being open, at scale

Yahoo helped make Apache Hadoop the cornerstone of the big data revolution when it took the early code and created a team around it to help it scale to Internet-scale. They agreed to publish it all as open source. When the need for real-time processing came to the forefront, Yahoo created S4 and open sourced it too, but then discovered Storm was just published, too, and it looked more promising. The team ditched their own code and put their efforts into helping make Storm even better.  

“We applied to Apache Storm what we learned from Hadoop and S4,” Yehuda said. “Our goal was to make it great, even though it kind of competed with our own first stab.”

Storm is a success today, and the company runs it alongside Hadoop to power many of its products. They added machine learning and high-scale data serving capabilities by adding Vespa Engine, to their platforms, and then published that too. And they helped other machine learning projects scale better too, all by publishing open source.

“We’ve leveraged our expertise with Storm to help both Caffe and TensorFlow achieve better scalability. We don’t own these solutions exclusively. Rather we share our code and help others — all the while we get to leverage our expertise to build one of the industry’s most scalable platforms for our use,” he said. “This saves us money while making us a fantastic place to work on projects that impact hundreds of millions of people.”

The program office worked on strategy, legalities, and execution of these and similar projects. Leveraging open source licensing and processes effectively was a key element throughout. Now as Oath, this work continues and expands.

Yehuda cited three key lessons he learned managing an open source program:

  1. Be a service to the engineers, not a barrier.
  2. Accept that challenges will be never-ending.
  3. Run the program office like you run an open source project: Be transparent in the way decisions are made and be open to input and collaboration from everyone.

“There are so many edge cases that come up — partnerships, acquisitions, unclear contract terms — and we simply need to be open to learn, explore, and come up with an answer to every open source related question. But the most rewarding part of my job is when people tell me they joined our company because they knew about our open source friendly culture. You know, we’re always looking for open source talent, and I’m hiring into the program office.” added Yehuda.

dropbox

One of the most important things when building an open source community is making sure that your own processes are open, according to Dropbox’s Luke Faraone.

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.

Measure success

Measuring Your Open Source Program’s Success is a free guide to help any organization learn exactly how their open source program is driving business value.

Open source programs are proliferating within organizations of all types, and if yours is up and running, you may have arrived at the point where you want to measure the program’s success. Many open source program managers are required to demonstrate the ROI of their programs, but even if there is no such requirement, understanding the metrics that apply to your program can help optimize it. That is where the free Measuring Your Open Source Program’s Success guide comes in. It can help any organization measure program success and can help program managers articulate exactly how their programs are driving business value.

Once you know how to measure your program’s success, publicizing the results — including the good, the bad, and the ugly — increases your program’s transparency, accountability, and credibility in open source communities. To see this in action, check out example open source report cards from Facebook and Google.

Facebook’s open source program office periodically posts the month-over-month results from its open source projects internally and sends an executive report to management. “Reports are just a good way to raise awareness,” said Christine Abernathy, Open Source Developer Advocate at Facebook. “Even though Facebook places a high value on open source (as an organization), it’s still always a good thing to market yourself internally all the time and show your value.”

Existing tools can help you measure program success. You can begin by setting up the right tools for collecting data and make sure the data sources are clean and in a format that everyone can understand. Many organizations create a dashboard of metrics for their open source programs, to track all of the data in one place and provide project snapshots that can help assess progress at a glance. (See our guide on Tools for Managing Open Source Programs.)

Key metrics for measuring open source program success

There are countless ways to measure success and track progress for open source programs. Project health isn’t the only thing to track, but is important. “How do you actually get the smartest people in the world working at your company?” asks Chris Aniszczyk, Executive Director of the Open Container Initiative and COO of the Cloud Native Computing Foundation (and former head of open source programs at Twitter). “Well, you open source stuff and then you convince them to contribute to your projects.”

It helps to be able to quantify project health. GitHub’s guide on open source metrics gives a great overview of what project maintainers should pay attention to.  Some key project metrics to track are:

  • Number of contributors (and ratio of internal to external contributors)
  • Number of pull requests submitted, opened and accepted (and time remaining open)
  • Number of issues submitted (and length of time remaining open)
  • Number of commits per contributor (internal and external)
  • Number of external adopters
  • Number of projects created or contributed to (program wide)

Other metrics include popularity and awareness, influence, and program costs. As you delve into these metrics, you can concretely report everything from diversity of contributors to your projects to the number of followers you have across channels.

The Measuring Your Open Source Program’s Success guide can help you with all these initiatives and more, and it explores how to set program goals and measure whether or not they are being met. It is one of a new collection of free guides from The Linux Foundation and The TODO Group that are all extremely valuable for any organization running an open source program. The guides are available now to help you run an open source program office where open source is supported, shared, and leveraged. With such an office, organizations can establish and execute on their open source strategies efficiently, with clear terms.

You can read more in previous articles, on How to Create an Open Source Program and Tools for Managing Open Source Programs. We encourage you to check out all the guides and stay tuned for more coverage of them.

The Tools for Managing Open Source Programs guide provides an exhaustive collection of categorized tools that any open source program can benefit from.

Is your organization looking to build out an open source program? If so, you’re not alone, but not every organization has a holistic sense of the available tools that can help create a healthy program. A simple charter document and a few spreadsheets for tracking projects won’t cut it anymore in managing a truly robust open source program. That’s where the new Tools for Managing Open Source Programs guide comes in. It can help any organization launch and maintain a thriving open source program.

“If you have more than 100 code repositories or 100 people that you’re trying to manage, you really can’t have someone doing it manually with spreadsheets anymore,” notes Jeff McAffer, Director of the Open Source Programs Office at Microsoft, in the guide. “Obviously, people still do it that way. But it starts to become ad-hoc and laborious. That’s where tools come into play. They allow you to scale.”

While launching and maintaining an open source program does require dedicated, task-specific tools, it is a mistake to assume that your organization must necessarily build its own tools from the ground up.

“Regarding existing tools and systems, my hope is that we’re quickly getting to a point where a company’s open source program office should not need to create any tools or technologies on their own,” said McAffer. “They should be able to find and use existing open source tools which can be used to manage their open source programs.”

Categorized Tools

The Tools for Managing Open Source Programs guide provides an exhaustive collection of categorized tools that any open source program can benefit from. These include Source Code Scanning and License Compliance tools, Bug Tracking tools, Release Management tools, and more. Are you familiar with FOSSology? It’s a Linux Foundation project that functions as an open source license compliance software toolkit capable of running license, copyright and export control scans from the command line. Have you heard of Docker Hub? It’s a cloud-based registry service that allows users to link to code repositories and build and test their images. These and many, many more useful tools are linked to and explained in the free guide.

Do you know how to answer questions like these?

  • How are your project APIs documented?
  • Have you laid out a Contributor Licensing Agreement that everyone can use?
  • Have you picked the right license for your project?

Various tools can help you determine the right answers to these questions, and the Tools for Managing Open Source Programs guide is a great way to surface them.

Methodologies

It’s important to understand that using open source for business strategy requires its own methodologies and processes which are very different than those needed when using and releasing proprietary software. As the guide notes:

“Nobody said it was going to be simple to move your company into the world of open source. But plenty of other companies, including giants like Microsoft and Google have done this before you and have provided detailed road maps, code, suggestions, and more to make your own journey easier. The creation of an open source program office and the selection of a package of critical tools to get your efforts started are within your grasp. By collaborating on open source projects and inviting others to collaborate with you, your company can gain immeasurable benefits and drive its progress forward with energy and innovation.”

The Tools for Managing Open Source Programs guide is one of a new collection of guides from The Linux Foundation and The TODO Group that are all extremely valuable for any organization setting up an open source program. The guides are available now to help you run an open source program office where open source is supported, shared, and leveraged. With such an office, organizations can establish and execute on their open source strategies efficiently, with clear terms.

These guides were not produced in a vacuum. Far from it. The advice you will find in them grew organically out of many interviews with some of the world’s leading open source experts. We encourage you to check out the guides and stay tuned for our continuing coverage of them.

Also, don’t miss the first article in this series, on How to Create an Open Source Program, which explores everything from the role of the open source program office to how successful open source programs at companies like Google function.

At organizations of all types, launching and maintaining successful open source programs has become a business priority. A strong open source program office helps to ensure that open source is supported, nurtured, shared, explained, and leveraged. With such an office, organizations can establish and execute on their open source strategies in clear terms.

With all this in mind, The Linux Foundation and The TODO Group (Talk Openly Develop Openly) have published a free collection of detailed open source guides to aid companies developing open source programs. The guides are available to you now, and this is the first in a series of articles that can introduce you to the value of the guides.

How to Create an Open Source Program is the first of the guides, and it explores everything from the role of the open source program office to how successful open source programs at companies like Google function. The guide also includes insights and advice from open source experts, including John Mark Walker, Founder of the Open Source Entrepreneur Network, and Will Norris, Open Source Office Manager at Google.

“The open source program office is an essential part of any modern company with a reasonably ambitious plan to influence various sectors of software ecosystems,” notes Walker, in the guide. “If a company wants to increase its influence, clarify its open source messaging, maximize the clout of its projects, or increase the efficiency of its product development, a multifaceted approach to open source programs is essential.”

The How to Create an Open Source Program guide makes clear that there is not a one-size-fits-all approach to creating a successful program. In fact, Google’s Norris notes that stakeholders from individual business units play a key role in how open source projects advance at Google.

“We allow the various business units around the company to make the decision on whether it makes sense to open source a given project from a business perspective, because there’s a lot of different reasons why you might open source a project or a piece of code,” he notes. “We’re comfortable with allowing projects to take the approach that works for them given their goals. We play more of a role of facilitating and advising.”

The first guide lays out recommendations for how to include stakeholders ranging from Legal to Engineering in the maintenance of a program office. It also delves into the importance of setting clear program policies and observing compliance guidelines.

“Having a well-defined policy in place, that’s great, but it’s got to be a well-defined minimal policy,” said Jeff Mcaffer, director of the Open Source Programs Office at Microsoft, who was interviewed for the first guide. “Otherwise you get lawyers, security folks, business folks, all piling in their concerns and constraints. Soon you end up with a straitjacket full of policy that basically means that nobody can do anything.”

These free guides are extremely valuable for any organization setting up an open source program. Notably, the guides were not produced in a vacuum. Far from it. The advice you will find in them grew organically out of many interviews with some of the world’s leading open source experts. We strongly encourage you to check out the guides, and stay tuned to this space for more articles in this series.