Qubes OS Future

General Discussion
1

Hello everyone.

As a long time Qubes user since R3, I would like to bring up a subject and hear your thoughts on it.

Over 10 years ago, Qubes OS began with a small team, with Joanna as the main coordinator. After a while, she left and handed the project over to Marmarek, who is still the main developer to this day.
My concern is that if Marmarek ever steps aside, who will replace him? I’ve checked both the website and the GitHub organization, but most of the people listed are either no longer with the project or not qualified for the job. Basically, when I check the GitHub commits, especially for the upcoming 4.3 release, they seem to be based largely on Marmarek’s work and expertise. Some features are introduced by community members or core team members, but only for specific aspects of the system, such as the UI and the new device API. Marmarek handles everything Xen related or very low-level, and I can’t see anyone else doing this instead of him.

So, what will the play be if it ever happens? Who is most likely to take on the role? Will ITL hire someone from outside the company, as they did for the future Wayland switch?

I would like to hear your opinions on this matter, as it has been a concern of mine for some time.

7 Likes
2

help make the system better and more popular, so it attracts more developers, so there are less chance Marmarek will burn out and more chance we have a healthy and sustainable development team :+1: Meanwhile, enjoy Qubes OS

This is not something you can really plan anyway in open source.

10 Likes
3

As I mentioned in my initial post, there are already community contributors who add new features, particularly in R4.3. These contributors have made numerous small improvements and added the new preloaded dispvm feature for example. Unfortunately, that doesn’t change the issue. If Marmarek leaves, no one can take his place. He is also part of ITL and is paid by the company to work on Qubes OS while others do that for free or receive grants.

Based on the latest statistics, Qubes has around 60,000 active users. It has grown significantly over the past few years, but according to GitHub, it hasn’t attracted many new contributors. ITL plays a huge role in keeping Qubes OS alive. Without a main developer who understands the system to its core and knows low-level stuff, it won’t matter if you bring developers, the project will slowly die out or change its philosophy.

4 Likes
4

Personally, I have always wondered what exactly has Joanna (or Marek) studied to know all these in-depth things written in her papers/articles. I would be really interested to know that.

4 Likes
5

hacking

1 Like
6

I noticed that the Qubes team often ignores very cool community solutions. For example, there has been a long-standing request on GitHub to make dvm in RAM, and qubist has implemented this perfectly Really disposable (RAM based) qubes his solution works by default, nothing needs to be done. Just add it to the system and enjoy. But I haven’t seen the devs pay attention to it and give all users this wonderful solution

4 Likes
7

You have provided source for your first claim that the user base is growing but did not provide source that it hasn’t attracted many new contributors. “According to GitHub” is not the complete story. You have the burden of proof. I recommend seeing the pull requests of 50 of the biggest Qubes repos in contributor count and see how many developers appeared through the years. The number of 3rd party repositories involving Qubes also grew, check that out.

The proportion of Xen low-level developers interested and has time and expertise to contribute to Qubes OS related to the user base is a low parity.

7 Likes
8

I notice that some members of the Qubes community often think that because a forum post has a guide and works for them ^TM, then it is a proper solution and must be merged into Qubes because they are fond of the idea. That is not how it works, there are many things to consider:

  • it is a shellscript, Qubes OS prefers python
  • it uses a blocklist, adding a new log file to the system would be a cat and mouse game, the proper way would not save those files in non tpmfs in the first place
  • there are no unit or integration tests
  • a live system would be much better to guarantee that nothing is ever written to disk

I too was a complainer, saying that my X idea was not merged into Y project, but once you go the full length of a PR, you will notice how much time it takes to get just some lines of code or documentation into a project.

14 Likes
9

Okay, you are right. I agree. And I also prefer to use Qubes Live. And I really love the Qubes team and Joanna :heart:

1 Like
10

I’m the original poster, got an account problem.

New accounts have very limited capabilities, which is why I couldn’t post any links because it would’ve been impossible to list everything. However, since you want proof of what I said, let’s look at the most important repositories: the “core” and “agent” repositories, which are the most important part of Qubes OS. I’m leaving out the obvious ones, like Xen and all virtualization components, because Marmarek manages them exclusively, and the others work on top of the repositories I’ll list.

