Another way to look at this situation is that canonical comes up with innovative solutions that are reasonably well engineered out of the box but they are rejected just because they are from canonical.
I'm struggling to find a way to characterize the difference between Red Hat/IBM and canonical's approach to the community. The most succinct I can come up with is that canonical releases projects and assumes that they are the one responsible for their creation., Red Hat releases rough ideas and code. There also seems to be a heavy political/disinformation campaign going on tearing down any solutions by canonical.
In either case, none of us can resolve the conflict. It's a pissing contest between canonical and IBM/Red Hat. I will keep choosing solutions that let me get my job done and get paid which is all that matters.
At an old job, we used probably hundreds of hardware and software vendors. I never had to deal with any of them directly, but I often spoke with those who did. There were complaints about all of them I'm sure, but the only ones that inspired bitch sessions over a drink were Oracle and Canonical. I'm told that both were just thoroughly unpleasant to deal with.
I don't think it is a pissing context between them, they can both happily exist in the same world, it just interesting to see the difference in approach and try and figure out why one seems more successful than the other.
I think you're right that Canonical creates and releases projects and assumes they are in charge of them, but I disagree about Red Hat (honestly not sure what you mean by "rough ideas and code"), I think they tend to see whats already out there and then throw their weight behind that, then only if there isn't do they create their own and even then they are more open about how the project runs. That difference means Red Hat gets more momentum behind its projects, and that is what counts. (of course RH can throw more engineers at stuff as well, and that also helps a lot)
Its not some sort of conspiracy, nothing Canonical has ever done has had the same amount of hate as systemd has, its just a difference in approach.
What I mean by rough idea and code is simple. Is a project something complete you can take and just use or is it a bag of parts. xcp-ng is a take it and use it project. KVM is a bag of parts.
My experience with Red Hat is that it's frequently IKEA level assembly required. Canonical projects tend to be read the docs and just use it. Although there are some exceptions. For example a couple of years ago, cloud-init was not documented well enough for my taste. Took a second look just now and found new documentation that may revise my opinion.
Exactly. Canonical's Snap Store service is closed source and the Snap client is designed to only interface with Canonical's proprietary service. It's not "disinformation" to point out that Snap is a locked-down product controlled by Canonical, while most other packaging solutions for Linux are fully free and open source on both the client and server side. Canonical's one-sided approach to interacting with the Linux community will only encourage Linux users to reject Ubuntu and adopt distros with more sensible defaults.
And even if they are open source, the development is not (initial development often closed completely, later development requiring CLAs) and the projects only care about Canonical's use of them to the point where even building them on other distros is often far from trivial.
I'm struggling to find a way to characterize the difference between Red Hat/IBM and canonical's approach to the community. The most succinct I can come up with is that canonical releases projects and assumes that they are the one responsible for their creation., Red Hat releases rough ideas and code. There also seems to be a heavy political/disinformation campaign going on tearing down any solutions by canonical.
In either case, none of us can resolve the conflict. It's a pissing contest between canonical and IBM/Red Hat. I will keep choosing solutions that let me get my job done and get paid which is all that matters.