Open ecosystems and the next wave of collaborative innovation

The relationship between organisations and open source has changed fundamentally over the past decade. What began as a pragmatic way to share code and reduce duplication has matured into something far more consequential: cross-industry ecosystems where competitors collaborate on shared infrastructure, co-develop standards, and collectively shape the direction of entire technology domains.

This shift matters because the challenges facing industries today — decarbonisation, data sovereignty, trustworthy artificial intelligence, software-defined vehicles — are too large and too interconnected for any single organisation to solve alone. The organisations that recognise this and participate actively in open ecosystems will have a structural advantage over those that attempt to build everything behind closed doors.

From shared code to shared ecosystems

The earliest wave of open source was primarily about code sharing. A developer at one company would publish a library, others would use it, and occasionally someone would contribute a bug fix. The relationship was transactional: take what you need, give back when convenient.

The second wave brought institutionalisation. Foundations like the Apache Software Foundation and the Linux Foundation provided governance structures, intellectual property frameworks, and neutral ground where competing companies could collaborate without antitrust concerns. This was a significant step, but the collaboration remained centred on individual projects — a web server here, an operating system kernel there.

What we are seeing now is a third wave, where the unit of collaboration is no longer a single project but an entire ecosystem. The Eclipse Foundation's Software Defined Vehicle working group doesn't maintain one piece of software; it coordinates dozens of projects, specifications, and reference implementations that together define how the automotive industry builds vehicle software. Similarly, LF Energy doesn't just host a few grid management tools — it is building the shared digital infrastructure that Europe's energy transition depends on.

The distinction matters. In a project, you contribute code. In an ecosystem, you contribute direction. And the organisations that understand this distinction are the ones shaping the industries they operate in, rather than merely reacting to changes imposed from outside.

The ecosystem maturity model

Not every open collaboration is an ecosystem, and understanding where a given initiative sits on the maturity curve helps organisations decide how and when to engage. We find it useful to think in terms of four stages, each building on the one before it.

Shared code is the starting point. Organisations publish and consume libraries, frameworks, and tools. The value is primarily cost avoidance — don't build what already exists. Governance is minimal, often just a licence and a maintainer. The vast majority of open source activity still happens at this level: a company publishes a utility library, others adopt it, and the relationship remains informal and transactional. There is nothing wrong with this — it works well for general-purpose tools where no deep coordination is needed.

Shared standards emerge when multiple organisations realise they need interoperability. This is where industry-specific bodies like COVESA (the Connected Vehicle Systems Alliance) operate. Their Vehicle Signal Specification defines a common data model for vehicle signals — speed, battery level, tyre pressure, ambient temperature — so that applications written for one manufacturer's platform can work with another's. Without this kind of shared vocabulary, every integration between systems becomes a bespoke translation effort. The value shifts from cost avoidance to market expansion — a shared standard makes the addressable market larger for everyone. It also lowers the barrier to entry for smaller players, which increases competition and innovation across the sector.

Shared governance appears when the stakes are high enough that participants need formal decision-making structures, intellectual property agreements, and commitment mechanisms. The Eclipse Foundation's working groups operate at this level, with membership agreements, steering committees, and specification processes that give participants a voice proportional to their investment. This level of formality may seem bureaucratic, but it solves a genuine problem: when companies commit engineering resources to a shared project, they need assurance that the project's direction won't shift unpredictably, that their contributions will be protected by clear intellectual property terms, and that no single participant can unilaterally capture the project for their own benefit.

Shared innovation is the frontier. This is where ecosystem participants jointly fund research, co-develop pre-competitive technology, and shape regulatory frameworks. The LFAI & Data Foundation's work on Trusted AI principles is an example — member organisations are not just sharing code but collectively defining what responsible AI development looks like, influencing standards bodies and regulators in the process. Another example is the Eclipse Foundation's OpenMobility working group, where automotive manufacturers, tier-one suppliers, and simulation vendors collaborate on open simulation standards for autonomous driving validation. The research and development costs for this kind of work are enormous, and the results are more credible when they emerge from a collaborative process rather than a single company's internal effort.

