Open Source Summit North America 2026 and Embedded Linux Conference brought together the open source community in Minneapolis from May 18–20, 2026.
According to the event report, the event welcomed 1,231 attendees from 524 organizations, with 68% of attendees in technical positions. The program included 210 conference talks selected from 977 talks submitted, reflecting strong interest and participation across the open source ecosystem.
For the ELISA Project community, the event was an important opportunity to continue the conversation around safety-critical software, open source safety standards, regulatory compliance, requirements traceability, verification, software supply chains, and safety engineering.
The Safety-Critical Software Track highlighted practical work across several domains, including aerospace, embedded systems, medical devices, robotics, avionics, automotive, and industrial systems. Sessions explored how open source communities are addressing the technical, process, and compliance needs of safety-critical systems.
Over the next few weeks, we will highlight selected session recordings from the track and share key takeaways with the community.
Session Highlight: From Pull Request To Patient Safety: How Tidepool Built an Open-Source Quality Management System – Tapani Otala, Tidepool
In this session, Tapani Otala of Tidepool shared how Tidepool built an open source Quality Management System (QMS) for safety-critical medical software.
Tidepool is a nonprofit organization founded by people with diabetes, parents of children with diabetes, and clinicians. The organization builds open source tools for diabetes care, including Tidepool Loop, an automated insulin delivery system. Tidepool Loop uses data from a continuous glucose monitor, runs an algorithm on a phone, and communicates with an insulin pump to adjust insulin delivery. Because the software can influence insulin delivery every five minutes, including while a person is asleep, the system must be developed with strong safety and regulatory controls.
A central point of the talk was that open source and FDA-cleared medical software can coexist. Tidepool Loop was cleared by the FDA as Class II Software as a Medical Device, while the source code remained open. Tapani explained that safety and regulatory standards define what evidence and controls are needed, but they do not require the software to be closed source.
The session outlined the core elements of a QMS, including traceability, verification and validation, risk management, and change control. Tapani described QMS as a controlled, repeatable, and auditable system made up of policies, procedures, records, requirements, risks, tests, reviews, and change history.
A major part of the talk focused on how Tidepool connects engineering work to regulatory evidence. Requirements are tracked in Jira and linked to design, implementation, tests, risks, mitigations, bugs, and other records. These links are not just references; they form the structure that allows Tidepool to trace a requirement through development and testing, and then trace code or test evidence back to the original requirement.
Tapani used a specific requirement for insulin delivery presets as an example. A feature that may appear simple to users can generate a large set of safety and regulatory artifacts, including development tickets, test tickets, risk records, mitigations, UX design work, usability testing, and training requirements. In one example, a requirement for presets was connected to multiple risks and tests, showing how safety-critical software features can create significant downstream evidence needs.
The session also explained how Tidepool generates regulatory outputs from its development data. Instead of manually creating traceability matrices and risk analysis documents after development, Tidepool uses scripts to pull structured information from Jira and generate workbooks for regulatory review. These outputs include traceability views, risk analysis, hazard analysis, cybersecurity hazard analysis, and related summaries. This helps reduce manual drift and keeps documentation connected to the engineering work.
Another important topic was Tidepool’s relationship with the upstream open source Loop community. Tidepool Loop was based on the earlier do-it-yourself Loop project, which was created by a community of people who wanted better automated insulin delivery tools. Tidepool needed to maintain regulatory control over its FDA-cleared product while still staying connected to upstream innovation. The team does this by selectively bringing in changes, running them through the regulatory process, keeping shared code modular, and offering improvements back to the open source community where appropriate.
Tapani also shared lessons learned from building this system. One lesson was that the schema behind tools like Jira matters because issue types, link types, required fields, and relationships become part of the regulatory structure. Another lesson was that heavy workflow gates can slow engineers down, while downstream validation and automated checks can help maintain data quality with less friction.
The broader takeaway for safety-critical open source communities is that transparency can support trust. Tidepool’s experience shows that open source development, regulatory compliance, and safety engineering can work together when traceability, risk management, testing, and change control are built into the development process.
As safety-critical software continues to expand across medical, automotive, aerospace, industrial, and embedded systems, Tidepool’s work offers a practical example of how open source communities can build auditable processes while keeping development open and collaborative.
Watch the session recording here.
Stay tuned for more Safety-Critical Software Track session highlights from Open Source Summit North America 2026. Check the playlist here.