Let’s analyze the commits from the past two years by appending /graphs/contributors?from=8%2F12%2F2023 to each repository and only considering contributors with a high level of contribution.

  • qubes-core-agent-linux:
    • ITL: marmarek, DemiMarie, Guiiix
    • External: alimirjamali, rustybird, zpc0, ben-grande
  • qubes-gui-agent-linux:
    • ITL: marmarek, DemiMarie, HW42, fepitre
    • External: skyzzuu, alimirjamali
  • qubes-gui-daemon:
    • ITL: marmarek, piotrbartman, fepitren, DemiMarie
    • External: alimirjamali, ArrayBolt3 (Whonix, probably paid for work), Euwiiwueir
  • qubes-core-admin:
    • ITL: marmarek, piotrbartman, fepitre, Guiiix, DemiMarie, marmarta
    • External: ben-grande, alimirjamali, ArrayBolt3 (Whonix, probably paid for work)
  • qubes-core-admin-client:
    • ITL: piotrbartman, marmarek, fepitre, marmarta, Guiiix
    • External: alimirjamali, slayoo (early 2024), ben-grande, rustybird
  • qubes-core-admin-linux:
    • ITL: marmarek, piotrbartman
    • External: alimirjamali, k4z4n0v4 (early 2024)
  • qubes-core-qrexec
    • ITL: DemiMarie, marmarek, fepitre, HW42, marmarta
    • External: ben-grande
  • qubes-core-agent-windows:
    • ITL: omeg
  • qubes-core-qubesdb:
    • ITL: omeg, marmarek

Main community contributors: alimirjamali, rustybird, ben-grande, ArrayBolt3 (Whonix)
Other occasional or one-time contributors: zpc0, Euwiiwueir, slayoo, k4z4n0v4, skyzzuu

So, we can say that in the last two years, with a growth of ~20,000 users, only 4 recurring contributors joined the project. Of course, Marmarek is on top of things most of the time.

I’m aware of them, but they are an addition to the Qubes ecosystem. If the project slows down, they will too.

This is the main issue I bring up. If Marmarek leaves the project tomorrow for whatever reason, what will happen to it if he is very hard to replace? It’s not only about Xen and low-level stuff; it’s also about his expertise in reviewing code and fixing necessary things. I think you know this since you interacted with him a lot while implementing the dispvm preload feature.

4 Likes
11

Links can appear if not rendered as links: https://example.com, use “`” on each edge.

This is not 50 most contributed repos but okay. Could say that there are repos that recently had more contributors from externals than from ITL.

Also, the filter high level contributions excludes many contributors from the list. I too didn’t start with a lots of commits or complexity at first of line code or commits also. There have been new contributors.

Your initial claim didn’t have this filter. Which is okay, minds change, but to answer one of your previous questions, there have been more contributors:

https://github.com/QubesOS/qubes-core-admin/graphs/contributors?from=8%2F12%2F2023

Atrate, RandyTheOther, 3hhh, rustybird, Ikubb, krystian-hebel, CertainLach. Just rustybird and 3hhh (that I know) have contributed years prior (and still continue to do so) to QubesOS.

It takes a lot of time to contribute to open source, those who can and want to give, give, even small contributions count.

I think @solene’s answer apply, there are things outside of your/our control and nothing we can do about it. Redundancy is not always possible.

3 Likes
12

Could you list them? Are they core components of Qubes OS that are not fully managed by Marmarek?

That’s the whole point of the filtering. It’s to include recurring contributors who help Qubes OS in general. Users who make one or two small contributions per year are not included.

Let’s take a look.

  • Atrate: Grammar Enhancement → I don’t consider this a significant contribution.
  • RandyTheOther: URL update for documentation → same as before.
  • 3hhh: Fixing storage bug → It’s a bug fix, but it’s a one-time thing. My concern is that there aren’t many recurring contributors. That commit is from July 2024.
  • rustybird: Few fixes here and there → That user commits to other repositories and is one of the recurring contributors I listed already.
  • Ikubb: One-time fix → Commit from October 2023; never committed again.
  • krystian-hebel: Addition for HCL reports → Commit from April 2024. One-time contribution.
  • CertainLach: Typo commit → It fixed a grammatical typo that didn’t change any functional aspect.

As I said before, rustybird is the only one of those who can be considered a long-term, recurring contributor. While 3hhh has made valuable contributions, he is not a recurring contributor. Therefore, we still have a total of 4 main community contributors across nine important repositories.

I never said otherwise, all contributions are welcome. The main point is that Marmarek does most of the work, and there aren’t many contributors to make the job “easier”. One of the most important contributors lately is alimirjamali, who has done a lot of bug fixing and added a few features. I can’t think of anyone else who does that besides him and you, of course.

It’s still important to point out. One major issue that I forgot to mention is that the entire OpenQA testing pipeline relies on physical hardware owned by Marmarek. This means that if Marmarek leaves tomorrow, the entire testing pipeline will disappear, which is a huge issue for Qubes OS.

2 Likes
13

There is absolutely no doubt that Marek is the most important and indispensable person to Qubes OS project. Not only his contributions is the most significant at this point, but also he has the leader personality. He reviews each and every PR with great patience and assures they fit the project (quality-wise and from security perspective). And it should considered that many of those PRs are from 1st time hobby contributors who make common mistakes (I was one of them).

But so what? Even Marek himself has mentioned many times (during last summit) that the project is tiny and small compared to others (Distros like Fedora could have over 2 million users).

