My vision for Open Source pro support | Hacker News Reader

My vision for Open Source pro support

xcp-ng.org

23 pointsplam50371114 comments

It's worth noting that the fixed-price unlimited support only works if you are charging north of $1000 per year. This limits your users to those who actually know what they are doing, and value their and your time.

Try doing the same for a $100/year product, and you will get very quickly overwhelmed by freelancers trying to push 100 different issues from their customers on you. And reasoning with them won't work because they have all day to try rephrasing the same problem in 10 different ways, hoping it will get them to a different agent.

Needless to say, the most entitled people will be the free tier users believing that the sole fact of them paying attention to your product is enough for you do drop all what you were doing and start rewriting it to their vision.

This. This is VERY true. Pricing is capital if you want to have some respect. The worst "customers" are often those paying nothing or the cheapest price.

Really nice that they adapt the proxmox model for support, it's worked excellent for us in our labs. It would have been nice to have emergency tickets as an option though, even if it costs hundreds per ticket. Because small businesses often can't afford the 1.2K commitment per machine, when they already pay for clusters of dedicated servers. Even a small cluster of 5 machines is 6K, a lot of dough for a small company..

That's why there's a smaller plan (XCP-ng Standard, it's only half the price, for 5 machines it will be 3K).

But yeah, smaller infrastructure pricing is hard, because people tend to have less knowledge and requesting more assistance, so the cost is even higher on the company's side.

edit: also I don't remember trying to "adapt" or copy Proxmox pricing, since we're always convinced since the start to not make Open Core but true Open Source! And I respect Proxmox a lot for doing the same :)

Yes, I saw the smaller pricing, the problem is that businesses often prefer a metered approach, but I also understand that subscription support makes it easier to afford having support personel on a salary, which is much harder when it's on-demand tickets.

I think many don't subscribe at all, or subscribe when they actually need the tickets. If they could pre-purchase a set of tickets for say, 200€-400€ per ticket (2x-4x the lowest subscription), I think it would be a hit, even if they never use those tickets, they could buy them when they can afford to buy them and keep them as a sort of assurance for future incidents.

That sort of model has worked extremely well in the SaaS startup world, with so called "lifetime deals". You buy a set of resources that don't expire and can consume them over a lifetime (of the company or product).

But if you buy only for support when you need, it defeats a bit the purpose of also paying the project to get security updates and new features (and more QA). And to get enough money inside, this needs to get TONS of customers. Check at Proxmox: they have a revenue around 2+ millions EUR with… 15k customers. We can't afford such a low revenue per customer, because having a big customer base takes time.

But this is the usual "issue" with Open Source model. A lot of companies selected Open Core and decided that some feature were only relevant for enterprise use case (Gitlab, Mattermost and such). Which I think works OK commercially speaking, but I don't like it regarding Open Source philosophy.

The problem is more on the revenue sources/use cases for proxmox, shared hosting and cheap containers from turnkeylinux.

If the margins and use cases are not enterprise enough, there’s not enough margins to pay for licenses/support even if you wanted to.

I think that’s why rancher/docker is more successful commercially, it enables configuration and automation instead of management and deployments.

I agree on the automation part, that's an important objective in our backlog (like we did with Terraform plugin etc.)

Seems like a neat project, but I was turned off by how they handle Xen Orchestra. Feels weird to have an open source project, but then try and push a separate proprietary product to install it that also gates features between payment tiers. Found a community maintained installer/upgrade tool on GitHub that gets you everything, but guessing they don't officially want to make it easy so they can make more sales.

Xen Orchestra is not proprietary at all (fully aGPLv3!). It's just a different approach, mainly for historical reasons, when it was only on top of Citrix Hypervisor/XenServer.

So the concept is that you can build it yourself from Github with all features (see https://xen-orchestra.com/docs/installation.html#from-the-so...) OR deploy a turnkey VM with everything pre-installed (targeting companies) with support on it. Yes, the turnkey VM is having tiers, but it's logical since you have various perimeters in terms of supported features. And it's flat priced :)

Obviously, the turnkey VM (called XOA, Xen Orchestra virtual Appliance) is only meant for businesses and not individuals.

I hope it's more clear.

Yeah, but feels like there's a conflict of interest. Xen Orchestra is made more difficult to deploy than it needs to be, since it'd reduce sales of XOA if it was easy. It's also not obvious on https://xen-orchestra.com that it is actually open source, seems like it's intentionally made confusing to get you to use XOA instead.

How difficult is to make a `yarn && yarn build`?

Also this is important to have a validated/tested environment to deploy your code (that's why a VM is really handy).

Regarding XO website, it was again for historical reasons when we sold mostly to Citrix (where the words "open source" was feared by those customers).

Now we got plans to have a better split between org projects and the whole "stack" to be able to compete with VMware (eg more commercial stuff on Vates website).

Again, most of what you see now is in transition before a clearer model since we have the whole stack control :)

> How difficult is to make a `yarn && yarn build`?

Not difficult, but not necessary either. I could also figure out how to build the XCP-ng ISO myself, but I think everybody uses the builds you provide instead.

> Again, most of what you see now is in transition before a clearer model since we have the whole stack control :)

Good to hear, looking forward to see what you guys come up with.

I understand your point. However, anything else might require time to maintain it (a script, a container, a VM, whatever you want: people will expect it to work obviously, so this needs time/effort to test it, unlike a simple documentation). Do we want to maintain that? I'm not sure due to the huge backlog and higher priorities.

But I'm eager to have more resources to change that in the future :) (all things considered, an official "community" container might be the easiest path, but we'd like to have maintainers outside Vates)

Reply on news.ycombinator.com