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
https://groups.google.com/d/msgid/qubes-users/fe5ecfd0-8869-2c19-6309-e870f8377eef%40leeteq.com.
For more options, visit https://groups.google.com/d/optout.
