Wednesday, 27 October 2010

Qt: the process is broken

After reading Albert's thoughts about the state of openness in Qt, I felt like I had something to contribute, and contribute I did in the comments on his post, but I don't think it is enough.

While I encouraged him to "please do stick in there", we're not exactly just at the start of this process anymore; Qt's moves towards opening up have been well received, but in the words of Thiago, "now we have to do more".

At the heart of it, I think it all boils down to two things:
  • Lack of manpower
  • The process to integrate merge requests is clunky and slow
So... what do we do?

Lack of manpower
This is actually probably is a much bigger problem than just merge requests in that there just aren't enough skilled people working on Qt itself (with push access), and the amount of work they have to do on their own tasks means there simply isn't enough manpower left over to work on the merge request queue, especially given the hoops that the current process requires the committers to jump through, which amount to an awful lot of effort and manual checking.

Get more people. Perhaps it's not even out of the question to dedicate a few people to working on community management at a technical rather than twitter-level.

While marketing Qt is great, and I'm far from knocking those efforts, you also need to have a healthy developer community around Qt itself, and right now, that doesn't exist. If you have developers dedicated to furthering that community, you will reap that investment further down the road.

I imagine that people in this sort of a role would act as the 'grease in the wheels' while Open Governance moves slowly but surely along, helping in reviewing merge requests (knocking back those with simple mistakes) and working together with others inside of Qt to integrate the finished ones, basically moving all of the burden of integration off of the product developers.

Think community managers on steroids. With push access and the knowledge to use it.

The process is clunky and slow
Work on the process. Open Governance is addressing this, but so far, there's been a lot of talk, and little (visible) action thus far.

It needs to become more of a priority. The quicker this is solved, hopefully, the more manpower Nokia will gradually have to shift onto people other than their own tasks, and let the wider community worry about what concerns them.

(also known as, "where I state the blindingly obvious")

Let's face it, it's great to have access to the source repository, it's great to be able to submit changes, it's great to have an open license.

It's not so great to have your work ignored after making requested changes, or worse still, ignored completely.

This needs solving.

So, Nokia, are you really invested in making Qt as good as it can be?

[usual thanks to my good friend, John Brooks, for proofreading and putting up with my horrible use of English]


  1. The situation seems highly analogous to the one Apple faced with WebKit: moving an open source but closed-development project to a (more) open development model as well. So how about "look at what Apple did and copy them" as a guide? It seems to have worked for them, at least viewed from the outside.

  2. Nokia is a hardware company. They never put the resources needed behind Maemo and now they make big PR talk about Qt, but a year from now they may be the largest Windowsphone company.

    I'll be at the MeeGo conference in Dublin, but does Nokia care about MeeGo or do they just see it as the plumbing for Qt?

  3. Nokia cannot really continue to compete as a hardware company. The world has moved on.

    If they were in Korea or China, perhaps...but a hardware company from Norway just cannot compete in today's world. Unless they can adapt they will die.

    They have been trying to adapt using symbian but the world regards it as yesterdays news and on that path they can only be yesterday's company.
    They need QT and a position in meego to have an IP stake in the future.

  4. Finally making Qt modular, like a proper project will help:

    Then it's much safer to make a change to some small part without worrying that it will be pushed out in a release too soon just because some other module needs to get its changes out.

    Of course the main thing is that nobody at the top seems to care about ensuring basic politeness when dealing with contributors or customers.

  5. Nokia should start to give trusted "outsiders" review privileges and access to their tools. Otherwise they will never fix the manpower problem.

  6. @cloose: I don't know, it probably wouldn't take more then one or two community managers as Robin specified to shepherd patches.

    However the community manager would need a lot of support from management and other Qt devs. I wonder if the problem is that its not clear who has the authority to approve or reject patches.

    @eagle you're completely wrong, they just made an West coast software executive their CEO. Nokia has 0 desire to be an Android or Windows 7 OEM. Their dedication to Qt should really be unquestioned at this point.

  7. Stephen Elop
    President, Microsoft Business Division

  8. Hi Robin,

    I work at Nokia on Qt. My team works on building our web infrastructure and works with the community, so I read your post with interest.

    First off, we know we need to improve the process. The open governance project is designed to help fix much of this. Like with all things that are big and important, it takes time.

    Secondly, we are always on the lookout for good Qt developers. We also have a community engineer position open (applications encouraged). All of this is designed to not only increase our Qt manpower internally, but also make it easier to get contributions in.

    Furthermore for clarity, there are two angles we take with regards to the Qt community: We have people developing _with_ Qt, and people developing Qt itself.

    For the development of Qt itself, that is something that Qt developers handle. Direct contact with our developers is the best way of getting the best contributions in, however we recognize the process currently isn't ideal. Hence the open governance project.

    For folks developing with Qt, we have put a lot of time and effort into building our developer network: Now that it is of sufficient quality we are looking for engineers to work on the site as well.

    Hope this helps.


  9. @Aron Sometimes when you develop with Qt you end up needing to make a change *in* Qt. If you see the world as split between Qt developers and everyone else you are missing the point entirely.

  10. I think it would help a lot if Qt developers would clearly reject things earlier and faster. This saves time on both ends, worst case is that the contributor keeps wasting time with a patch that hasn't got a chance to get in but everyone's being too polite to say it out directly. It will also clean the merge requests queue a lot.

    Your first merge request (QCircularBuffer) is a good example of this. Just because something can be added to Qt doesn't mean it should, as every little piece adds to the cumulative maintenance burden of Qt as a whole. Someone from Qt should make a snap yes/no principle decision if the submission is anything that's worth pursuing for inclusion into Qt.