Meeting Summary: Scaling Zephyr — From Monorepo to Ecosystem

Topic: Scaling Zephyr's development model, repository structure, maintainership, and ecosystem to support continued growth.

Overall outcome: The meeting established broad agreement that Zephyr's current development and maintenance processes face scalability challenges. However, there was no consensus on moving board, SoC, and driver support into separate repositories. The discussion increasingly converged on maintainership, ownership, review processes, API stability, and testing infrastructure as problems that need attention regardless of repository structure.

1. Executive summary

Zephyr's current development model has been successful in growing the project over its first ten years, but participants questioned whether that model can accommodate the next decade of growth.

The central concern is that Zephyr is increasingly expected to accept and maintain nearly every board, SoC, driver, and vendor integration directly in its main repository. This creates growing pressure on maintainers, reviewers, CI infrastructure, and contributors making changes across the tree.

Two broad approaches emerged:

• Ecosystem-oriented model: Allow more hardware support and vendor-specific code to live in repositories outside the main Zephyr tree, while remaining part of the Zephyr project and potentially retaining central integration and testing.
• Development-process-oriented model: Keep the current repository organization largely intact while introducing more hierarchical ownership, delegated reviews, better PR classification, and improved merge processes.

Participants agreed that these approaches are not necessarily mutually exclusive.

A central unresolved question was how to delegate responsibility without compromising the integrated, consistent, cross-vendor development experience that makes Zephyr attractive to users.

2. Main discussion topics

A. Repository organization and ecosystem growth

The initial proposal questioned the expectation that every board, SoC, and driver must be upstreamed into the main Zephyr repository.

The proposed direction was to make it possible for hardware support to remain officially within the Zephyr project without necessarily being hosted in its main source tree.

Potential benefits discussed included reducing the amount of platform-specific code in the main tree, allowing vendors to manage their contributions more independently, avoiding unnecessary downloads, and limiting the central project's responsibility for hardware it cannot realistically maintain.

Several participants strongly opposed splitting code into additional repositories, arguing that it would make development more difficult, particularly for changes affecting multiple components.

Key disagreement: Whether the benefits of isolation and distributed ownership outweigh the added synchronization and integration overhead.

The proposal was explicitly presented as an option to explore, not a plan to immediately remove existing platform support.

B. Monorepo versus multiple repositories

A substantial portion of the meeting compared a monorepo-based development workflow with Zephyr's existing use of West modules.

Consideration	Single repository	Multiple repositories
Cross-component changes	Easier to coordinate and potentially make atomically	Requires coordinated changes across repositories
Development velocity	Favors contributors working across subsystems	Favors independent development within modules
Downstream customization	May require maintaining changes against a larger tree	Allows individual modules to be forked or replaced
Downloads	More source code may be required	Users can select required modules
Ownership	Can use hierarchical maintainership	Can assign repository-level responsibility
Compatibility	Easier to coordinate integrated changes	Requires version and dependency coordination

An example was presented involving a C library type change affecting multiple modules. The necessary updates had reportedly taken approximately six months to coordinate and had not all been merged.

This illustrated how independent repositories and maintainership boundaries can slow cross-component changes.

Other participants emphasized that Zephyr is fundamentally different from Linux because users commonly build applications directly against the RTOS source and expect to support different boards and vendors from a common workspace.

No agreement was reached on the preferred repository structure.

C. Ownership, maintainership, and delegated responsibility

This became one of the strongest themes of the discussion.

The current approach implicitly makes the core Zephyr project responsible for the quality, compatibility, and continued maintenance of a rapidly increasing amount of hardware-specific code.

Participants argued that this cannot scale indefinitely.

A recurring question was whether the project should continue accepting responsibility for every supported platform or whether vendors should assume greater responsibility for their own integrations.

There was support for giving vendors and qualified maintainers more autonomy, provided they respect Zephyr interfaces and architectural requirements.

However, participants raised concerns that excessive delegation could weaken review quality or result in vendor integrations that are no longer compatible with current Zephyr releases.

Important principle identified: Scaling requires clearer ownership boundaries and greater trust in maintainers, accompanied by appropriate accountability.

D. Hierarchical maintainership as an alternative

One alternative to splitting repositories was a hierarchical development and integration model resembling aspects of Linux maintainership.

Under this approach, subsystem or vendor maintainers would review and integrate changes within their areas of responsibility. Changes would then be incorporated into the central repository through a more controlled integration process.

This could reduce the number of people involved in every individual change without requiring Zephyr to move its source code into additional repositories.

Participants acknowledged that similar approaches had been considered or attempted previously, with GitHub's workflow and existing processes presenting challenges.

The discussion nevertheless recognized that the present maintainership model was designed for a smaller project and needs to evolve.

E. API stability and compatibility

API compatibility emerged as a critical dependency of any more distributed ecosystem.

The concern was that moving drivers or platforms outside the main repository could make changes to Zephyr APIs more difficult to coordinate.

If the core changes an API, externally maintained components may not immediately adapt, potentially leaving some hardware support temporarily incompatible with current Zephyr.

Several points emerged:

• External HAL modules generally should not depend directly on Zephyr-specific APIs, although the discussion acknowledged exceptions and existing violations.
• Changes to shared interfaces, including C library interfaces, can still affect multiple repositories.
• More stable APIs would make external maintenance substantially easier.
• Experimental APIs create additional challenges because users expect them to change more frequently.
• A distributed model would need clear compatibility, deprecation, and versioning policies.

The key tension was between preserving the ability to evolve Zephyr's interfaces and maintaining continuous compatibility across all supported hardware.

F. Testing and CI scalability

Testing was identified as another major obstacle to scaling.