Most organisations engage primarily at the first two levels. The strategic advantage belongs to those that reach the third and fourth.

Cross-industry patterns

The ecosystem model is emerging independently across several industries, driven by similar structural pressures. Three sectors illustrate the pattern particularly clearly.

Automotive

The shift to software-defined vehicles has made the traditional supply chain model untenable. A modern vehicle runs hundreds of millions of lines of code across dozens of electronic control units, and no single manufacturer can develop all of it in-house. The Eclipse Software Defined Vehicle working group, COVESA, and the SOAFEE initiative (Scalable Open Architecture for Embedded Edge) are building the shared platforms that make this new reality manageable. BMW, Bosch, Mercedes-Benz, and dozens of others participate not out of altruism but because the alternative — every manufacturer independently building the same foundational infrastructure — is wastefully expensive and produces worse results.

The Eclipse SDV working group alone coordinates projects covering vehicle abstraction layers, over-the-air update frameworks, fleet management protocols, and in-vehicle application runtimes. What would have been proprietary middleware five years ago is becoming shared infrastructure, freeing manufacturers to differentiate on the features and experiences that actually matter to their customers.¹

Energy

LF Energy's projects address the operational challenges of a decarbonising grid. OpenSTEF provides short-term energy forecasting that grid operators need to integrate intermittent renewables — predicting how much solar and wind generation will be available in the next hours and days so that grid balancing can happen proactively rather than reactively. SEAPATH builds a virtualisation platform for substation automation, replacing proprietary hardware with open, interoperable software that can run on commodity servers.

These are not side projects; they are becoming core operational infrastructure for some of Europe's largest grid operators. The economics are compelling: the cost of building and maintaining proprietary alternatives is prohibitive for all but the largest utilities, and the regulatory pressure toward interoperability means that closed platforms are an increasingly poor long-term investment.²

Artificial intelligence

The LFAI & Data Foundation hosts projects spanning the entire machine learning lifecycle — from data preparation to model training to deployment. But its most consequential work may be in governance. The Trusted AI initiative establishes principles and tooling for building AI systems that are fair, explainable, robust, and privacy-preserving.

As regulation tightens globally — the EU AI Act, the emerging frameworks in the United States and Asia — organisations that have embedded these principles early will find compliance significantly less painful than those that treat it as an afterthought. The collaborative nature of the work also means that the resulting tools and frameworks have been stress-tested across diverse use cases, making them more robust than anything a single organisation could produce internally.³

Why open participation is a strategic advantage

The business case for ecosystem participation extends well beyond shared development costs. Four dimensions stand out.

Influence over direction is perhaps the most underappreciated benefit. Organisations that actively participate in ecosystem governance — serving on steering committees, contributing to specifications, chairing working groups — have meaningful input into the technical decisions that will shape their industry for years. This is not about vendor lock-in; it is about ensuring that shared infrastructure evolves in a direction compatible with your own architecture and strategy. The organisations that showed up early to COVESA's Vehicle Signal Specification process, for instance, ensured that the data model accommodated their vehicle architectures. Those that arrived later had to adapt to decisions already made.

Early access to emerging standards gives participants a head start on implementation. When a new specification is published, the organisations that helped write it already understand its design rationale, its edge cases, and its intended evolution. They can ship compliant products months before competitors who are reading the specification for the first time. In regulated industries where standards compliance is a market access requirement, this timing advantage translates directly into revenue.

Talent attraction and retention is increasingly tied to ecosystem participation. Engineers want to work on interesting problems with broad impact, and they want their work to be visible. Organisations known for their open source contributions have a measurable advantage in recruiting, particularly for senior technical roles where the candidate pool is small and competitive. A company's presence in a recognised ecosystem signals technical seriousness in a way that no amount of employer branding can replicate.

