On Fri, Dec 16, 2016 at 1:06 PM, Leeteqxv <teqleez...@leeteq.com> wrote:
> 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. > > Agree with that. On the license side also a mixed scheme may be interesting. For example there is an obvious need of some development directed to the very special enterprise needs. This additional enterprise development may be kept closed-source for a limited time, perhaps 5 years rather than the international 50 years of copyright law. During this limited time this additional software may be available under a non-disclosure agreement for the licensee to check it or even compile it. Best fran > -- > 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/ms > gid/qubes-users/fe5ecfd0-8869-2c19-6309-e870f8377eef%40leeteq.com. > > For more options, visit https://groups.google.com/d/optout. > -- 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/CAPzH-qDP3QAV6-gYRbbh3bQ5a%2B1CA3uUXgajV9FAv5S5sKVD0A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