The current testing infrastructure contains a large amount of board-specific configuration, including platform filters, overlays, and test variants.

The discussion referenced approximately 9,000 overlay files and highlighted how adding a board frequently requires changes across samples, tests, and configuration files.

A particularly important limitation is that testing boards maintained outside the main Zephyr tree can be difficult because existing test filters and configurations may assume those boards are defined upstream.

This creates pressure to upstream board definitions simply to reuse Zephyr's test infrastructure.

Improvements discussed included more capable test selection, less reliance on board-specific overlays, better API and test design, and stronger automated testing.

The meeting also discussed making vendors responsible for providing hardware-testing evidence.

A proposal to improve the handling of test overlays and configurations was mentioned as work already underway.

Key implication: A distributed Zephyr ecosystem would require improvements to Twister and related tooling so that externally maintained platforms can use common tests without modifying the main tree.

G. Pull request and review scalability

The discussion eventually shifted toward the volume and complexity of incoming pull requests.

Participants described several recurring issues:

• Board additions frequently modify drivers, test configurations, samples, and other unrelated areas.
• Such changes generate review requests for many maintainers, contributing to notification fatigue and unclear ownership.
• Large PRs may receive insufficient attention because no single reviewer feels responsible for the entire change.
• Current approval and review procedures can delay changes even when the relevant maintainers have already reviewed them.
• PRs occasionally include changes outside their stated scope, intentionally or otherwise.

There was support for improving PR classification and routing, requiring more clearly scoped contributions, reducing unnecessary reviewer notifications, and reconsidering how different kinds of changes receive approval.

The possibility of rejecting or requiring contributors to split unnecessarily broad PRs was discussed, with the important exception that genuinely atomic cross-tree changes may need different treatment.

Participants recognized that this problem could be improved independently of any repository restructuring.

H. HALs and vendor integration

The meeting also discussed the lack of consistency in how vendors provide HALs and integrate them into Zephyr.

Issues included HALs becoming large ecosystems of their own, vendor-specific compatibility layers, external binary dependencies, and differences in maintenance practices.

Questions were raised about whether Zephyr should carry compatibility code for external software designed around other RTOS environments.

While participants discussed reducing reliance on vendor HALs through more generic drivers, there was skepticism that HALs could be eliminated or that vendors could realistically be required to share a single generic driver implementation.

The general direction was toward better-defined integration boundaries, clearer guidelines, and stronger separation between vendor code and Zephyr-specific functionality.

3. Agreements and unresolved questions

Areas of broad agreement

• Zephyr's current scaling challenges are real and increasingly affect productivity.
• The existing model was valuable in Zephyr's early development but needs to evolve.
• Review and maintainership processes are significant scalability bottlenecks.
• Hardware vendors need clearer ownership and greater autonomy.
• API stability and compatibility are essential to supporting a broader ecosystem.
• CI and testing infrastructure must become more scalable and reusable.
• Users must retain a practical, consistent development experience across different hardware vendors.
• Existing tools, particularly West and Twister, would need improvements to support a more distributed approach.

Questions left unresolved

Question	Status
Should boards, SoCs, and drivers move into separate Zephyr repositories?	No consensus
What should remain in the core Zephyr repository?	Not defined
Should externally maintained platforms receive the same CI guarantees as in-tree platforms?	Unresolved
Who must update external components when Zephyr APIs change?	Responsibility debated
How should releases guarantee compatibility across repositories?	Requires design
Should Zephyr introduce hierarchical integration trees?	Alternative proposed; no decision
How should maintainers' approval and merge authority evolve?	Further work required
What qualifies a platform or driver for inclusion in the main tree?	Criteria not established

4. Proposed follow-up work

The transcript does not record formally assigned action items, but the discussion identified several concrete areas for investigation.

Priority	Follow-up	Objective
High	Revisit maintainership and PR review processes	Reduce bottlenecks and unnecessary reviewer involvement
High	Improve test configuration and platform filtering	Support external platforms without extensive in-tree overlays
High	Define ownership and maintenance responsibilities	Establish accountability for vendor-specific code
High	Clarify API stability and compatibility expectations	Reduce cross-repository breakage
Medium	Prototype external platform repositories	Validate whether West can support the proposed ecosystem model
Medium	Evaluate hierarchical integration workflows	Determine whether delegated integration can scale within existing infrastructure
Medium	Establish criteria for main-tree inclusion	Avoid treating every incoming board or driver as permanent core responsibility
Medium	Improve West manifests and dependency management	Preserve a consistent user experience across repositories
Medium	Review HAL integration rules	Reduce unnecessary coupling, compatibility layers, and maintenance burdens

These are proposed follow-ups derived from the discussion, not formally approved or assigned meeting actions.

5. Overall conclusion

The meeting exposed a fundamental tension in Zephyr's evolution: the project wants to remain a highly integrated, well-tested RTOS while supporting an increasingly decentralized and diverse hardware ecosystem.

A monorepo provides significant development and integration advantages, particularly for cross-component changes. However, keeping all platform-specific code and maintenance responsibility centralized creates growing pressure on the project's maintainers and infrastructure.

Separating code into more repositories would not automatically resolve these problems and could introduce new complications for API compatibility, testing, releases, and downstream users.

The most actionable near-term opportunities appear to be improving maintainership and review processes, clarifying ownership, reducing test configuration complexity, and strengthening interface stability.

The longer-term direction remains open: Zephyr should make it possible for components and platforms to participate in its ecosystem without necessarily requiring everything to live in the main repository.

The meeting ended without selecting a particular architecture or migration plan. The intention was to continue exploring the options, improve the underlying tooling, and avoid making repository restructuring a prerequisite for addressing the existing scalability problems.