At a Glance:
- Involved in open source since: 2020
- Works for: Thales
- Eclipse Foundation contributor since: 2020
- Involved in: OpenHW CVA6, OpenHW CORE-V cores
- Eclipse Foundation committer since: 2020
What’s your background as a developer?
My background is in hardware development, specifically digital integrated circuits such as ASICs and FPGAs. I spent more than 20 years in this field, working as a developer, then as an expert, project leader, and eventually a team manager. During that time, my work was almost entirely proprietary. I was far removed from open source.
How did you get involved in open source?
About seven years ago, Thales’ Technical Directorate decided to invest in open source hardware, particularly RISC-V. They needed someone to coordinate these activities, and that’s when my role was created. I joined Thales Research and Technology (now Thales cortAIx Labs) in March 2020 to help implement this strategy.
The transition from proprietary development to open source was a big shift. Open source requires a mindset of collaboration and openness. You share your work publicly and engage with a community. That’s very different from proprietary environments, where NDAs and IP protection limit what you can share.
How did you become a committer at the Eclipse Foundation?
My involvement with the Eclipse Foundation came through the OpenHW Group, which was created in 2019 as an independent non-profit but worked closely with Eclipse Foundation processes, such as the contributor agreement. I became a committer around 2020 when the group operated as a project within the Eclipse Foundation ecosystem.
In January 2025, the OpenHW Group was officially integrated into the Eclipse Foundation and became the Open Hardware Foundation. Over time, projects evolved, and today I’m mainly involved in the OpenHW CVA6 project, which grew out of the broader Open Hardware initiative.
What are the biggest challenges as a committer and project lead?
There were two major challenges early on.
First, starting a project like CVA6 without prior open source experience was difficult. We had to get our feet wet with basics like GitHub. We made mistakes, especially in how we guided contributors. It took time to establish clear guidelines so contributors could effectively collaborate with the project with lower frustration.
Second, in the early years, we faced what I would call a “Death Valley.” The project started in 2020, but initially there were few contributors or adopters. We didn’t know if the project would gain traction.
Today, the challenges are different. CVA6 has grown into a popular open source RISC-V core, and now the challenge is managing and coordinating a large and diverse community. We need to balance academic contributions with industrial needs while maintaining a cohesive direction.
Co-leading the project with Jean-Roch Coulon, my colleague from Thales, has been very helpful in addressing these challenges.
What have been the highlights of being a committer?
Two highlights stand out.
The first is seeing the community grow, from a small group to a vibrant ecosystem of contributors.
The second is seeing CVA6 being used in real products. Even though many applications remain confidential, knowing that the work is making its way into real-world systems is very rewarding.
Any advice for someone new to open source?
A few things come to mind:
Join an existing project first. It’s much easier to learn how open source works by contributing to an established project rather than starting from scratch.
Read the documentation and guidelines. Projects usually have contributing guidelines. Understanding them is essential before submitting work.
Align with the roadmap and the project team. Just because you can submit a pull request doesn’t mean it will be accepted. Contributions need to fit the project’s direction. Also consider the people who will review your contribution and the time they will devote to it.
Avoid fragmentation. Too many independent contributions without coordination can harm a project.
Finally, if you start a new project, establish clear leadership. A small leadership team – two people works well in my experience – helps maintain direction and accountability. Leading together is always better than leading alone, and if one of them is on vacation, the other leader(s) can still run a meeting.
Any other recommendations?
I would encourage people to engage with the community beyond code contributions, for example, by attending events like the RISC-V Summit Europe in Bologna this June. These gatherings are great opportunities to connect and collaborate.
From an organisational perspective, open source also enables vendor independence and technological sovereignty, something my company, Thales, has been very focused on. It allows organisations to take control of their computing solutions rather than relying entirely on proprietary technologies. Thi