Best practices and use cases to align open source initiatives with business goals

[anajsana]

• Recommendations for adopting open source in businesses (e.g Address clustering suppliers to assess their open source-first commitment).

• Share neutral collaboration examples, such as LF Energy’s, OpenSTEF, etc where open source adoption led to business success

[SDKAAA]

I see from the size of the issue is that it is Large; therefore how large should it go?
Do we want to be more academic and do some interviews with identified usecases' suppliers? maybe a survey? thoughts?
Then there is the question on how to structure this? do we start by enumerating, then grouping and meanwhile trying to summarize the most important parts of the successes of the usecases?

for the sake of not forgetting a few usecases from the top of my head:

• I find the Red Hat 'upstream first' approach worth mentioning (post from 2016 but still valid where they spent at the time almost $2 billion to acquire open and closed source technologies and make sure they're freely available to the community)
• 12 Successful Big Companies Using Odoo ERP from 2022 but shows the success of both Open Source business and Businesses using open source and open source businesses.
• Passbolt is a usecase of true success in open source business (single platform to manage the entire passwords lifecycle)

also, something worth checking, at FOSDEM, there is going to be a talk about "Build a Great Business on Open Source without Selling Your Soul" by Robert Hodges and here's what he's proposing:

A profitable business is one of the best protections for commercial open source projects and communities that depend on them. Our talk draws on the experience of companies that pulled it off to explain how to do it for your own projects. We’ll discuss commercial models that actually work, giving back to the community, and gracefully collecting money for free software. We'll also discuss topics for larger projects like foundations and taking VC funding. It is possible to balance a strong belief in open source communities with making payroll every two weeks. We've done it and will share our secrets.

[mkurzman]

We used the chance for an unconference session in the ChaossCon EU 2025 before the FOSDEM to discuss the planned additional chapter "Transparent, Manageable Risks in Open Source vs. Closed Source" around metrics to go more in detail.

We didn't really discussed focussed on the chapter at the end and collected a lot of interesting material. The Unconference notes are shared in the slack-channel: https://chaoss-workspace.slack.com/archives/C02EMK6RAKT/p1739368080273219?thread_ts=1738235472.883629&cid=C02EMK6RAKT
But I can also share them here.

[mkurzman]

These are notes from an unconference discussion at the ChaossCon EU 2025 in Brussels at 2025-01-30
Thanks to all participants for their time and inputs.

Collection of examples

Arguments for Closed Source

• Time to Market TTM
  • Hint: If it is not purely self-developed software, there might be Open Source dependencies
• Differentiating IP
  • Hint: Identification of the relevant technologies that need protection is necessary

Engineering driven

A) OSS as alternative to proprietary solutions
e.g. Linux Zephyr

• ready to use, maintained and community driven
• potential benefit: consolidation effect: instead of the need to maintain several (proprietary/closed source) solutions, only one solution needs to be maintained
• idea: make a simplified example total cost of ownership (TCoO) calculation (e.g. based on maintenance costs)

B) Industry wide mapping of SBOMs

• if all players in one industry would map there SBOMs, an overlap may be expected
• the mapped overlap as "identified commons" would mark the "critical infrastructure"
• Health monitoring of the "critical" project may lead to need to support
• Alternatives to handle projects with health issues:
  • provide money (under the premise that there are maintainers available)
  • provide resources
  • Force: downstream fork (worst case: internal) e.g. if TTM is needed)

Business driven

A) Goldrush and Shovels
e.g. AI chip = shovel; AI = goldrush. Invest in Open Source may grow the adoption and thus lead to higher sales numbers

B) Disruption by Open Source
e.g. smaller competitors unite against the monopolist in the market
Two perspertives:

• from monopolist side: risk: try to get engaged in the community to slow down the progress
• from non-monopolist side: chance: try to get engaged in the community to accelerate the progress

C) Open Source as marketing instrument
e.g. providing free plans/free tools w/o vendor lock.in, then use business models for up-selling e.g. Premium Services

D) Standardization by Open Source code
e.g. Zephyr => may indirectly lead to case B)
other players in the market can either refactor their existing internal solutions to fit the public API or replace/adopt the Open Source solution.

E) Ecosystem play
e.g. create momentum to collect momentum - e.g. Realtime Linux (took 8 years to bring it upstream, needed >5 mio $ to work on it, now implemented via sub-system

F) Fast Follower
e.g. observing the market and follow on one of the above mentionned models

Additional hints

1. competition watching in companies should include the Open Source solutions
   e.g. like in the Gartner reports, or in plugfests
2. Generation switches may lead to outdaing legacy systems
   e.g. television broadcast with SD is shut down as it becomes too cost intensive and is replaced by HD => this may happen to Open Source technologies, too

Discussion of the picture "engineering driven vs business driven"

original see https://github.com/todogroup/ospology/tree/main/whitepapers/business-value
scribble see attached picture

Finding 1: If the business analysts would consider Open Source solutions in their reports, the business driven Open Source activities might be pushed, the business analysts use also metrics. Business people take their decisions on those metrics.
Finding 2: The business analysts would need input from the engineering side to match the correct solutions in their reports => this would heavily overlap with the CHAOSS metrics
Finding 3: the engineering side and the business side seems to be two different bubbles that have no link
Hypothesis: The two bubbles would need to be linked to solve the problem of missing Open Source business awarness; it could be investigated if CHAOSS could have a look at more "business" specific metrics as well