Sustainability through shared infrastructure reduces the total energy and effort an industry expends on foundational technology. When fifty companies each build their own telemetry pipeline, that is fifty times the compute, fifty times the maintenance burden, and fifty times the security attack surface. Shared infrastructure consolidates this into a single, well-maintained implementation that everyone benefits from. This is not just an efficiency argument — it is an environmental one. The energy cost of redundant software infrastructure across an industry is substantial, and shared platforms are one of the most practical paths to reducing it.

Building for collaboration from day one

Participating effectively in an ecosystem is not simply a matter of publishing code on a public repository. It requires deliberate organisational design across several dimensions.

Dedicated ecosystem roles are essential. Someone needs to be responsible for tracking the ecosystem's direction, representing the organisation in governance discussions, and connecting internal engineering teams with external collaboration opportunities. This is not a part-time addition to an existing role; it requires dedicated attention and organisational authority. The most effective ecosystem participants we have worked with treat this as a distinct function, often reporting directly to the CTO or VP of Engineering.

Contribution strategies should be explicit. Which projects does the organisation invest in? What kind of contributions — code, specifications, documentation, governance participation — align with strategic priorities? How does the organisation balance upstream contribution with downstream consumption? These questions deserve the same rigour as any other strategic investment decision. An organisation that consumes heavily from an ecosystem without contributing is extracting value it hasn't earned, and the ecosystem's other participants will notice.

Internal alignment between engineering, legal, and business leadership is critical. Ecosystem participation involves intellectual property decisions, competitive dynamics, and resource allocation that cut across traditional functional boundaries. Organisations where these functions operate in silos will struggle to participate effectively. Legal teams need to understand open source licensing well enough to move quickly on contribution approvals. Business leaders need to see ecosystem participation as a strategic investment, not a cost centre. Engineering teams need the autonomy and time allocation to engage meaningfully with external communities.

Measurement and feedback close the loop. Track what the organisation contributes, what it consumes, how its influence within the ecosystem evolves, and how ecosystem participation connects to business outcomes. Without measurement, ecosystem engagement risks becoming either underinvested (because its value is invisible) or overinvested (because enthusiasm outstrips strategic alignment). Good metrics include contribution volume and quality, governance positions held, specification influence, and — most importantly — the degree to which ecosystem participation has accelerated internal product development or opened new market opportunities.

The road ahead

The trend toward cross-industry open ecosystems is accelerating, driven by regulatory pressure (the EU's interoperability mandates, the Data Act, the AI Act), economic reality (the cost of duplicating foundational infrastructure), and the increasing complexity of the technology challenges industries face.

The European Commission's approach is particularly noteworthy. Through initiatives like the Data Act's interoperability requirements and the Cyber Resilience Act's provisions for open source stewardship, the regulatory environment is explicitly encouraging the kind of collaborative infrastructure development that ecosystems enable. Organisations that are already embedded in these ecosystems will find regulatory compliance a natural extension of their existing practices. Those that are not will face a steep and expensive learning curve.

Organisations that view open source purely as a source of free components are missing the larger shift. The competitive advantage is moving from what you build alone to what you can build together — and from what you own to what you shape.

The question for technology leaders is not whether to participate in open ecosystems, but how deeply and how strategically. The organisations that answer this question well will be the ones defining the next generation of industrial infrastructure. The rest will be consuming it on someone else's terms.

Footnotes

1. The Eclipse SDV working group's project landscape provides a comprehensive overview of the projects and specifications under active development, spanning vehicle abstraction, connectivity, and fleet management. ↩

2. LF Energy publishes an annual landscape overview of its project portfolio. The foundation's membership includes major European grid operators including RTE (France), Alliander (Netherlands), and TenneT (Germany/Netherlands). ↩

3. The LFAI & Data Foundation's Trusted AI Committee maintains a set of principles and an evolving toolkit for building AI systems that meet emerging regulatory expectations. Their work has informed several provisions of the EU AI Act's requirements for high-risk AI systems. ↩