On 15/12/16 23:46, je wrote:

> I do not believe that developing a commercial operating system based on an
    > open source foundation will pay off on a long run.

    Is there a specific reason you think it will not? Just curious.

1. Selling a license provides a one time payment. Even if you are able to sell 100_000 licenses for 40 you would earn 4_000_000, but the same companies will not buy a license the year after that. Which means no constant income for the long run.

Most companies will stick with one version of the product till they really have a reason to upgrade. Because, the costs for upgrading are actually higher than the costs of the license and upgrades involve the risk of causing disruption (problems during the upgrade, which blocks employees from getting their work done. Which again means I loose money).
With other words Qubes OS will be stuck with one version for years.

2. The simple question is how can you sell a product which contains mostly GPL licensed code (Xen, Linux Kernel)
which everybody can download and compile for free?

RHEL sells support subscriptions. They offer support (10 years backporting, customer support etc.) and most important they offer a platform for other business software. The work RedHat constantly invests in their RHEL can not be easily replicated and that is the reason why CentOS is not a competitor.

3. Security is a process and not a product. As an enterprise customer I want to have constant updates and upgrades, security bulletins and other security information. I want to know if DirtyCOW, hardbleed or other security flaws affect my business if I use Qubes OS or not?

Furthermore, I believe that the Qubes OS team and ITL does not understand what Qubes OS could offer on an enterprise level.
I am working with IT strategy myself. Enterprise needs are clearly completely different from SMB, etc., so in that sense we are talking about two entirely different strategies and support models. I think Qubes should pursue both, but with two distinctly different teams in charge, with the suitable understanding of each area.

As the whole industry (and society at large) continues to mature into various ways of readiiness for Open-Source things, I am quite sure that we will see a growing market among SMB's that are willing to pay for support and related peace-of-mind aspects even if it is possible to compile everything oneself. It is worth paying to "delegate" both such manual work and to avoid keeping up on the related competence race.

A license is one thing, perhaps even limited in time, but an accompanying support agreement is yet another. Both are needed, IMO.

There is also a middle ground here - Take for example me:
I would like to offer entry-level services to clients, who all will pay the license + pay for my services. In turn, I want to be a professional-level client of Qubes support, so that I can get their backup when there is something I run into which I cannot answer or solve properly for my entry-level clientele. So I would be willing to pay a professional support membership of some sorts.

I strongly believe memberships-based support services (premium communities) is a good business model for this, atop of whatever licensing scheme one may have.

You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
For more options, visit https://groups.google.com/d/optout.

Reply via email to