When the World Ends

I’m delaying my sleep time further on, after two hours on IRC discussing the gtk+ 3.x issues spawned by Miguel’s blog post, because there are a few points I’d like to make.

discussion: the first, and foremost, is: let’s not use blogs to discuss. blogs suck at this — they break down communication, they are slow and they are not meant to do this kind of stuff. we have meetings, mailing lists, IRC — all of these are better versed at discussing things. for instance, I would have loved to have Miguel at the gtk+ team meeting of tuesday at GUADEC: it would have been a great discussion, I’m sure of it, and we might have had a different state of the union talk.

marketing: let’s be honest, here — we’ve been joking a lot on KDE 4.x and their marketing trainwreck, and how it was similar to the GNOME 2.0 own marketing trainwreck. there’s a difference, though, with gtk+ 3.0 and it is: gtk+ is a library, is not an entire desktop; if we call 3.0 the initial release of the 3.x API series it’s because we promised that the 2.x API series would not break API nor ABI. QT 4.0 was released with KDE 3.5 still going strong and KDE 4 far away in design land, and the features that are now used by KDE 4.x have been added during the 4.3 and 4.4 releases of the QT platform.

features: yes, 3.0.0 might not have features. is this bad marketing? probably. so we need to fix this. a way ((kudos to iain)) to do this would be keeping the 3.0.0 in alpha state, call it 2.99.0 ((but install a pkg-config file called gtk+-3.0 and install the headers under gtk-3.0)) and add features to that until we get to a 3.0.0 that developers will want to migrate to, like the new scenegraph API or the new style API. let’s break with 2.x in style. :-)

communication: there’s a certain lack of communication between the gtk+ team and the users of the library. in my opinion, it’s due to the small number of active developers and to the fact that ISVs don’t really get involved into shaping the platform they are using. they have the source code, and sometimes it’s easier to fix in-house than to communicate and go through the proper process — and this is a structural problem that is caused by the small number of people involved in the said process as well. the gtk+ team needs to open up more, and at the same time the ISVs need to get more involved. sometimes it feels to me that the team is waiting for features, direction and help in the development, while the users of the library are waiting for the team to come up with the perfect plan to fix all the bugs and warts while retaining the whole API and ABI.

process: this is connected to the first point — we have a lot of channels, and it might be daunting to actually follow them all; but we’re also open in terms of discussion and revision. this is our strength. so please: if you want to discuss, join the IRC meetings on the #gtk-devel channel on Tuesday at 20:00 UTC or send an email to gtk-devel-list with your points. get involved. help shaping the future. don’t stand idly by, and wait for stuff to break to complain.

I’d like to thank iain, Hallski and campd for the interesting discussion — and for the points raised and taken