On the other-hand, Qubes OS development process is very efficient in my personal view. I have made contributions to other projects (e.g. dnf5). While dnf5 development team could have more members than the entire Qubes OS development team, some of my PRs to dnf5 were left unattended for over 6 months (without positive or negative feedback). Whereas I have seen cases where my draft unfinished PRs to Qubes OS were reviewed and highly valuable advise were given.

I believe that the above claim is not correct. The openQA setup should be owned by ITL and Marek is not even CEO of ITL (he is CTO). Do you have any proof for your claim?

5 Likes
14

I think this is definitely an interesting question to pose, not from a doom and gloom perspective, but how we the community, can do our part to support Marek and the team with all the unique opportunities we have as individuals, be that monetary, motivational, political, or talent. Maintaining a helpful and affable community and the occasional and sincere thank you can do wonders.

This discussion has motivated me to try and do my part, however big or small that may end up being.

P. S. Will anyone be joining for the Qubes Summit later next month?

5 Likes
15

I don’t have a problem with this. I don’t think you understood my main point. Marmarek is the most important part of Qubes OS. He keeps it alive by working on it, sharing his experience and analysis, and ensuring that external contributions follow the system’s correct security philosophy and that the code is in order. But if he stops working on it, what will be left? We’ve talked a lot about contributors on this thread, but none of that matters if the most important person behind the project steps back.

Again, I’m not opposed to this. Qubes OS works fine as it is today, though it’s a bit slow. This is understandable, since it’s a small project with a small team. I’m just pointing out that if marmarek leaves, no one can contribute as much as he do to Qubes OS. As users and contributors of this project, it would be nice to know if the project would continue if he stopped working on it. At first glance, however, it doesn’t seem like it is.

Based on that article written by Marmarek a while ago, the laptops and all the hardware testing for Qubes OS is done somewhere he can access at any time, so I don’t think it’s in a remote location. I could be wrong, but based on the time of the commits and how they are done, that’s how I understand it. I don’t see why all of this would stay remotely while he is the only one working on them. Although the hardware is likely under ITL controls, arranging everything would still take time. It also takes into account that the new person knows how to handle these.

3 Likes
16

I fully understand your point. The same point applies to the similar small to medium sized projects. Take Asahi Linux as an example. Did the project die after Hector Martin resigned due to burn-out? Did Asahi users wipe their drives and did they reinstall MacOS? Or even go back. Did Qubes project die after Joanna handed over the project management to Marek?

Also take into consideration that some of the valuable core team members are currently working on projects which require almost 100% focus. For example, Rafał Wojdyła has been dedicated to QWT. Marmarta is focused on UI/UX. Simon has been focused on the new devices API & S0ix sleep function. Fredric on Qubes Air. Piotr (Bartman) does multiple parts but has focus on update mechanism. Demi was also focused on multiple parts.

In the end, I am asking again. So what? What is the suggestion? Do you mean ITL should do an IPO, find some questionable investors and then Qubes OS project should hire a lot of developers? That would be the path of CentOS and Redhat. It would be somewhat the end of a project of Qubes OS nature.

8 Likes
17

To me, it seems the whole topic’s dealing with the consequences, instead with the root causes.
Though in a veiled manner, I already discussed this a pretty long time ago - I see it as it’s all about the money (as usual, of course).

But I don’t think neither the money is a root cause. How?

Well, I think no case study or business model was done when starting with the project, namely - “what is our focus group”. Or, it was poorly done.

If it was “an average user” then you don’t advertise it with Edward Snowden (almost only with). That thing scares average user. In addition, and I firmly believe in this - unnecessary mystifying Qubes. My kids, for example, started with Qubes, and “Windows is so hard for them”. You know what I mean? And the fact caused a small number of users, meaning small donation base caused by the small focus group. So, it’s not about the “small team”.

The other focus group could be corporate use of Qubes. Well for that, most probably you have to have “a garage” and a 3-letter agency constantly pointing to the “garage” one way or another. Or, again, you did a bad PR, left with the small tier of partners, so simply there’s no room to include serious developers.

Not to miss to include the security issue when considering new team members, taking into account 3-letter agencies.

But, as long as the partners donate at least as they do up to this point, I am sure @marmarek will fully dedicate himself to the project. Even when not, Qubes is already recognized to be so important, so someone will continue with it.

Qubes is not a project developed by “non-westerners” that you can almost for sure expect they’ll abandon it at some point, nor it’s a “just another version of Linux” on distrowatch. That’s more than promising for Qubes. And comforting.

1 Like
18

hacking

I mean academic discipline. Are you saying that Joanna or Marek have studied “hacking” in some university?

1 Like
19

No, I think they learn vulnerabilities of different systems and this way they know in-depth things about different systems and can write this papers/articles. This knowledge come not from academic discipline, but from own research/learning

1 Like
20

Warsaw University of Technology; Master’s Degree in Computer Science

2 Likes