Why is Qubes OS project team so small?

That’s probably what should happen.

Contributors are one thing but I am talking about the core team. They are not charities, they are paid from sponsors and donations.

It isnt. There are many projects which work with users making a
contribution without payment. You must know this.

My thoughts -

  • Some users want to remain anonymous. That wouldnt stop them contributing. Perfectly possible to work on GitHub anonymous and over Tor.
  • The roadmap includes moving features out of dom0. That’s stated over and over. But any one can start contributing by starting squashing bugs.
  • Do you find the instructions in qubesbuilderv2 not simple? They seem straightforward. The number of repositories may seem difficult to start with. It isnt difficult to find where some feature or program is packaged, and then to find the repository that provides that package. But you can always ask.
  • You overstate the difficulties in working with the team. The primary place to discuss features, difficulties, etc should be qubes-devel. Look at how @qubist is handling changes to firewall, and BenGrande. This is clearly stated under contributing in the docs.
  • No one should expect to work on a feature in isolation, and then hope for it to be accepted. Work on a bug within existing framework, or propose a new feature etc. That seems to be how progress is best made.

I said much earlier - the number of people in the core team does not
equate to the number of contributors.

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

1 Like

This is not true. There are members of the team who work for ITL and
work on Qubes. There are others who work for free. There are contributors
who are paid (from some source) for their work and others who work for

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

Perfectly possible to work on GitHub anonymous and over Tor.

Unfortunately, it is no longer possible to register on GitHub and use its full functionality without JavaScript. (Ironically, the same applies for this forum).

Just a side note.

1 Like

I think it’s impossible to register at GitHub over Tor even with JavaScript right now:

1 Like

Simple or not, they don’t work reliably, and asking is hit and miss.

Which is in a completely separate place to “Developer documentation”. Discovery is a problem with the website that’s come up for me a few times before - sometimes it’s not a reasonable expectation on the user, who would basically have to read it cover to cover to find what they’re meant to know. So the fact that it’s clear once you find it is neither here nor there.

The projects that naturally attract more contributors than they can use can maybe get away with not investing in contributor experience, but that doesn’t make it sensible. Getting keen hackers isn’t always the same thing as getting good contributors, clearly.

Perfectly possible with headaches including high connection instability, account flagging, and low confidence in Microsoft’s attitude towards privacy.


23 posts were split to a new topic: Contributing on GitHub requires JS and that creates challenges and some are discouraged

It was appropriate to answer about the core team size not being a definitive measure, but knowing the volume of external contribution is necessary to support that point. Looking at git logs across all Qubes-owned repos over the last year, external contributors and contributions are few and cover a tiny fraction of the codebase.

I’m not sure why you’d think anyone was talking about templates, except that it’s the bit you provide professional services on.

I wonder how I can tell you haven’t tried.

1 Like

Well, if you want to build a Qubes iso, you have to build client
packages and templates. So there’s that.
As to “professional services”, I have no idea what you are trying to
say. I dont get paid to build the templates or packages that I release
at 3isec.

Obviously you cant tell. It’s true that I havent built a full iso for some
time; I mainly build individual packages and templates. For most
trouble shooting and fixes, that’s all that’s required.

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

1 Like

Some who understand the above choose not to do it. So, Qubes may be missing the contribution of experts who have deeper understanding. That’s the only point I am making. Not looking for an argument at all.

If those experts actually existed, I’m sure they’d be able and willing to contact the qubes team to talk about this and see if they can come up with a solution. So no offense, but to me this is mostly pedantry / tokenizing “experts with deep understanding for whom true anonymity is a necessity”. Point simply is, given the size of the team, that you have to direct limited time and resources. And then it makes little sense to anticipate on this by moving away from github now that it’s been bought up by MS simply out of a wholly invented FOMO worry.

The point is that trying to shoehorn user feedback into what you already know about, and labeling the rest as fruitless or summarily dismissing it when it’s based on knowledge and effort, isn’t just unhelpful, it’s obstructive. In this thread, you’ve tried to close down concerns from the OP, Solene, and me, with at most minimal or trivial engagement. If you do have any financial incentives behind that behavior - and you’re pushing your brand repeatedly here so I’m pretty suspicious - then that would be a lot worse.

Hello , june 11, 24 i think it will be very pleasent for this TEAM, to encourage …and thank for their greate work. Sorry it is my personal opinion…

