There are a lot of various points to support contracts. Support contracts are not “fix any bug” or “implement any feature”, but…
- With a support contract, there are SLAs to respond to incidents / bugs within a timely manner, and
- You have a clear escalation path to talk to engineers, rather than customer service, and
- While you can’t dictate what features / bugs will get fixed, you do have some weight for prioritization.
If you have no support contract, then you may not be able to talk to engineers at all, your bug reports may get completely ignored (not even looked at), etc.
Yeah but if the response to your bug report is "WONTFIX", it doesn't much matter if you got that reply in a timely manner. It still does you absolutely no good.
I don’t understand what kind of point you’re making here.
Are you saying that support contracts are completely worthless because some bugs are closed WONTFIX?
B2B generally does not run on the “let’s screw our customers as much as possible” model. Of course, some do—companies like IBM and Oracle are famously extractive, and cloud providers are trying their best to bait you into getting locked into their cloud.
But in a typical B2B scenario, the support contract is the entry price for having real people read your bug reports and respond in a timely fashion. That’s the starting point, and from there, the bug will get fixed, or you’ll get connected to a “customer support engineer” or someone that will tell you that you’re using the product wrong, or you’ll be given a workaround. Without the support contract, you don’t get the workarounds, you don’t get the fixes, and you don’t get the contact with engineers. You just get to figure it out on your own. Yeah, a percentage of bugs get closed WONTFIX. That’s normal. Yeah, the contract may only require a response and not a fix. The actual practice is that you get some bugs fixed, and some not, and that’s a lot better than your bug reports going straight into the trash.
In my experience (not with IBM), support contracts get you issues resolved. You get a certain number of incidents per contract, and each one gets resolved. You ask for a feature or bug fix, and they implement it. That’s what you are paying for.
Now Red Hat would have no obligation to upstream or maintain the patch, even to projects they own. But you ask for a big fix under a support contract, they should fix the bug. Even if it’s just a patch for that one customer only.
To be the provider of a support contract and then just turn around and say “nah, won’t fix” in response to an official customer service contract request… I’ve never, ever heard of that in my professional career.
Sometimes customers come up with feature requests that are reasonable in the surface but would cost millions to implement and maintain. In that case, workarounds are one way to resolve the issue.
> Even if it’s just a patch for that one customer only.
Red Hat does not do one-off patches. If it's fixed in the product, it's fixed for everyone (including upstream).
> In that case, workarounds are one way to resolve the issue.
Yea I always check "why" and if the feature request is not already reasonably well motivated, I'll reach out to the customer and ask.
In my experience it's quite frequent a non-trivial feature or change request can be solved as well if not better by a simple, but different change instead.
Alternatively it allows me to see that three customers are asking for nearly the same thing, even though the feature requests make them sound quite different.
For Red Hat, there are bugs and there are customer cases. The two are not the same, but they are linked internally. Customer cases don't deal with "X functionality doesn't work in libvirt", but rather a higher level issue that the customer can't resolve due to the underlying bug. Here a workaround the customer can live with is a perfectly acceptable solution.
In my time I was there I never saw a bug closed as WONTFIX unless the customer case was resolved in a satisfactory manner. Red Hat people are very aware who's paying the bills. I have seen badly managed escalations, but I've never seen anyone taking customer problems lightly. However, bugs that have no customer case attached to them carry very little weight unless an engineer, a PM, etc says that this is really bad and will cause problems in the future.
This is part of where the disconnect comes from. Red Hat prides itself in being an open source company, but it is first and foremost a customer-oriented company. Sure, often individual people will take time they have left and go fix something for the community, but if it's something more involved, it will need PM and management support. Benefiting from and also providing their customers with open source is simply part of the model that has worked for Red Hat, but nobody should be under the illusion that this is done for the greater good. Red Hat is a company and companies serve the purpose of making money for their shareholders. If this happens to align with the interests of the open source community, that's awesome, but will not always be the case. Over the past few years there have been numerous instances of that unfortunate reality.
Without knowing the specifics about libvirt's funding, if a project needs to be truly community-driven, the community must come up with a model that doesn't involve Red Hat paying a large portion of the salaries of the people involved, or it will be subject to Red Hat's business interests.
