The path to RISC-V growth: Why software consistency is becoming crucial

Interviews | March 5, 2026

By Alexander Neumann

On 15 April, 2026, Elektor is hosting a conference on RISC-V and its increasing significance for embedded and IoT systems. Ahead of the event, we spoke with one of the speakers, Marcos Codas. He is a Director of Partnerships and Education at GDevelop, which provides an open-source, no-code and AI game engine. His presentation will be on the creating a centralized game store for the SiFive HiFive Premier P550 RISC-V board. He will present evidence of how software fragmentation affects platform adoption.

Alexander Neumann: At the RISC-V conference you’ll speak about “software fragmentation” as the main reason why developers often return to ARM despite its architectural freedom. What specific fragmentation problems are most common with RISC-V desktops today?

Marcos Codas: RISC-V for desktop, server and general consumer products is advancing fast from a hardware perspective. But from a software perspective, there are a number of issues that pop up on desktop that make it difficult to adopt any given RISC-V board as a medium-term platform.

First, there is basically no mainline kernel adoption. Most board manufacturers provide their own kernel, which often lack basic driver support at launch. These kernels are sometimes years behind the main Linux kernel in terms of features, security, and other factors that affect the userland experience. And when we talk about userland, even within boards whose hardware makes it possible to share binaries for applications, the repositories are fragmented.

For example, Ubuntu is capable of running Debian binaries. The Debian repositories have a plethora of applications that the Ubuntu repositories do not have access to. This leaves users of boards that ship with Ubuntu in a situation where there are applications that could potentially run on their hardware, but to which they have no out-of-the-box access.

Even on ARM, this segmentation is a lot less prominent, and users are usually able to access compatible binaries more easily. This reduces the friction in the adoption of the platform, and entices developers to continue working on the more mature ARM ecosystem, despite the fact that RISC-V could rival software availability if users had easier access to the right repositories.

Neumann: You call eliminating deployment complexity a “strategic necessity.” How do you measure this effect – for example, reduced setup time or a lower error rate?

Codas: In my opinion, it starts with access. If we go from having 100 applications easily available to Ubuntu RISC-V users, to 1000 applications by simplifying deployment and access, this completely changes the friction of adoption equation for new developers. And that’s where reduced setup times and lower error rates do come into play. If a user or developer knows that they have out-of-the-box access to the tools they need to utilize the hardware properly, they are way more likely to invest in the ecosystem.

There is a finite number of developers in the world, with a finite amount of time available to them. Making RISC-V an ecosystem they can develop on, rather than one they have to fight against, is crucial.

Changing the equation from “I will need to find a way to compile my own binaries, or track a compatible binary down, before I start working”, to “I can just install the tools I need to get the work done” will also have a measurable effect: higher rate of adoption, better attachment rates, better sales figures for desktop-tier hardware, and much more.

Neumann: Which typical setup errors or incompatibilities are completely eliminated by your toolchain/store model?

Codas: Because the store is curated, the user knows that whatever they choose to install will run. There are two scenarios that the store specifically addresses:

A compatible binary is found on a repository that is not available: for example, Debian binaries for Ubuntu users. In this case, the tool simply installs the right binary from the Debian repository.
An application needs to have hardware-specific flags set to run, or run well: in this case, a build recipe is created, so that the application is compiled on the user’s hardware, with the flags set to allow for compatibility or performance.

From a technological perspective, this is not a gargantuan effort. But from the perspective of user experience, it can turn otherwise countless hours of looking for the right binary or repository (and even then, not knowing if it’ll work, or work well), into a few seconds, or minutes, at most, installing or compiling a working version of the application.

Neumann: How do developers who simply want to quickly run a binary respond to the option of using build recipes?

Codas: Using build recipes has its advantages and disadvantages. While it may be slower than simply downloading a binary and installing it, you have the advantage of knowing the code is being compiled from a trusted source.

There are people who prefer each option more than the other. However, either of them is better than looking around for hours on end for a compatible binary, testing different versions or compile flags, and all of the other tedium this store is looking to remove from the user experience.

Neumann: To what extent can a consistent software ecosystem remove the biggest hurdle to RISC-V adoption?

Codas: It can definitely be a factor for logarithmic growth: the more consistent the software ecosystem, the better the user experience. The better the user experience, the more people will choose RISC-V over other platforms. The more people choose RISC-V, the more hardware sells, allowing manufacturers to iterate faster, as well as creating the bedrock of RISC-V developers of the future.

However, software is only a part of the desktop computing equation. Hardware is also very important, and the performance and efficiency deficit of RISC-V when compared to ARM and even x86-x64 also plays a big role for a lot of developers looking to experiment with the platform.

Having said that, my experience working for an open source software company for the past few years points to a positive correlation between an improvement in user experience, and platform adoption.

Neumann: Beyond the software side, what features do you think RISC-V still needs to compete with ARM in the next two to three years?

Codas: We’re in a very difficult time right now, due to the shortages and price increases we’re seeing across the industry. However, since this affects RISC-V as much as ARM or x86-x64, we can still benefit from:

Improvements in power efficiency
Improvements in raw performance
Easier boot management/BIOS or UEFI adoption

If RISC-V manufacturers can address at least 2 of those 3 points, we’d be looking at a much healthier growth pattern.

This last point is something that the RVA23 is already looking to address, as fragmentation continues to be a concern for users who don’t want to deal with proprietary operating system images, EOL status for their devices, and more.

On this point, I see the store I’m working on as an extension of the RVA23 profile’s philosophy of binary defragmentation.

Future hardware may see the RVA23 standard rectify this fragmentation issue to a large degree. But it will not help the many thousands of boards produced up to this point, which while very capable from a hardware perspective, and suitable for a wide range of applications, may see obsolescence come sooner than it is desirable.

Neumann: What role can the open-source community play in maintaining recipes, patches, and driver configurations?

Codas: I am hoping that it will play a large role, indeed. I have access to limited hardware, and while I plan to continue supporting the hardware I do have, I want owners of other boards to benefit from this project as well.

That’s why I will be making this project open source in its entirety, not just the recipes. That way, people can adapt the code to suit their needs, add support for their own boards, and share that with their community as well.

For more information on Elektor’s online conference “RISC-V – Open Architecture for Embedded, AI, and Automotive” on 15 April, see the conference website. Register today! (Early-Bird discount is active until 20 March.