I’d say that compared to some, my “pushing of the brand” is non-existent. The only thing I do is host Qubes material on GitHub, and a server provided by a supporter of Qubes. I rarely reference them or promote them.
I think your insinuation was unpleasant and uncalled for.

To the matter in hand:
I havent tried to “close down” concerns raised in the thread. I did try to close down the initial concern raised by @jagnopurka because it was based on a misunderstanding. You did much the same in your initial response.

The thread has moved on to other matters. I tried to directly address some misunderstandings, or things I found misleading.
Among other matters raised:

  • Risks of “losing” core contributors
  • Lack of funding for team
  • Lack of funding for contributors
  • Issues remaining unfixed for a long time.
  • Issues and PRs often remain unanswered.
  • Difficulties in getting involved
  • complexity of code arrangement
  • lack of developer documentation
  • lack of simple build instructions
  • Hard to reach core team
  • Lack of a clear roadmap.
  • Lack of perceived “core” features:
  • incremental backups
  • GPU acceleration
  • working dark theme
  • Problems with video-conferencing
  • remote management
  • Difficulty of commercial deployment
  • Issues with Qubes using GitHub
  • Proposal to fast track upstream committers and maintainers to have commit access to Qubes.

Thats pretty wide ranging, and I undoubtedly missed some things. Let’s break it down in to manageable chunks. I’ve tried to deal with some already.
For issues with GitHub, I’ve offered a proxy service to allow people to contribute without touching GitHub, and it’s also possible to email in diffs for changes.
Discussions about aspects of the design, code arrangement, contributing features, and build documentation should take place on qubes-devel. An alternative proposal - create a specific category here in the Forum for development, where these things can be discussed. We can share problems, experiences, solutions, and so on, and that can feed in to improved developer documentation.
@alimirjamali’s project to clean up qubes-issues should be encouraged and you could join. We did something similar on the transition to 4.0 and made inroads in to the issues then. It’s undoubtedly time to do it again.
These may help overcome some of the barriers to entry.

Qubes need contributors, both on documentation and code. There’s a current thread on becoming a Qubes developer with some good ideas: take a look at that, and dive in. Be realistic where you start. Dont try to rewrite the whole doc web site - you can start with a single page or a single image. Dont start by trying to build the whole system - start with a single package. Look at open issues one by one. Whatever you can do, you can make some contribution, and help improve Qubes.

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

It was substantiated and important to me as a user. I’m pleased to learn there’s nothing in it. I apologize if this was out of proportion compared to what other people are doing - I wasn’t aware of that.

I’m going to leave it there. I think I’ve been clear enough about my views on contribution, and that discussion can carry on in other places.

I’m happy to do that explicitly at least once. I wouldn’t be here if I didn’t think it was great. What we all want is for the great things to survive and spread, which is why we raise issues.

It was not substantiated, and you should not suggest it was. However, I accept your apology.

Besides raising issues we need people who will contribute, in any
capacity. I suggested areas, and made some proposals to move forward.

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

1 Like

Besides raising issues we need people who will contribute, in any
capacity. I suggested areas, and made some proposals to move forward.


Would it be possible to have an up-to-date task list of what actually needs to be done, so that a newcomer may start contributing fairly quickly without having to acquire a mountain of knowledge?

What I mean is: Looking at ~2k issues is not encouraging that at all (especially when there are “critical” ones from 2015). One would rather get lost in that and give up in 10 minutes.


  • fix typos in doc X, Y, Z (required skills: English language)
  • refactor code in files A, B, C (required skills: Python)
  • create a script for … (required skills: shell scripting)
  • create functionality for … in … (skills: C, …)
  • etc

Individual tasks may be linked to actual issues or milestones and a project manager will check each fulfilled task. Contributors may receive some kind of reward/score for each successfully fulfilled task, so they are recognizable in the community for their contribution. Based on pre-defined thresholds a contributor may receive extra rights, e.g. to add items to the task list and so on.

There is a help wanted label on GitHub: Issues · QubesOS/qubes-issues · GitHub

1 Like

There’s also the good first issue label, which is currently on only four issues.

1 Like

None of these 2 links is quite what I mean.

Well, there’s also the Current team tasks board, which shows what the team is actively working on at any given time.