From Theory to Practice: Leveraging the Virtuous Open Source Cycle for Long-Term Success

Learn how to apply the virtuous open source cycle model in practice. Learn to design contribution and return paths, measure value, reduce friction, and sustain open source investment successfully.

1. Introduction

This is the second article in a series about the virtuous open source cycle model. The first article explained the basic model, showing how companies can contribute to open source projects and capture value in return. There is a third article describing an iteration of the model together with practical advice on how to set it up and optimise it.

In that article, I described the two environments (open community and company’s internal environment), the two systems (the open source project and your product or service), and the two value paths (contribution and return). I also explained the main types of value flowing between these, like assets, effort, capital, influence, and reputation. This helps us understand the full value flow from both sides.

In this second article, we will focus on how to apply this model in practice, turning ideas into actions, such as designing contribution and return paths, defining and measuring value, maximizing learning and ROI, and making contributions sustainable.

Reading the first article first is highly recommended to fully understand the concepts used here.

2. About Value Types

Value types are what flow through the cycle, as we saw in the first article. They include assets (such as code), effort (measured in FTEs), capital (budgets), influence, and reputation. Over time, you may add developer satisfaction, brand impact, and knowledge transfer. It is best to start by clearly defining assets, effort, and capital for your case.

2.1. Influence and reputation

Influence starts with contributions to the technical parts of the project. Over time, it grows across the whole project if contributions continue.

Your open source project, like your product, includes two parts: the commons (shared areas benefiting everyone) and differentiation (unique features you build advantage on).

Contributors should understand the link between their contributions and the product’s commodity (shared code) and differentiation (unique features). Influence and reputation grow best when contributions benefit both parts. Mature projects usually invest a big part of their effort in the commons. Embrace this, and plan your contributions carefully.

Influence maximises when your team’s contributions put the project’s needs at the same level that their preferences, which should align with the employer’s goals. There is always a way to balance interests: the project, contributors, and the company. If interests clash, find the alignment.

Influence and Reputation will not vary frequently, at least early in the process. Define a reasonable cadence to report about them so progress become evident.

2.2. Defining, Tracking and reporting about Value

You must track and report your selected values. This is essential for your organization’s future open source strategy success. Being able to assess and justify investments is key for sustainability.

2.2.1. Adapt and reuse

Speed is not common in open source; remember:

If you want to go fast, go alone if you want to go far, collaborate

Adapt your reporting strategy accordingly. One thing I have done is to report about different values asynchronously, so I can report often.

Define how to measure the value types. Choose meaningful metrics for those directly involved and for others across the company. Less is more. Choose your metrics wisely.

Reuse existing organization tracking systems where possible by feeding them with open source data. Reports should be easy to consume to have a real impact across the organization. Leave the complex reports to those closer to the initiative.

2.2.2. Customizing Value Types

Feel free to modify and adapt value types to your case. Some organizations consider branding impact essential from the start. I tend to avoid this early on. I prefer focusing on tangible elements that are easier to track and justify, but the choice is yours. Just make sure you can measure what you choose.

2.3. Start Small, Think Big

Make the vale types definition simple at first. You can always add complexity later. I always suggest to start with small amounts of effort and assets, defining a “exploratory” phase as initial phase.

Invest capital in coaching in that exploratory phase. This approach reduces risks and accelerates learning.

3. Setting Up the Cycle

Many organizations start contributing to projects they already consume the software from. They assume the return path — how value flows back — is already set. Most times, it isn’t.

Often, most energy goes to contributions; the return path is neglected. Later, management sees costs but not benefits, threatening sustainability. It is one of the most common mistakes I have seen.

Set up the entire cycle first — both the contribution path and the return path. Ensure your organization is ready to capture value as soon as contributions begin, even before if you can.

First, pave the road, then drive the car.

3.1. Optimizing the Return Path

The return path doesn’t end when the code lands in your internal repository. Ideally, it ends when the software reaches your customers. Sometimes, the value continues even after that, as maintenance can be a significant part of the delivered value.

When the open source code coming from the target open source project lands in an internal repository, few people know about it. Sometimes not even the person who approved the budget knows. Even if they know, they might not understand the impact.

Impact varies for different people, organizational units, and even entire organizations. It is critical to define impact in advance because the entire cycle’s design, processes and actions depends on it. Code might be an asset but is impact what justifies the investment, so what will fuel future investments.

More code does not mean more impact.

Focus energy in creating processes across the return path that maximises throughput and stability and to increase the value return, reduce friction (bottlenecks, constrains) along the entire return path

• Adapt internal processes and tools so upstream code is easier to consume.
• If you cannot do that right away, build proxies or automation to simplify adoption, then work on long-term improvements.
• Make it easier for all teams — compliance, security, release, documentation — to benefit from your contributions.

Examples of activities I have gone through that optimise the return path and the perceived returned value:

