Red Hat is, by its very nature, a deviation from the norm in this series of profiles. It is not a company with an open source program, but rather an open source company with an open source and standards office and an engineering team dedicated to curating communities and tending upstream contributions. In essence, Red Hat is a living, breathing testament to the success of open source. However, it still benefited from some organization and goal-setting in its community efforts.

“The Open Source and Standards office, or what some would refer to as an open source program office, was established six years ago to create a consistent way to support communities which Red Hat is actively participating. We created a centralized organization of expertise and resource to support our goals by flanking the considerable upstream engineering efforts ,” explained Deborah Bryant, senior director, Open Source and Standards, in the office of the CTO at Red Hat.

However, there wasn’t any need to advocate open source or push for its adoption internally. Red Hat started from day one as an open source company rather than approaching open source later, so everyone on board was already firmly in the open source camp.

“Most open source program offices are chartered to encourage and enable engineers to contribute to open source, or to educate people on what open source is, or to assist in choosing an open source license. These are things that are a done deal at Red Hat,” says Bryant.

“Rather than just seeing how we can use open source to improve our business, or be more flexible in operational efficiencies, or bringing more money to the bottom line, we are at the level of maturity where open source is our actual business practice and model. And because we work first upstream (in the open source project) of our products first, community success is critical.”

Therefore, the focus is supporting open source projects and the ecosystem rather than on transitioning to open source.

“For us, open source is an important part of our business model, and our business goals are to make sure that those communities that we rely upon are healthy and thriving,” said Bryant.

In Red Hat’s open source toolbox

Having goals is one thing, achieving them is quite another. Several tools can be used to measure progress and results. Red Hat uses a range of tools to make sure to, and communications-based tools top the Red Hat list of must-haves.

“Collaboration tools are a very big deal for us, because we have a high degree of collaboration across engineering and product and business lines. I know I’m probably understating that, but collaboration across Red Hat is huge,” Bryant said.

The company also uses the kinds of open source project, program and community tools you would expect, as well as Kanban boards for organizing tasks.

“A lot of these are developed organically, independently through the communities that we support – they pick the tools that work for them. We use Kanban boards to track progress. We measure using metrics that are established community by community and also in terms of what Red Hat’s hoping to influence through contribution. We use both publicly published metrics and internal metrics for custom boards,” says Bryant.

The team also started using OKRs, or Objectives and Key Results. The framework is used to define and track business objectives and outcomes. Red Hat plans to use OKRs across projects to connect the business side of Red Hat with the work of product managers and engineering to better support long term objectives.

Bryant says that “probably the most essential communications tool we use is IRC.” The acronym stands for Internet Relay Chat and it’s a system used for real-time communications between people anywhere on the planet.

“Most of us are working virtually over five or six or different time zones. IRC is our virtual building, our team is there and collaborating on a conventional level,” she said. “We use a tool called Telegram to do logistics and coordination when we are traveling at big events.”

Measuring Success

At Red Hat, success is defined differently for each open source project.

“When you talk about measuring upstream contributions and such, we actually go through a formal process on an annual basis, and then we refresh it several times a year to define what the success criteria are with the folks here at Red Hat who have the biggest stake in the project,” says Bryant.

“But in other cases, such as Fedora, where we have a lot of Red Hat contributors, we’ve started to measure the number of upstream contributions from other organizations, and not just from our own. For us, healthy ecosystems are a key goal, so we measure our successes partly by measuring how many other contributors there are.”

Dave Neary, a senior principal software engineer working on SDN and NFV in the Open Source and Standards office, added another example in OpenDaylight.

“There is already an ecosystem of companies that contribute to OpenDaylight, and there is a developer team inside Red Hat. Our goal could be to increase the adoption of OpenDaylight as an SDN backend for OpenStack, for example. Or, it could be to increase the awareness of OpenDaylight as an end-to-end network management solution. That is a very different goal, with different stakeholders, and you would measure different things,” he said.

“The goals are going to be different from one project to another. One project may care much more about developing the user community, while another project may care much more about growing a vendor ecosystem.”


We would like to thank Dave Neary (senior principal software engineer working on SDN and NFV in the Open Source and Standards office and CTO’s office) and Deb Bryant (senior director, Open Source and Standards, in the office of the CTO at Red Hat) for contributing content to this article, along with Pam Baker who performed the interviews.

product manager

As a product manager, you should definitely look at how open source can impact on your customer’s experience.

As open source program offices emerge in organizations worldwide, the focus is often on developers and other technical leaders. This makes sense – the drive for an open source program office comes from developers who are already engaged in open source.

