FAQs

The Zephyr™ Project is a scalable real-time operating system (RTOS) supporting multiple hardware architectures. The Zephyr vision is to be the best-in-class RTOS for connected resource-constrained devices, built with security and safety in mind. As a Linux Foundation hosted Collaboration Project, Zephyr is an open source cooperative effort uniting leaders from across the industry.

The Zephyr Project’s goal is to establish a neutral project where silicon vendors, OEMs, ODMs, ISVs, and OSVs can contribute technology to reduce the cost and accelerate time to market for developing the billions of devices that will make up the majority of the Internet of Things.

The Zephyr Project is perfect for building everything from simple connected sensors, LED wearables, up to modems and small wireless gateways. Because the Zephyr OS is modular and supports multiple architectures, developers can easily tailor an optimal solution to meet their needs. As a true open source project, the community can evolve Zephyr to support new hardware, developer tools, sensors and device drivers. Enhancements in security, device management capabilities, connectivity stacks and file systems can be easily implemented.

The vision for the Zephyr Project is to create a truly community-based, open source RTOS that isn’t just called “open”, isn’t just licensed “open”, but actually lives and breathes the “open source way” (http://opensource.com/open-source-way and http://www.theopensourceway.org/). We want this project to be useful to the largest number of developers worldwide and in any industry that needs it. For that to happen, we are seeking discussion and active participation from a broad range of organizations. We want collaboration so that the Zephyr OS can evolve to meet the needs of its community.

The project has identified a core set of Maintainer roles – kernel, subsystem, architecture (ARM, x86, ARC, and others), security, and developer experience. As the Zephyr Project matures, the Maintainer roles will also grow to accommodate the need of managing the detailed subsystems, additional hardware support, and other features as well as documentation, advocacy, community management, financial management, and all the other trimmings needed for a healthy organization. We expect these roles to come from the member organizations, particularly those who have a proven track record of RTOS and small OS development. As with most open source developed projects, the Zephyr Project seeks contributors willing to learn the codebase and contribute support via feedback, code, and feature development to evolve the software to become more modular and better suited to distributed and open development. Finally, the project seeks community managers with expertise in working and facilitating with open source development.

Contact us zephyr-info@linuxfoundation.org now if you are interested in taking an active role.

Licensing choices are always a source of conversation in open source communities. The Zephyr Project chose Apache 2.0 for three main reasons:

  • It’s permissive enough to allow the community and customers to use the code and contribute value back to the community.
  • It’s an Open Source Initiative (OSI)-approved, permissive license that is in broad use and well known. This enables the Zephyr Project to expand membership to a broad set of organizations including those who have not typically participated in open source development in the past. 
  • It has a well understood patent grant.

A permissive license gives the user the option to use proprietary extensions or share their code. Contributions are accepted without a Contributor License Agreement (CLA), and the expectation is that contributions will have the license captured as part of the headers in the code. IP compliance will be checked prior to acceptance into the codebase.

The Zephyr Project Governing Board is exploring various safety certifications and their relative values for members. Safety certifications require strict development processes best implemented with a parallel code base, which likely would require additional engineering resources beyond those devoted to the current project roadmap. If you’re interested in learning more about these conversations and wish to participate, we’d love to know what you think. Engage with the community on Slack, and become a member today.

The Security Working group is exploring a security audit and will make recommendations comprising readiness, breadth of implementation, and resources required to the Governing Board. To find out more about how you can participate, please contact: info@zephyrproject.org.

Zephyr Project supports multiple architectures including ARC*, ARM*, Nios II, RISC-V, Tensillica, and x86. Details regarding the full list of boards supported can be found here.