Canonical are Hiring!

It seems like this week’s popular anti-Ubuntu FUD is that Canonical are missing people who can fix particular classes of bugs, many people have said the same thing in comments on my previous blog post.

So I’d like to point out that Canonical are Hiring! and we have many open positions listed on our Employment page.

If you’d like to work on open source software, for a fun company with some of the smartest people you’ll ever work with, or you know someone who would, don’t hesitate to check it out.

13 thoughts on “Canonical are Hiring!

  1. All of those jobs are home based, which is very bad. I definitely have to separate work from private life otherwise it is very depressing. I tried working from home, but it is very bad when the stress of work takes over the private space, there will be no place to relax.

  2. 1 ARM toolchain hacker
    1 OEM engeneer possobily integrating linux drivers

    The FUD was that Canonical doesn’t hire linux kernel / fs experts.

  3. I don’t get this particular complaint about Canonical. Canonical has historically (I don’t know if it’s true these days) not been making a profit but has hiring people like crazy. Just because they don’t have somebody for every possible area of the OS doesn’t mean:
    1) *nobody* in Ubuntu is has expertise in the area, we do have non-Canonical developers after all
    2) Canonical is not contributing to the greater FLOSS landscape. Canonical’s focus is much more at the higher level of desktop apps and online services, not kernels and filesystems.

  4. @Rob: we do have offices in a few locations around the world, in particular London, Montreal, Lexington MA, Taipei, etc. people near to those are free to chose to work from the office if they like.

    I know of other employees who have desks in nearby Ubuntu-friendly companies, it’s one of the awesome things about the Open Source ecosystem.

    Also there are other areas where we have particular groupings of developers, e.g. Portland OR, some of those might let people work from their space, etc.

    So the “working from home” need not be a restriction

  5. @Dmitrijs Ledkovs: actually, we just took down the filesystem-related job because we’ve filled it. The ironic thing about that FUD is that there *was* an opening for the entire time (it’s been up for months).

    Likewise the kernel team has recently been expanded.

    I’m not saying we don’t have all the resource we want, but the meme that we don’t *want* to hire developers is just FUD – we’re actively hiring like crazy, we just can’t fill the positions fast enough :)

    (In particular, we’re not in the habit of trying to poach developers from our Open Source friends, unlike others [hi, Google! :p])

  6. I have 15 years of Linux experience, advanced CS education, and above all, I’m a hardcore Ubuntu fan. Still, I sent my Resume six weeks ago to hr@canonical.com, and after two additional pings, I haven’t even managed to get a confirmation of receipt. What sort of profile are you guys looking for?

    • @Anonymous: if you contact me by e-mail, I can chase HR for you. The previous 6 weeks are the busiest in our cycle with our LTS release and UDS planning meeting, it may be simply that the hiring manager has been too busy to interview for the position you applied for.

      I’m sorry that they haven’t replied though, and I will certainly chase for you.

  7. So when Mark Shuttleworth sent that letter to the opensuse community in the wake of the Novell-MS licensing agreement.. that wasn’t an attempt at poaching? Sure he wasn’t luring people away with paychecks like Google is doing… but I’d still classify what Mark did as an attempt at poaching nonetheless.

    And did anyone say that Canonical doesn’t _want_ to hire developers? I read Ted’s comment as saying Canonical wants to hire them… on the cheap. Implying to me that Canonical wasn’t offering fair market value for the skillset. That’s an interesting bit of commentary about the state of supply and demand for linux kernel development expertise. If demand for expertise is increasing, I would most certainly expect it to get the hiring situation to get more competitive as it would in any specialized labor market.

    He also levelled and additional criticism that Canonical wasn’t letting their developers work enough as part of upstream kernel development. Not to get caught in another round at mind reading, and motivation second-guessing…but I will say that sort of caught me off guard as I didn’t expect that sort of criticism coming from that particular direction…as Google hasn’t been particular stellar with regard to that either when it comes to the lingering android patchset. It’s a bit of a head scratcher to me why he felt comfortable relating that opinion as it invites criticism of Google’s upstream contribution commitment.

    -jef

    • @Jef: I think we learned from that incident ;-)

      As far as I’m aware, Ted has never applied for a job at Canonical, so I can’t see how he’d know anything about our pay rates. I can only speak for myself, but when Google attempted to poach me to work on Chrome OS the salary they offered was *less* than my Canonical salary. I’ve been a hiring manager too in the past, and very very few people have turned down the job after salary negotiation that I’m aware of. So I think that’s probably unfounded FUD too.

      As to letting our developers work on upstream development of any kind, including kernel, I spend the majority of my time working “upstream” as do several others. It’s simply a choice of whether you want to, or not. If you’re fixing bugs, you’re actually required to get the patches upstream, etc. If you want to do development work, you simply have to put a few days work into a rationale that you can bring to UDS for why it’s a good thing to do.

      I would say that in the kernel space, there are much fewer contributed patches than we’d like, but I _think_ that’s more of a factor of the efficiency of the existing upstream. Once the team has find out about and triaged a bug, they’d check with the upstream maintainer – in many cases there’s already a patch in GIT that fixes it, if not, the maintainer tends to produce one of their own.

      While we have recently grown the kernel team, it’s still tiny compared to the massive teams at other companies; comments from people like Ted that are largely unfounded mean we can’t get the superstars who could turn our scratch in the surface into a decent dent.

      It’s a bit of a vicious circle, really.

  8. @Scott:

    So how big is the Canonical kernel team at the moment? How big are other vendor’s kernel teams? You say the other teams are massive. Is that a statement of fact or are you applying Canonical’s trade secret methodology for coming up with userbase estimates?

    Okay…do you have numbers for multiple vendors on he size of their dedicated kernel team? I’m more than happy to give Canonical the benefit of the doubt on this score and go back and rescale the kernel development statistics based on the size of each vendor’s dedicated kernel team and see where Canonical shakes out.

    I actually question whether you even define a dedicated kernel team at other vendors and encapsulate all the work that they are doing at the upstream kernel layer. When multiple engineers at another vendor is developing and committing patches for device hardware support at the kernel layer and patches up through freedesktop and also into user facing Gnome UI…it’s difficult to see how compartmentalizing the overall engineering effort into labels like “kernel team” makes any sense at all…when the engineering management at other vendors seems to be focused on managing resources to features integrated up and down the stack instead of compartmentalizing work into specific levels of the stack.

  9. I find it disappointing that with all of those developer and technical jobs, you are not interested in Technical Writers and similar folks who create documentation.

    ~~~ 0;-Dan

Leave a Reply

Your email address will not be published. Required fields are marked *

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>