It’s an upfront design that covers the core concepts all together, not bolting on one feature after another. Someone familiar with the project history might be able to say whether it’s all been smooth or they’ve had to make major corrections to the initial design, but it looks like it’s been solid. I reckon in a lot of projects half the staffing is compensating for poor or postponed early design decisions, because reasons.
I thought this would be the main concern! It’s the combination of being able to lose a high proportion of the project through one or two incidents or individual decisions, and not having much experience seeing how easily Qubes can find and onboard new people. I really like the emeritus page for this reason.
As long as development continues unabated, I see no cause for concern, regardless of how many people are actively working on Qubes OS at any given time.
My Jitsi Meet instance works just fine on my Librem 14, although I do not know the hardware requirements for other clients to join. In any case, I can always reconfigure the video resolution and bitrate if needed.
Do donors get personalized support or special feature requests?
We regret that we cannot provide personalized support to donors or implement specific features based on donations. In both cases, the reason is that our resources are limited. If we were to allocate these limited resources to providing support to individual donors and implemented their requested features, we wouldn’t have enough resources left over to make timely progress on our core projects, and the long-term sustainability of Qubes would suffer.
If I am not mistaken, I remember times, when full version of QWT was expected to be paid or something. Qubes OS used KDE back then. Like the OS is free, while binary QWT packages for Windows VMs should be paid for. Am I right?
In the past, Qubes Windows Tools were mostly closed-source as its development was focused on business use. However we have decided that it is better to provide the full functionality of Qubes for all users, so we’re doing just that – please enjoy Qubes Windows Tools with the same confidence you use Qubes OS! [1]
Definitely. More eyes on the code = more better. Barrier to entry might mean eventually nobody wants to touch the legacy code? I’d love to see nixos-level of community participation
If it’s so hard to enter, one has to wonder if the project will survive even one of the current main devs now having an accident or leaving for any reason…
I dont understand how having a small core team restricts the ability for
“more eyes on the code”. The code is open source,and open to review by
any one. In fact there is currently a program of code review underway
in the community.
The core team does not provide any barrier to entry, in terms of making
a contribution to Qubes. Any one is welcome to review code, suggest
enhancements, fix bugs, propose PRs, update docs, etc etc.
Given the recent activity at Nixos I think that an unfortunate
comparison.
[quote]
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
I dont understand how having a small core team restricts the ability for
“more eyes on the code”. The code is open source,and open to review by
any one.
Perhaps the important factor is not how many but what eyes are on the code.
In fact there is currently a program of code review underway in the community.
Could you share more details?
Any one is welcome to review code, suggest enhancements, fix bugs, propose PRs, update docs, etc etc.
I have suggested one enhancement (including actual code) in qubes-devel on 27.April. How long does it normally take to receive a reply?
Those are all some of the many things that I have been working on (in my spare time, unfortunately) over the last couple of years.
I still believe that Qubes OS has tremendous potential in the corporate environment, if only it can be remotely controlled in a way that both meets the needs of the company, and doesn’t compromise on the values that Qubes OS stands for.
Unfortunately it’s a slow and surprisingly costly (you have to test on bare metal, VMs are not the same) process, but I am making some progress.
——-
I agree that turnkey solutions native to Qubes OS (settings panels, config scripts, GUI GUI GUI, etc.) to perform basic functions like “create a template, install XYZ packages into it” would go a long way to breaking down the barriers that currently exist.
GUIX had 60 and … Money talks, bullshit walks. Why did the Green Party in Germany switch Munchen from Debian to Linux? And so on… The tyranny of evil money printers who want to keep things one way. They can while you can’t… old story.
That (declined) proposal envisaged developers from Debian/Fedora/
(perhaps community distributions like Arch,Ubuntu,Whonix,etc - why
not?) having a special path to getting commit access to the Qubes
code base.
It was based on the feeling that such distributions have established trust
and vetting procedures. I think this is wholly mistaken. The discussion
there is instructive.
I never presume to speak for the Qubes team.
When I comment in the Forum I speak for myself.
