Upstart [as an init system]: no longer in active development, moving to systemd.
bzr: no longer in active development.
Landscape: very well established.
Mir: not really a wide-reaching project (AFAICT). It fits in between existing well-defined APIs (a handful of toolkits on one side, and hardware on the other), and can be implemented fairly independently by a separate team.
That doesn't leave very much to "spread themselves so thin". It comes down to spreading over two main areas: client devices, and cloud.
With client devices, it makes sense to cover multiple form factors with a single code base. That's Unity 8 across phones, tablets, etc. That's not spreading out to me; it's just being smart about code re-use.
With cloud, it makes sense to look at Openstack on the host and transactional updates on the guest. That's hardly "thin".
Dropping bzr from active development is surely an illustration of how "spreading themselves so thin" exactly what Canonical is not doing?
Naming a pile of buzzwords doesn't by itself provide any evidence of your claim. Especially when some of these are flat out wrong because they (quite publicly) aren't under active development any more.
> seeing what sticks
Upstart remains excellent and nothing else existed at the time. It preceded systemd by a large margin. bzr is much the same. It pre-dates git.
In [1], Jelmer Vernooij writes: "Some people claimed Bazaar did not have many community contributions, and was entirely developed inside of Canonical's walled garden. The irony of that was that while it is true that a large part of Bazaar was written by Canonical employees, that was mostly because Canonical had been hiring people who were contributing to Bazaar - most of which would then ended up working on other code inside of Canonical."
It isn't so much that Canonical conceives of a project and goes off on its own direction; more that Canonical ends up hiring community members who are already contributing, who then make decisions they would have made anyway but with Canonical hats on, and larger community less aware of the details attribute this to some kind of secret internal Canonical policy decision.
I think that neither of these were about "seeing what sticks", since at the time they were conceived there weren't any other clear alternatives. And nothing else in your list is yet unstuck, so that hardly demonstrates that this is some kind of policy here.
Disclosure: I work for Canonical (but here I speak for myself, not for Canonical).
While I see what you're saying, I've never seen a company the size of Canonical attempt to respond to every single new thing in the marketplace the way it does:
Smartphones? Ubuntu Phone. Also Ubuntu for Android
Smart TV boxes? Ubuntu TV
AWS? OpenStack
CoreOS? Ubuntu Core
DVCS? Bzr
Windows 8 Metro mode? Unity
The problem is most of these don't do their jobs well. I think they'd be much much better off focusing on one or two rather than attacking on so many fronts. I still use Ubuntu on the server but everyone I know has moved off ubuntu on desktop for OS X, mainly because of how slowly Unity has improved.
As a 10 year long Ubuntu user for servers, desktop, cloud etc I agree with both your comments. Ubuntu/canonical over announces and under delivers recently to the level of appearing not believable. I m still waiting for my Ubuntu phone, Ubuntu for Android etc, and had to delete my Ubuntu one.
> But doesn't it still need to be supported for 5 more years because of 14.04 LTS?
Sure it does. I'm not familiar with the details, but I believe that Upstart development was primarily one person prior to the decision to switch to systemd. Supporting existing stable releases surely requires far less. So it's hardly an onerous burden.
There is also the question of supporting packages that integrate with Upstart (eg. via Upstart init script), so this involves some more work as we'll be supporting packages that use Upstart (in 14.04) as well as systemd (from Vivid, if we complete the switch this cycle).
But I still don't think it's so much work as to be considered a contributing factor in "spreading themselves so thin". It's not even close.
> In addition, it's still the default for ChromeOS and not much interest has been expressed in a switch. Anything new on that frontier?
No idea, sorry. Not my department. I know that Upstart is pretty solid though, with particularly high quality code and comprehensive test coverage. There aren't any major feature gaps either, apart from extra new stuff that you may or may not want. So I don't see much of a problem in continuing to use it for a while yet. I expect it to bitrot slower than an average project.
bzr: no longer in active development.
Landscape: very well established.
Mir: not really a wide-reaching project (AFAICT). It fits in between existing well-defined APIs (a handful of toolkits on one side, and hardware on the other), and can be implemented fairly independently by a separate team.
That doesn't leave very much to "spread themselves so thin". It comes down to spreading over two main areas: client devices, and cloud.
With client devices, it makes sense to cover multiple form factors with a single code base. That's Unity 8 across phones, tablets, etc. That's not spreading out to me; it's just being smart about code re-use.
With cloud, it makes sense to look at Openstack on the host and transactional updates on the guest. That's hardly "thin".
Dropping bzr from active development is surely an illustration of how "spreading themselves so thin" exactly what Canonical is not doing?
Naming a pile of buzzwords doesn't by itself provide any evidence of your claim. Especially when some of these are flat out wrong because they (quite publicly) aren't under active development any more.
> seeing what sticks
Upstart remains excellent and nothing else existed at the time. It preceded systemd by a large margin. bzr is much the same. It pre-dates git.
In [1], Jelmer Vernooij writes: "Some people claimed Bazaar did not have many community contributions, and was entirely developed inside of Canonical's walled garden. The irony of that was that while it is true that a large part of Bazaar was written by Canonical employees, that was mostly because Canonical had been hiring people who were contributing to Bazaar - most of which would then ended up working on other code inside of Canonical."
It isn't so much that Canonical conceives of a project and goes off on its own direction; more that Canonical ends up hiring community members who are already contributing, who then make decisions they would have made anyway but with Canonical hats on, and larger community less aware of the details attribute this to some kind of secret internal Canonical policy decision.
I think that neither of these were about "seeing what sticks", since at the time they were conceived there weren't any other clear alternatives. And nothing else in your list is yet unstuck, so that hardly demonstrates that this is some kind of policy here.
Disclosure: I work for Canonical (but here I speak for myself, not for Canonical).
[1]: https://www.stationary-traveller.eu/pages/bzr-a-retrospectiv...