The ROI of open source

In the course of our work in the Open Source Program Office, we get to have discussions once in a while with Red Hat partners about the nature of open source and the best practices to start using open source for a project or two within the partner's organization. 

These conversations are a little hard to describe. On the one hand, there's the standard list of open source things to do beyond just tossing out a bunch of code onto an open source repository and declaring to the world "we are open!" If you've done this, you've fallen victim to one of the classic open source blunders, never just throw your code over the wall.

These processes include creating a community infrastructure that provides a clear path for users and contributors to be a part of the project. That means things like websites and communications channels that progress the concept of onboarding: what is the project, how do users use it, and how do you get it? 

It means talking about community governance, which boils down to who makes a decision when there is a choice to be made? And there is the inevitable discussion about licensing, that some believe should dictate the rules of using a project and therefore place commercial controls on the use of the project's output. In reality, licensing has more emphasis on the rules of the road about distributing the project.

This part of the conversation is relatively straightforward, typically. Most partners have been around the block a time or two and get the basic concepts of open source. Occasionally, there are more emphasized parts of the discussion, depending on what the participants believe they want to get solved. "What about a foundation?" "Should we set up a technical advisory board?" That sort of thing.

What about ROI?

But there's the meta part of the conversation that sometimes gets a bit... disconnected. Invariably, things go a little sideways when someone asks "so how do you determine your return on investment (ROI)?"

To be fair, I get this question more often than not because somewhere in the meeting introductions it comes up that I am involved in determining community health via objective metrics. So, someone hears “metrics” and thinks I know what the cost-benefit analysis numbers are. Except here’s the thing… ROI isn't the deciding factor in whether Red Hat joins an upstream project or builds its products from open source projects it collaborates on and/or sponsors. Red Hat is focusing on the technological fit and health of projects, not whether it can improve its ROI through external contributions. 

When I share this bit of news, I will admit to a little secret pleasure in hearing synapses misfiring on the other end of the conversation, because it shows me that here is a great new opportunity to educate someone on how Red Hat works. The reason Red Hat does not focus on ROI in open source communities is because we’re going to participate in the open source community anyway. 

For a lot of organizations, there is still a choice on how a software project will be built. In-house and proprietary, inner source, shared source, or open source… a whole gamut of choices that will have analyses applied to ensure that the chosen process is indeed the best way to accomplish the task. And, let’s face it, 20 years into the 21st Century, there’s still a bias for proprietary processes, so ROIs are going to show up on any process that deviates from that. When something deviates from the perceived “norm,” there is more worry about whether that process is correct, so it gets more scrutiny.

At Red Hat, open source procedures are the norm, full stop. This means an ROI becomes a much smaller priority because we’re not looking at open source as an alternative method, an experiment being run to test the waters. At Red Hat, open source is the only way we’re going to go.

Does this mean that we’re completely unconcerned with the costs of building a community? Hardly. We’re not giving out diamond-encrusted swag at community events nor flying around community members in private jets to speak at conferences. Like any business, we’re watching our costs, and working to ensure that community and business goals are aligned.

Syncing business and community goals is a key part of ensuring success with open source projects in a business context. In our own Open Source Program Office, we regularly conduct stakeholder reviews of the open source projects Red Hat stewards. These reviews determine the overall health of a given project, and also afford the project and the business units that work with the project a chance to outline their respective goals and come to a common consensus on what the project’s goals will be moving forward.

During the stakeholder review process, it should be emphasized, this is not an opportunity for Red Hat to dictate what its goals are and have the project march in lockstep. More typically, the goals of the project are gathered from all major participants, regardless of their organization, and are aligned within the project first, with Red Hat’s teams adjusting their goals to those of the projects’. This is especially true of projects with a broad organizational diversity. 

In this way, and by individual contributors acting as good community citizens, Red Hat gains the most benefit from participating in open source. Communities are stronger and we are stronger about the projects with which we participate. That, in a very real sense, is our return on investment. Not numbers, but the value of what everyone gains in the open source process.