Why is Qubes OS project team so small?

Looking at Team | Qubes OS , it seems there are only 5 coders working on Qubes. This seems like a quite small amount for something as ambitious and complex as Qubes OS. Even Linux Mint which is just a fork of Ubuntu has more people working on it (at least what they officially state).

I can’t help but feel somewhat worried about the long-term future of Qubes OS, even more so that Xen itself also is not really used by any big player (last one was Amazon who switched to QEMU/KVM) which also may be bad for its long-term future.

Does anyone else also share these concerns?


The design means I’m much more comfortable with this project having a small development team than I would normally be. I hope they don’t all get in the same cars, though.

Is the Xen community worried?

1 Like

Not at all.

1 Like

More people getting involved would be nice, but it’s a niche operating system and I think the entry barrier is quite high to get started, it is really complicated IMO and there are not much developer documentation for newcomers.


I do. I think that due to the huge room for improvement for such thing as OS and its complexity, the current development is not fast enough to even keep up the situation at the same level, to keep the OS stable.

Some things are inevitably drop off and stay unfixed for way too long to call the Qubes OS stable or average-user compatible. E.g. currently we lost QWT for Windows that was working from version R1.0 or something, and there are no man power to get it back, in R4.1 keyboard layout switching was not working properly, huge regression that was not fixed during R4.1 lifetime. Third-party contributions are not accepted for years, too, because even accepting third-party free help also requires work from the Team.

So, many things that require attention are not processed due to the lack of software developers, so I share your concerns.


Are you suggesting that the United States Air Force is not by any means a “big player” with the way they use Xen?


Of course, not big. It’s even not a software “player” in the first place. And if they really have a lot of software-developers-resources, they can switch to KVM or something, too.

Don’t you agree, that Xen is not very “popular” nowadays, most virtualization cases, including hostings, are leaning towards other virt solutions?


Is SUSE and Red Hat not also dedicating resources to Xen development?

1 Like

Let’s start with the official Xen Project website - it’s stated that The Linux Foundation® has the copyright to it.

Furthermore, I wanted to address the messages that are to give the impression that “it’s just some no-name project that nobody uses”, despite the official endorsements at the Project’s website and the document I posted in my earlier message.

The choice of a hypervisor can mean different things to different people and I don’t feel like speaking on behalf of companies, which heavily utilize virtualization for their cases (among which could be hosting virtual servers), especially since I don’t work for them and don’t know, why the choice has been made.

Or maybe I’m missing the point and people are worried something I’m not aware of yet, when it comes to virtualization solutions and their popularity - If so, my first guess would be about some hypervisor functionality that is not yet implemented. However, if there’s a reasonable demand for that, I’d start with the following GitHub tickets:

and then either contacting Invisible Things Lab to ask, how much would such a huge effort cost, or setting up own team, who could then spend time developing such a solution.

1 Like

There’s a fundamental misunderstanding here. The size of the team bears
no relationship to the number of people contributing to Qubes. It’s an
open source project that any one can fork, or to which any one can contribute, by
proposing improvements or by submitting PRs.
It’s not uncommon to have numerous contributors but only a few core
team. In some projects there are many contributors and only one
dictator, benevolent or not.
More people ready to make a contribution would be a good thing, but I
would not give up the oversight and judgements made by Marek et al.

Others have offered a correction on this. But note too that the link to
Xen is historical and not essential.

Perhaps. Not me.

I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.

1 Like

Does anyone else also share these concerns?

What if one does? What will that change?

1 Like

One could give money, the transparency reports include all expenses, some people are paid to work on some parts / features. See Qubes OS · Expenses - Open Collective


Theo heard you! :upside_down_face:

@jagnopurka It‘s not about numbers, it‘s about efficiency. Security updates are delivered quite quickly IMO.

1 Like

Yes, that’s definitely important, if one can donate they probably should!

Spark a discussion like this one. I’m curious what is the reason: do they think they have enough resources as it is? Does complexity scare newcomers away? Is the funding insufficient? Are there other organizational issues? Everyone could probably agree that the project would benefit from more manpower.

I agree regressions should always be #1 priority even during lifetime of a release. I never needed many keyboard layouts or even Windows VMs for that matter, but it does sound bad.

The OS is still even missing basic functionality one would expect from a desktop OS like: incremental backups, GPU acceleration (not just passthrough), or a proper dark theme that actually works…

Can you elaborate?

That’s what saddens me the most: that outside of security enthusiasts that care about their personal data, no one really cares for secure desktop computing. Everything seems to be focused on server security (like SELinux/AppArmor). Flatpaks are one half-assed attempt at desktop “security” but they are pretty bad because it fully trusts the app devs to create their own policies and too many of them simply come with filesystem=home. I wish Linux had a more secure app model like Android does.

A project like Qubes should gain a lot of traction and support from big players like Red Hat, hell, even hardware manufacturers that would avoid many hacks that Qubes does. But again, just no one really cares for desktops. Another “Qubes-lite” of sorts project is SpectrumOS, but it also seems to be just one-man small-house project with no real traction.

What is there about Qubes design that justifies smaller team?

Yeah, I thought about that too… but thought it inappropriate to mention here :stuck_out_tongue_winking_eye:

1 Like

It’s hard to motivate people to use a system where video conferencing barely works or requires a very powerful machine :confused:

It is also complicated to deploy Qubes OS in a corporate environment with remotely managed account, I suppose Invisible Labs business relies on this kind of setup though.


Spark a discussion like this one. I’m curious what is the reason: do they think they have enough resources as it is? Does complexity scare newcomers away? Is the funding insufficient? Are there other organizational issues? Everyone could probably agree that the project would benefit from more manpower.

If you think those are the issues, the only thing you can do is:

  • fund
  • learn
  • join
  • manage

Be the example of the change you want to see :slight_smile:


You mean something like qubes-remote-support but without Tor?


I’d love to have it. Preferably it should be available (optional) out of the box, with salt command or some package installation, not third-party solution. Because the lack of reliable and production-ready remote control (like VNC/RDP) stops Qubes OS from being used on PC-routers.
VPN chains, including shadowsocks, tor and other stuff, network virtualization solution (with cross-vms connections) that are available out of the box: all that are unique features of Qubes OS, that cannot be used in router-type PCs, because to change something user is required to connect keyboard, display and mouse each time.

1 Like

Well, that is kind of a problem I see and raise from time to time: there is no actual long-term priority list, plan or roadmap. You cannot know what Qubes OS is expected to be in a 2 years or in 5 years. Only some vague things, like, probably it will support wayland eventually some day.
Which is not a roadmap, of course.

This worries me even more than the lack of software developers, because I see no picture of future of the only OS I love.


I guess this has been like that since Qubes OS exists, and this didn’t prevent it to be where it is now :thinking:

1 Like