Driving SDV Project Adoption and Involvement With Maturity Badges

The automotive sector of open source is unique. It’s true that not all open source projects are being developed with the aim of commercial application, but even among the ones that are, automotive projects are in something of a league of their own. 

While any commercially aimed project will need to satisfy requirements around usability, robustness, performance and software engineering quality, the automotive industry is highly regulated and extensive certification is required for commercial products. But the open source community has always been a bit leery of certification, especially because it’s expensive to do. 

For this reason, the Eclipse Software Defined Vehicle (SDV) Working Group is going to introduce maturity badges, which will be released alongside the SDV process. These voluntary badges will serve to communicate the maturity of projects to potential adopters in the commercial space, which should benefit both the project and adopters.

Hesitation to Adopt Hurts Open Source Engagement

While companies in the automotive space are well aware of certification requirements, there is less awareness and familiarity with open source development practices. Typically, the main question is: Can any of this actually be used in a commercial deployment?

The question itself speaks to the need for a maturity model. While open source is undoubtedly a hotbed of innovation and there’s a great deal of remarkable work being done, from the outside it can be difficult to judge the standards to which individual projects hold themselves. 

For other industries, this may be a relatively minor obstacle. They’re generally more familiar with open source and industrial regulations aren’t especially stringent. But the automotive sector is still relatively unfamiliar with open source, and the industry is heavily regulated and has numerous standards it must meet to launch commercial products. Without an easy way for automotive players to tell at a glance whether a given open source project will provide a viable base for a commercial product, they’re considerably less likely to give those projects the kind of support they need to grow and flourish. 

This is the problem that the maturity badges are intended to help solve. These small but clear and distinct graphics will communicate to potential adopters exactly what to expect from a given project and provide them the confidence that they need in order to commit resources back into the project. 

SDV Process and Maturity Badges Will Be Aligned

There’s a saying in the open source community that open source software is free as in free puppies, not free beer. It’s not something you can just consume. Unless everyone is chipping in, those puppies just aren’t going to grow.

It’s the same with software engineering practices and code quality. While it certainly doesn’t make sense to shift the burden of certification onto the open source community (rather than the commercial adopters of those technologies) there is definitely a role for the community. That’s why the maturity badges and the SDV process are really just visualising existing best practices in open source. 

Initial Structure Will Be Five Pillars, Each With Three Tiers

While it’s worth noting that the requirements are going to form a living document and will continue to change and evolve with the support of the community, the initial structure has five pillars, each of which comes in three tiers:

• Requirements
• Documentation
• Testing
• Coding Guidelines
• Release Process

Each of the tiers within a given pillar will build on the previous tiers. In general, expect the first tiers to be relatively vague. For example, the first tier of the requirements pillar only requires a project to have documented requirements. It doesn’t include any specificities for how many documented requirements there need to be, nor does it note any tracking or reference requirements. In other words, it only represents a basic aspect of a development process, whether open or closed source. 

It’s the later tiers that speak for a more formalised and stringent process. For example, tier two of the requirements pillar requires 100% documentation of exposed features, and that changes to requirements be tracked in release notes. 

The ultimate goal of these criteria is to provide, at the highest tiers, a solid framework for a commercial adopter to take this technology and certify it for a specific use case. Ideally, a project that has satisfied the highest tiers of each pillar will provide every engineering artifact possible that is going to enable certification. 

Badges and Process Represent a New Step for Open Source

It’s also definitely worth noting that none of this process would have been possible without support from the community. This kind of regularisation of process and methods is something you typically see in closed-source environments, and it tends to happen more quickly there. But it was very important for us that the origination and development of these standards was done in the open source way. And while it’s been a long road to get where we are, the fact that we have well-defined criteria and evaluation mechanisms that were created in an entirely open and community-driven way is remarkable. 

The hope is that the community continues to drive the development of the process and badges. As projects become more mature and adoption increases, it’s likely that the process will grow to cover more criteria and we will add more to it. But we want to keep that process community-driven in the open source way. 

Eclipse ThreadX Project a Testing Ground and Proof-of-Concept

The Eclipse ThreadX project, contributed by Microsoft, is something of a test-case for the SDV process and maturity badges. It provides a vendor neutral and safety-certified OS for deeply embedded applications, making it well-suited for in-vehicle applications. 

The project came with certifications that we intend to maintain, including safety and cybersecurity. But we want future versions of it to be certified as well. This will require the project to have a well-documented and strictly implemented development, testing, and management process. 

That’s being developed now, with the plan to bring it back to the Eclipse SDV Working Group and use what’s been put together to help guide us as we evaluate the SDV process. The community can then have an open discussion: Do we adopt the stricter ThreadX process wholesale, stick with the SDV process as is, or just adopt the elements of the ThreadX process we think are beneficial to allow the SDV process to make projects certifiable?

Community Support Needed to Continue Driving Efforts Forward

As far as these efforts have come, we’re still only really at the beginning. After the initial launch we will begin the process of refining the badges and process. 

As such, this effort will continue to rely on the community getting engaged with the material, contributing to the coding efforts, as well as the discussions around what should and shouldn’t be in the process and related badges. It will also be helpful for people to try out the process of getting the badges and meeting the requirements. Making sure that the process makes sense and adds value will help drive future changes and provide a stepping stone for future development.