• Improve change logs in the open source project so your release teams and technical product marketing colleagues can understand them better and integrate them faster into the product change logs.
• Contribute fixes and documentation upstream so trust among your colleagues on the upstream code coming from your target project increases compared to the code coming from projects you do not contribute to. They should perceive the difference.
• Create baselines where you continuously test upstream software, including backports, with your current code base, putting an eye on performance on your hardware
• Integrate upstream bug reporting into your systems
• Flag unmaintained, end-of-life code, vulnerabilities…
• Track main points of contact for the upstream code you consume

Your goal is to make contributing to a specific project better than not contributing, making sure that the impact is perceived internally. Be aware that the amount of code you consume is, in general, greater than the one you are able to contribute, so every action in the return path might generate a bigger impact.

Focusing on the return path is as important, if not more, as on the contributing path.

3.2. Setting up and optimising the contribution path

By the time you have design the return path, it is most likely that you have already detected areas of contribution that will help to increase the impact of the code you are already consuming (if that is the case).

For instance, you can help the license compliance and security teams by ensuring due diligence is done upstream for the code you are consuming from the target open source project. You can also assist the maintenance and support teams by backporting fixes. The documentation team can also benefit from understandable release notes and better structured code base.

By helping other teams, the assets coming from projects you contribute to will be more appreciated than those coming from projects you do not. Focus there first, instead of in creating new features of adding new capabilities only.

At the beginning, optimise your design and actions for learning and code consumption instead of for contribution efficiency or ownership within the open source project, which sadly is the norm. In other words, optimise the whole process (circle), not a specific path or asset.

3.2.1 The efficiency trap: the tragedy of the commons

One main challenge is justifying investment in project commons. These are areas that do not benefit your company directly. But they are essential for project operations and sustainability.

Some effort must go to educating contributors and decision makers about how relevant these contributions are and their relation with reputation. But if you need to play defense here, you are already in trouble.

The best strategy is maximizing ROI across the entire cycle and report about the big picture, including contributions to the commons as necessary to spinning the wheel. When done it right, questions will decrease. I have seen it.

In addition to the above, work on making commons contributions visible and recognized upstream. Also make them valuable internally for contributors, their teams, and departments. Think about project commons areas as:

• R&D environments for your department
• Early testing environments for internal teams
• Learning environments for juniors in your company.

Make contributing to the commons of the open source project work for you, as part of your product/service lifecycle for specific teams, instead of simple “effort sinks” for regular engineers.

I always tell the example of how simple and efficient technical documentation is solved in many open source projects compared to what I have seen in corporations. Involved your technical product marketing people upstream so they learn a different reality, while contributing.

If you cannot pull it off, consider outsourcing effort in the commons to companies or professionals with interest in the open source project or showing capabilities in the open.

3.2.2. The ownership trap

Companies often push for ownership when contributing upstream. They do not understand the responsibilities and costs that come with ownership. Also, trust is essential for ownership in open source, which takes time. Too often, companies promote employees to maintainer roles. Then they struggle to give that employee the capacity and internal decision power to play that role properly. In addition, these roles comes with a lot of responsibilities in the commons of the project, which companies see as a waste.

At the design phase, those involved need to ask themselves: What is better for our customers and products, being able to contribute and steer with our contributions several areas of the project, or owning a significantly smaller area of the project?

To own in open source means the highest level of influence you can get. This question needs a careful evaluation. Reverting a decision in this front can ruin all the gained reputation. I have witnessed it several times.

4. Get help

To start strong, engage a freelance coach or a consulting service company with roots in the target, or at least a solid experience in various community projects. Do this for the first few months.

This coach should:

• speed up onboarding,
• help avoid early mistakes,
• focus your efforts where they matter,
• and make sure your return path works, not just your contributions.

This early investment saves time, money, and risks which is welcome when companies struggle at providing the necessary time to make the entire circle work well.

5. Summary

This article has shown practical ways to use the virtuous open source cycle model. It described how to:

• Maximize influence and reputation.
• Build the contribution and return paths.
• Deal with friction and measure value.
• Detect and avoid some of the most common challenges.

I discussed the importance of defining and tracking impact, making your contributions count as well as some recommendations for a successful start.

Sustaining contributions depends on showing a clear return on investment (ROI). If ROI is unclear, contributions are often questioned — or stopped. I hope that by describing the model first , and providing clues out of my own experience on how to use it later, you can find better ways for your organization to grow their open source investment into a lasting, self-sustaining process.

Remember that there are other articles corresponding to this Open Source Value Flow Model series:

• Article one: The Virtuous Open Source Cycle: Model Description
• Article three: Part 3: Evolving the Model by adding a company-driven open source project
• Article four: Value Types: Reputation and Influence

Note: all the ideas and content are mine except the last two images, generated with ChatGPT and Perplexity. Different AI assistants has been used in the tow posts article series to polish the text and to correct grammar and syntax errors.