Next thing for Ubuntu to learn
bugs.launchpad.net
bugs.launchpad.net
As a matter of fact, I know of someone that worked in one of the Ubuntu teams, when his work became well known, and someone at Red Hat discovered that he was not paid they just hired him.
EDIT: I do not see this as a problem though, I watch closely the Dragonfly BSD project and as far as I know the majority of the developers are not paid to contribute with the project.
And it's not even that much of a problem for Ubuntu's end users, since Ubuntu's biggest problem is making meaningful contributions upstream.
He was hired by Google, and his point is that if Ubuntu is going to make a distribution, they need to have the engineers available to solve it, instead of just bugging actual engineers over and over again, which I see is reasonable given they sell support.
https://bugs.edge.launchpad.net/ubuntu/+source/linux/+bug/31...
and especially:
http://lwn.net/Articles/322823/
Whether that has anything to do with this particular sniping incident, I obviously have no knowledge. But I think it's an important piece of context.
Edit: after reading the whole bug report, it's also important to point out that the issue at hand here is a real and still-unfixed but in ext4 that has been worked around for Lucid. Ted's appeal that no one from Fedora has complained seems a little shallow given that there's a 7-line shell script at the top of the bug to exercise it.
Really, this doesn't seem warranted here. I know the kernel team doesn't like Canonical. But I don't see what they did wrong here other than pick a different workaround than the one Ted suggested.
"I've already done Ubuntu a huge favor by spending ten minutes to do a quickie investigation. Ubuntu needs to learn that it can't rely on upstream developers to jump through flaming hoops on short notice before a LTS release deadline as a cost-saving mechanism to avoid hiring their own senior kernel engineers."
Though I was particularly put off by the bit at the bottom, where he says that even if Ubuntu does hire and train up people to work on upstream kernel or filesystem issues Google's deep pockets mean they will just poach them once they are trained up.
Hopefully at Google they'll actually work on the upstream Linux rather than the Android fork.
(Probably other things too, but I suspect they hired him more because of their infrastructure requirements than for Android)
And to be fair, he said "Red Hat or Google" will hire them. He was implying (saying, actually) that Canonical don't pay their engineers enough, not that Red Hat or Google pay exceptionally.
I might fix my girlfriend's computer for free, but I make sure to bill everyone else.
I assume you don't act like an asshole no matter who you are helping. I'd go further and assume that even when you turn down people asking for your help, and suggest they might want to hire someone instead, you're still not an asshole to them.
Anyone who has watched Canonical since Hardy Heron (also an LTS release) knows that the company has deep and systemic problems. I wouldn't be surprised if the tone of Ted's response is also a result of past history with them of the sort that's illustrated by this message.
I might go even further and say that if you're as serious a member of the Linux kernel development community as Ted is, you might be rather concerned about Canonical's practices and how they're likely turning off a lot of would be Linux users.
Going back to Hardy Heron, if you were using a machine with a Broadcom 43xx wireless card, you would have been rather upset for that to have stopped working. Or for HH to frequently crash without saying anything (even Windows gives you a BSOD).
What I'm saying is that while the objective is obviously good, the execution appears to be so bad than in combination with that objective it may well be a disaster.
If what Ted is saying is true about them not paying anyone (who's good) enough to retain them nor hiring a few serious kernel hackers, then that pretty much makes the case, wouldn't you say?
I.e. given that they take a snapshot of Debian unstable and then furiously try to make it work in 6 months.
Another bad and telling sign is that ship dates are more important than quality, and that will also lose them good people. I would not want Canonical on my resume for very long after 6 months before the release of Hardy Heron and I have found such work places to be utterly depressing and demotivating.
A little digging in the package repositories showed, that 2.5% of lynx packages contain svn, git or cvs in their version number. This means, they were either a stable release that was patched with something from the repo or even a complete snapshot from the repo. Debian, for comparison, has only half as many packages with that criteria.
Canonical does not make billions unlike Google and even Red Hat. It was funded by a guy who gave money from his own pocket and a lot of it and managed to make Linux popular, so kudos to him and I'm sure they'll get lots of kernel developers if they ever manage to be very profitable.
See elsewhere in this topic where I addressed how their low quality releases starting with Hardy Heron may in fact be hurting Linux. If true, that and the resulting backlash against Canonical would have it end up in even worse shape financially and therefore less able to hire hackers of the level required. I.e. kernel hackers like Ted who keep fielding their requests for help and who are acutely aware of their lack of quality in their releases might be particularly unmoved by the "we're bringing Linux to the masses" argument.
Who said it was his problem?
Who said they want those? They just don't have the money to pay for such devs, they know it, and that's that. Also who said it was his responsibility? Sounds like a big straw man to me.