But, as explored in the recent open source guide on starting a new open source project in your organization, as you build credibility as an open source contributor, you may want to open source your own code. Although developers are used to engaging in open source, when you look to open source your code, others in the organization will need to engage as well.

A key participant in this process is the product manager – this person drives the direction of the product forward with input from the business, engineering staff, and user feedback. This complex job requires the product manager to manage strategy, roadmap, features, and delivery – many think of it as being the “CEO of the product.” The product manager must also be creative and collaborative to be successful, especially when looking at how to build out the product and the ecosystem surrounding it.

So, how can the product manager look at leveraging open source as part of their product strategy?

Filling in the gaps in product development

Product features tend to fall into one of two gaps – features that are key differentiators and that actively sell the product, and those that just need to be there but don’t actively sell the product (often referred to features that “check the boxes”). The latter is likely an area where open source can help.

For example, suppose you are building a task management application. The key pieces that differentiate the product would likely be ease of use, integration with key productivity applications, as well as the approach taken to managing/assigning tasks – those features are ones you’d ensure your team is best skilled at building. But what about the authentication? Or maybe iCal integration for publishing tasks on a calendar? Those are all great features, but you could leverage open source libraries or tools to add them easily without knowing the ins and outs of dealing with identity providers or the iCal spec.

Leveraging open source this way gives you both the ability to deliver product faster and to increase functionality and stability as those tools are further developed over time.

Enabling an ecosystem

Thinking about that task management application, the possibilities for how people would use it are probably endless. And on top of that, your users might have specific applications they would like to integrate into it. In a proprietary model, the product owner is the full gatekeeper of such things, but an open source model lets the product thrive and build an ecosystem of applications and integrations to increase customer value.

Ecosystem building is the holy grail for a product manager – it helps bring your application out of a silo and be relevant to more users. This gives the product manager two important assets:

  • Insight into how the product is used by the integrations being leveraged.
  • Freedom for your customer to evolve how they use the application without being blocked by product development.

Finding talented developers

As the product grows, so does the team to support it. How do you best identify the right person with the skills and interest in developing out that product? Start by looking at those in the community who are most active in working with the code.

Bringing in developers to work on the team in the ecosystem ensures they have the skills to be effective right away. But since they have chosen to spend time on the code already, you know they find value in the work and are much more likely to stay with the product for the long term.

Collaborating on hard problems

Some technical problems are just hard, and finding the right talent to work on them may not be feasible. Open source collaboration evens the playing field and helps bring in the best talent to solving those problems, sometimes with competitors in the market.

Managing these projects can be hard, but the projects in turn can produce amazing results. For examples of this in practice, check out projects such as the Apache Hadoop project, and Automotive Grade Linux – both of which have competitors collaborating together in a vendor-neutral forum.

Open source is a transformational technology that enables people and organizations to innovate faster, collaborate globally, and make a different in each of our lives. As a product manager, you should definitely look at how open source can be used to make a noticeable impact on your customer’s experience.

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.


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.

Enterprises using open source code in infrastructure must understand both the risks and benefits of community-developed software. Professional open source management is a discipline that focuses on minimizing risk and delivering the benefits of open source software as efficiently as possible.

For successful open source management, enterprises must adopt clear strategies, well-defined policies, and efficient processes. Nobody gets all this right the first time, so it’s also important to review and audit your policies for continuous improvement. Additionally, successful open source initiatives for enterprise IT must provide real ROI in acquisition, integration, and management.

To examine these concepts in detail, The Linux Foundation is hosting a free webinar called “Open Source Strategy for Enterprise IT” on Thursday, Jan. 26 at 10:00 a.m. Pacific time. In this webinar, presented by Bill Weinberg, Sr. Director and Analyst, Open Source Strategy, and Greg Olson, Sr. Director, Open Source Consulting Services, you will learn about:

  • The elements of enterprise-level open source strategy

  • Using OSS as a secret weapon for innovation and differentiation

  • Current and new use cases for OSS

  • Attracting and retaining talent with OSS use and contribution

  • OSS security and compliance in the enterprise context

In a previous webinar (called “When Open Source Becomes Mission Critical”), Weinberg and Olson covered other topics related to managing open source software and talked specifically about the risks of under-management. Such risks include legal factors involving non-compliance of licenses, operational risks involving the ability of the software to meet enterprise needs over time, and security-related risks involving vulnerabilities that companies must stay on top of.

Weinberg said the moral here is that managing open source software shouldn’t be an afterthought; it should be part and parcel of using and integrating open source software.

Learn more in the free webinar “Open Source Strategy for Enterprise IT, on Thursday, January 26, at 10:00 AM Pacific time. Register Now>>