Wednesday, 21 July 2010

Qt: Bootstrapping openness

I witnessed (and was pleased to take part in) some interesting discussions on #qt-labs this afternoon, all stemming from a contribution to Qt3Support being rejected.

A long story short, the contribution - despite looking reasonably valid - was rejected because Qt3Support is effectively unmaintained, and as a result, any changes to it could have negative impacts on users of the support API.

I understand that argument, yet at the same time - I can't help but think it's a bit of a backwards approach to be taking. Typically, a contributor will wander along, find a bitrotting module/project that interests them, throw patches at the previous maintainer - and shortly after doing so, find themselves a de-facto (or indeed official) maintainer through their efforts.

This is a natural progression of things and should really be encouraged, it allows what would otherwise be dead code to live on. However, in Qt3Support's case, the central point was that they'd love someone else to take responsibility for it, but don't want to expend the effort themselves to triage, maintain, and otherwise support it right now.

To me, it's a false saving.

Time you save not maintaining it now (and encouraging potential contributors/future maintainers along the way) is spent being forced to put the code on life support maintenance if you decide you want that code, for whatever reason, later on.

Not to mention that those people who might be happily contributing you ideas or patches (to code old and new) are instead going to be spending their spare time doing something more rewarding than having their hard work rejected in the future.

Openness doesn't just happen overnight. It isn't just in the licensing. It requires real persistent effort and culture change. This is something I plan to keep revisiting over my next few posts.

{Note}: Before commenting, please note that this issue isn't *just* based around Qt3Support. That is one example of the problem, yes, but the patch was actually to QWorkspace which actually wasn't part of Qt3Support, and QtSql is in a similar boat - and there is nothing to port code using QtSql *to*.


  1. the fact is, if you that code this bad you can fork qt.
    Conducing users to switch to newer API is something perfectly reasonable. The problem with old code is not only maintenance, but it can prevent you to improve or change some behavior in the rest of the code (because you have to keep compatibility with legashit code).

  2. I should have been more clear on this point, but this is an underlying, more general problem - not just related to Qt3Support. QtSql is another area of Qt with similar problems. Patches to it have (in some cases) gone unreviewed for almost a year now, simply because it is unmaintained - and there is no "newer API" to switch to.

    Regardless of that, switching API - especially in a commercial product - is a serious undertaking. Trying to convince your boss that you're going to be working hard for the next month or two to "port" an application, which will end up more or less where it started, isn't going to go down all that well, as well as being boring - and as a result, we have code today still using Qt3Support.

    It doesn't burden Qt overly much at present to keep this code, but I would personally quite like to see a firm lifespan put on it being removed unless someone steps up to maintain it (and are given the appropriate help and tooling to do so).

    Leaving it in its present (unfixed) state isn't really all that great.

  3. Actually the patch that I was submitting and which got rejected, was a patch for QWorkspace.
    That's not even as old as Qt3Support, i.e. it got deprecated more recently.

    I was really furious because it was rejected for fear of it increasing support work. But
    if I do all the work (actually fixing the bug, not just reporting that a bug exists), then
    they should be happy about that, and integrate that work, rather than just hiding behind
    "it's dead jim, we'd rather not touch it anymore". The code is shipped, therefore it is assumed
    to work. If not, then every migration to Qt 4 becomes more expensive because we must also
    port away from QWorkspace, and at some point it just becomes too expensive for the customer,
    who will end up giving up on Qt.

    I agree with you that accepting patches to deprecated areas *MIGHT* end up with people stepping
    up as voluntary maintainers of some areas, but I certainly wish that this doesn't become a requirement
    (which seems to be a floating idea in qt-labs at the moment). In KDE we accept contributions to
    unmaintained areas even if the contributor doesn't promise to become maintainer. Of course we'll
    contact him in case his change broke stuff, but that doesn't mean we'll ask him to fix every
    bug that was there before he came in, that's just nonsense. Some people do step up and actually
    do that, but we can't require that of every contributor.

    For instance I could actually maintain Q3ButtonGroup after all the projects where we had to fix it
    so that it finally behaves almost like the Qt3 QButtonGroup, but just because I fixed one bug in QWorkspace
    doesn't mean that I want to maintain QWorkspace in the future...

    Anyway. We agree, rejecting patches to deprecated code (for that reason) is nonsense.

  4. Qt3 support is a module that allows people to keep using code that was end-of-lifed 6 years ago. In internet time thats an eon ago. If people still depend on that, I'm not entirely sure that the pain they have is not worth it.
    What people seem to assume is that you should *port* that code, while we have new technologies that allow writing it from scratch 10% of the work it was a decade ago.
    The qt3support code should be removed from Qt and maintained by volunteers as a separate project IMOHO.

  5. @Thomas: please see the added note on the bottom of the post, this isn't (just) about Qt3Support, in fact, the original issue was brought up due to a patch to QWorkspace which I (incorrectly) attributed to Qt3Support due to being busy at the time.

    note that just moving to a seperate module it isn't possible. Qt3Support requires (ifdef'd) support throughout the core of Qt itself.

    also note that there is nothing wrong with keeping code where it is, provided that patches to it aren't rejected without good reason, which is what the open governance discussions will (I hope) help lead to.

    thanks for your comments!