I think I have a very accurate picture as to what Canonical pays employees do. The majority of Canonical developers are paid to write private web services application code behind closed doors. But if you disagree with that feel free to prove me wrong. See if you can get people talking about UbuntuOne project. The UbuntuOne hacker team is larger than the Desktop Experience team according to launchpad…both internal Canonical teams to my understanding…hmmm.

Please start writing articles about the open technical advancements that Canonical is driving as the technical lead for Ubuntu. Jockey, checkbox, bzr, upstart.. all reasonably good fodder for articles as Canonical employees are part of the core development team for those projects. Upstart is a very interesting story because if you look closely you’ll see that a significant amount of work to integrate it with D-Bus was done by a Red Hat employee in the 0.5 upstart timeframe. Upstart is a good coop-etition story. Too bad its not sexy enough to get the attention from the blogosphere. Ubuntu is still using it in backwards compatible SysVinit mode so even in Jaunty its not actually taking advantage of the event based approach:
https://bugs.launchpad.net/ubuntu/+source/upstart/+bug/338648
Isn’t that worth talking about? Multiple releases of Ubuntu later and Upstart features arent being used beyond basic SysVinit compatibility.

Or if you want something a little more sensational, go ahead and write about the future of notify-osd and libindicate which speaks to whether Canonical has done enough to discuss their place as a potential part of the Gnome Desktop of the future.

http://bugzilla.gnome.org/show_bug.cgi?id=557647#c16

Canonical does not have the manpower to build and maintain a highly customized GNOME desktop for any significant length of time. That’s pretty clear from looking at how they handle existing GNOME desktop bug reports.

https://bugs.launchpad.net/ubuntu/+source/gnome-session/+bug/249373

The more customization patching Canonical does downstream of GNOME the heavier the burden is on Canonical to actually fix things on their own. The fact that they are experimenting with a change in how notifications work inside an Ubuntu release which deeply impacts functionality across a wide number of applications without being on the roadmap for upstream GNOME should be a concern for you as an Ubuntu supporter. Even if the feature is great, and its wildly popular, does Canonical have the manpower to keep the new notification concept maintained as a set of downstream patches against applications?

Or on the other hand maybe the notification work Canonical is investing developer time in really isn’t really compelling to you. If the most compelling and interesting things on the horizon for linux users that you can think to write about are technical advancements that Canonical isn’t playing a significant role in you need to do a much better job of point out who is actually leading that effort.

I also find it ironic that Shuttleworth says that kernel work isn’t that important to Ubuntu users.. like his mom (see the recent video interview). And yet here you are talking about kernel level driver features as one of the most important things coming up for Ubuntu. That is a significant mismatch in world views. Do you consider yourself part of the target audience for Ubuntu? I’m not sure Shuttleworth does.

Articles like the one you have written above put the emphasis on the wrong part of the equation. The hard work..the work that need to be lifted up..is not the consumption of the functionality by integrators like Canonical. The hard work is the actual development of the functionality. If you are going to write articles about feature development then give credit where credit is due. Make the effort to actually talk to a developer..any developer..who is involved in doing the work and give them a chance to be quoted in the article with their perspective. Fair’s fair.

-jef

It still is, have you looked at the Ubuntuforums message boards at all recently. My current laptop still won’t do wireless or audio properly in 8.10 or 9.04 after 60-80 hours spent on the problems. This article made me laugh. It illustrates Linux/Ubuntu’s biggest issue, tunnel visioned developers spending a lot of man hours adding obscure unnecessary capabilities when the common required ones still don’t work properly or at all. Why would I replace my $60.00 wireless router that works just fine with a $600 laptop that still doesn’t? Absurd!

Well, of course. Canonical has somewhere in the region of 5% the revenue of RedHat and it isn’t profitable yet. What do you expect them to do? Invest money that they don’t have or has to come out of Shuttleworth’s pocket? They can only do so much of this.

But your post points to something interesting, i.e. the superiority of open source in bringing benefit to all its users.

As for Red Hat, although I’ve been critical on this site of its professed disengagement from the desktop-Linux market, I do agree that it makes plenty of useful contributions to the free-software community. I think Canonical also does more than you give it credit for, but there’s always room for improvement.

http://linuxwireless.org/en/developers/GSoC/2009/Add_AP_Support_to_Network_Manager

Notice who the mentor is? Isn’t it great that Red Hat does so much development work at all levels of the software stack for ubuntu users to take advantage of. From low level kernel work..like maintaining wireless drivers..as well as desktop components like NetworkManager, they are doing the integrated development to make it possible for things to just work. It’s almost like Red Hat is building the best and most interesting bits for future of Ubuntu. Imagine how much faster Ubuntu users could get their hands on important technologies like this if Canonical made the manpower investments to work on the kernel drivers or the end user wireless tools.

It’s really too bad Canonical decided they didn’t have time to mentor Google Summer of Code students this year after they were accepted as a mentoring organization. Google Summer of Code projects can produce some very useful things when there are mentors who are deeply involved in project development who can guide students. Then again, they’d need to have developers who were deeply involved as project leads in upstream projects to be good mentors..so in the end maybe its for the best they stepped back, even though they were already accepted to participate.

-jef