Thursday, 6 May 2010

Qt: how to love and embrace being open

It's been quite a while since the Qt code was opened up now.

With the changing of development model and licensing, one would think that there was a lot of potential to nurture and grow a Qt hacker community, but at least in my mind, this hasn't taken off quite like I'd hoped it would, although things have been steadily improving, through things like the #qt-labs channel on freenode.

After  some recent chatter with a few people on #qt-chat, I started reflecting on just how things are, how they could be, and what could be done to help get them there, and so I'd like to reflect on how to best encourage new development on Qt: the best approach, I think, is to lead by example.
..And if all else fails and you're really bored, you can always write test cases. ;)

Yes, you. For all those of you out there who haven't become involved yet: now is as good a time as any.

Don't be scared off by the complexity of Qt. It's a cool library, a cool set of people, and awesome fun to hack on. You may not be perfect, but nobody is, and you can learn. You beginners of today are the hackers of tomorrow.

If you don't know what you could be doing, feel free to ask me, or one of the many other friendly folk on #qt-labs - I'm sure someone can find something to keep you busy. :)

Why, I hear some of you ask, is this important? Well, it's fairly straightforward.
Qt as an application development platform is growing and growing and growing - not just inside the mobile world - and this shows no signs of slowing. This is great news.

Not all Qt application developers will work on Qt itself - but it is something that we should work to encourage as much as is possible in order to match the above growth. The more skilled platform hackers we have, the more application developers we can support. Think of it as a pyramid: you can't have a stable structure without a solid base.

How, then, do we nurture and grow our platform hackers? How do we encourage growth of the community around the code? There isn't a simple, single, answer to this, but I think there is plenty we can do, and the above is a very good step.

However, some of us with a corporate affiliation are already contributing to Qt, and there are a few things that would help encourage more community growth.

Firstly, it would be much better if the community had merit to provide review of what goes into Qt itself, both merge requests and from internal work too. Currently, we can provide review, but it isn't a replacement for internal review.

Not only is this creating a bottleneck, but (somewhat obviously) it doesn't encourage others to take part and become the hackers of tomorrow.

Secondly, everyone should be going through the same processes. A code review in #qt-labs is still a code review, but when some people are made to jump through the hoops of filing a merge request, this leads to a two tier system.

A much better way of doing this, IMHO, is to stick with the idea of having a few reviewers who know specific subsystems, and can accept patches for their 'area' (be it networking, QML, or whatever) - and all patches, no matter their origin, go through merge requests.

