[chr15p]

> Mir, Unity, now Snap. Ubuntu has a track record of wanting to go it alone.

This. Also bzr. They seem to want to control their projects completely and so even when they have good tech they lose out to more open, community developed, equivalents that build wide engagement and momentum.

I honestly don't understand it, you would have thought they would have learned by now that they don't have the engineering resources to do everything by themselves.

Compare that to Red Hat who always try (and sometimes even succeed!) at developing projects with the community and are far more successful at getting their projects adopted (I know people don't like them, but you cant deny they are effective at it)

[toyg]

> I honestly don't understand it, you would have thought they would have learned by now

The simple answer is that the company culture really, really wants to be "the Apple of Linux", with all that it entails. Whereas RedHat wants to be the Linux of Linux, they've learnt how the opensource game really works and they play it every day.

[necovek]

Bzr is a great counter example.

Bzr "lost" because git had GitHub, whereas Launchpad was one too many things and slow to optimize for modern sensibilities.

(And Linux used a different VCS before git, so that didn't matter in adoption)

Imagine a world without GitHub, and I don't think git would be our go-to VCS. Though maybe not even Baazaar, but there are things like Mercurial too.

[account42]

Git already had momentum before GitHub became popular. And yes, it is absolutely Linux and other high-profile projects that ensured its success in the OSS world. Claiming that Linux having used a different VCS before git means that Linux's use of git doesn't matter is really odd when git was developed for the Linux project.

[necovek]

It sure had momentum. As did a bunch of other distributed VCSes. If you were a party to voting what VCS to switch to for some of those high-profile projects, I'd very much like to hear about it.

In GNOME, a decision was delayed and bzr and git were pretty evenly matched.

Linux has previously used BitKeeper, but that didn't make it "win out", just like it didn't do so for Git. Sure, it wouldn't have existed if there wasn't a need for Linux.

I am only pointing out that it was GitHub that helped popularize arguably the worst UX among DVCSes: I don't hear people say "your free software contributions portfolio" — they'll just say "your GitHub profile".

[mindajar]

bzr lost because it was poorly-architected, infuriatingly slow, and kept changing its repository storage format trying (and failing) to narrow the gap with Mercurial and Git performance. Or, at least that's why I gave up on it, well before GitHub really took off and crushed the remaining competition.

For my own sanity I began avoiding Canonical's software years ago, but to me they always built stuff with shiny UI that demoed well but with performance seemingly a distant afterthought. Their software aspirations always seemed much larger than the engineering resources/chops/time they were willing to invest.

[necovek]

Sure, that's a fair point as well (though bzr came out of GNU arch, which didn't originate at Canonical, and it was finally redesigned into something good at Canonical — not a knock on arch either, it was simply early).

The question then becomes: why not Mercurial which still had a better UX than git itself?

My point is that git won because of GitHub, despite lots of suckiness that remains to this day (it obviously has good things as well).

[rickydroll]

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.

[hotpotamus]

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.

[chr15p]

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.

[rickydroll]

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.

[toyg]

> they are rejected just because they are from canonical.

Or rather because they're proprietary, often closed-source, like Snap server.

[commoner]

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.

[account42]

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.