Lastly, the remaining private infrastructure should be opened up as much as possible. No private pastebins, no private test server, publish the results of the integration runs and test suites on platforms. (note: I believe that work is underway on this, I'm just including it for the sake of completeness.)

There are other points here which are useful for an open future, but I've deliberately kept the list short - walk, before you can run. :)

Finally, I'd like to thank Nokia for purchasing Trolltech, and starting the road to opening Qt development. You've started something very cool and awesome here, and I'm excited to play my role in this. I hope that some of the ideas and points I raise here can prove useful to moving forward to a bigger, better, more awesome future.

[I'd also like to thank the following people for their time and feedback on this post:

  • John Brooks
  • Thiago Macieira from Qt
  • Bradley Hughes from Qt
  • RevdKathy from Maemo]


  1. IMO Qt's main roadblock to contributions is the requirement to give Nokia a "do what you want -- even close the source again" license.
    My personal reason for contributing to FOSS is to help the community and not to give some corporation more rights than the rest of the community.
    If Nokia wants the right to close the source, then IMHO Nokia should just license Qt under BSDL for everybody.

  2. Licensing is the way it is due to the commercial Qt customers, which (regrettably!) aren't going to go away overnight, or indeed perhaps at all.

    I'm all for FOSS, but I'm also for compromising a little to achieve better coverage of FOSS. If they had bad intentions, they could well have just closed Qt for their own purposes and locked the community out entirely.

    They haven't, and as a result, we've got an open library which will soon be shipping on most (all?) of the devices of one of the largest handset manufacturers worldwide. That's something pretty big for the community, I think.

    All this aside, I'd speculate that in the (highly unlikely, they know the risks and of course aren't idiots) case that Nokia were to re-licence Qt again to be more restrictive than it is now, I'm fairly sure they would end up being forked, and kept under LGPL. So it's never going to end up closed again, at least, not to the detriment of the community.

  3. Do commercial customers forbid to adopt a BSD license for everybody? I don't think so.

    Nokia of course has the legal right to do whatever it wants with most of the Qt source (excl. Phonon and WebKit).

    I'm just saying that the current contribution requirements hinder 3rd party contributions. Why should a competitor of Nokia contribute on the current terms?

    While I appreciate Nokia's increased development efforts for Qt, I simply won't work for corporations under such terms and considering how many people are complaining about the same in OpenOffice (where Sun/Oracle can do anything), I'm not alone.
    For OpenOffice the same contribution requirements led to the Go-OO fork.
    It can't be in Nokia's interest to go down the same road.

  4. You raise some interesting points, but I think you're partially arguing apples and oranges.

    [For example at least in OO's case, as far as I recall, there were other reasons leading to that fork, it wasn't purely a licensing or contribution decision, but also down to some (worthwhile) contributions and change being ignored]

    I'm not quite sure what you're arguing about, though. At first it seemed like distribution ("If Nokia wants the right to close the source"), but now it seems like you're unhappy with the LGPL. Why is this?

    I'd also encourage you to take a read of the contribution agreement, it's really not all that draconian considering where Qt is positioned - if there's any specific points you'd like clarified or changed, raise them, and perhaps it'll be addressed.

    At the end of the day, sitting on the fence because the water isn't quite right will leave you left out in the cold, though, the only way you're going to make change happen is by making others aware that you want change.

  5. I'm not unhappy with the LGPL. I'm merely stating why people aren't contributing as much and it's because of special licensing for Nokia.
    Either Nokia should simply use the LGPL without any exceptions for Nokia (GTK-like licensing) or if Nokia is legally required to to offer closed source variants because of Trolltech's old customers, Qt should just be BSD-licensed.

  6. Okay, that's a clearer position, and to my understanding, the reason for dual licensing is indeed commercial customers. I am not in any position to know why BSD licensing was not an option, but I'm actually more comfortable with LGPL personally.

    I think things are definitely on the right road, anyway, and we'll have to see where it ends.

  7. I personally don't see why BSD licensing would be preferable to an LGPL + Nokia rights to release a commercial version. The only difference that would make is that instead of paying Nokia to be able to ship a (closed) modified Qt, everybody is free to close their version of Qt. I don't think that helps to encourage contributions.

    I do hope the commercial licensing will go away at some point, but for now please also realize that the money earned with the commercial licenses is mostly used for support, sales and marketing, making Qt even more popular. I think this is in the interest of everybody in the end.

  8. It does in some respects for the very point you raise: the freedom to close.

    Arguably, the people who would want to close their development aren't the sort who would contribute back, but this isn't entirely true (see the various BSD projects using that licence).

    I can understand some people being a little unhappy about it being possible in theory for Qt to close development on a permanent basis - I'm by no means well read on the subject, but this was the reason for the KDE licensing agreement as far as I remember (in that Qt would fall to a more open licence if a GPL release of substantial improvement was not made at least once a year).

    Perhaps the reinstatement (or restating?) of this guarantee is something that would put this issue to bed for those it matters to - but at the end of the day, I think the issues I outline above are much more crucial than licensing, and that's where I will choose to put my energy.

    Of course, this doesn't preclude someone else taking the ball and seeing what happens. :)

  9. The biggest challenge is Nokia itself. Rather than allow Trolltech to exist as an independent subsidiary like Navteq, Nokia basically brought Trolltech into their Device Group. Companies who compete with Nokia for specific platforms/verticals have no desire to use a framework whose developers share an address. Where companies don't compete with Nokia such as desktop use of Qt, you are more likely to see less concern. But in the mobile space, you will be more likely to see Taiwanese ODMs than big name companies using Qt in the mobile space. That has a ripple effect on the community. Contrast this with Google and Android and I think you will get the point.