AUG
26
2009

Some Comments on PySide

To be honest I'm not all that happy with the current situation. Riverbank Computing, basically Phil Thompson, has done an excellent job developing SIP and PyQt over the last 10 years and providing a Free Software (GPL) version which PyKDE is built on. Phil has also done an excellent job of providing answers to my queries, basically as a free service to KDE and the FOSS community. Having two competing Python bindings for Qt is a waste of resources and is generally disruptive to the community at large. Seeing the future of Riverbank and the good working relationship between it and KDE jeopardised is not something that appeals to me. I am disappointed that no kind of cooperative agreement could be reached between Nokia and Riverbank Computing.

On the technical side, PySide is just starting out and has a long way to go before it is as mature as PyQt and is a viable replacement for it. This is only natural. Bindings development is not easy -- just ask Richard Dale, he's been at it for years. (As a point of interest Nokia could have saved themselves a lot of effort by building on top of Richard's Smoke libraries/tools.) It will be interesting to see how PySide progresses and what happens in Python / Qt community. In the short term at least, PyKDE will continue to be developed on the mature SIP/PyQt.

Comments

I was thinking of trying some python KDE development, but this limbo with pyqt and pyside is really stopping that, even though pySide claims API compatibility. I would prefer a clear statement that as soon as pyside is up to the task, that then pykde moves to that. And a statement the pyKDE developers will join pySide development list to track and coordinate development.

Really? You want everyone to change just so you'll feel more comfortable using PyKDE?

Let's be honest here, last I read pyQt has some 100 to 200 paying customers. And now the creators of QT, backed by a multi billion dollar company and via a Brazilian (where KDE is strong) research institute will create their own python Qt bindings. Clearly with the aim of using python on maemo, and perhaps the Nokia netbooks that will come out in Q4 or 2010 Q1.

Ah, you're more impressed by big name branding, marketing hype and Internet rumours than by an established customer base and user community. I'd like to know where you get those numbers from, incidentally.

Moreover, the new lib will be LGPL, a clear improvement over the present licensing and something KDE should immediately approve of.

I'm not sure why KDE should approve of the LGPL over the GPL, unless it's generally regarded as better for people to develop proprietary software instead of free software on KDE. Maybe that's fashionable these days.

I don't know if KDE has some convincing power with Riverside aka Phil, but it should be made clear to him that pyQt will only survive in an OSS environment if it becomes LGPL also. Licensing has always been the weakest point of KDE, and now that is finally resolved with Qt becoming LGPL, keeping it for pyKDE seems like a no brainer.

You know, I'm sure he's aware of the situation and what people want.

Don't get me wrong, this is OSS so people do what they like. If the aim is to have python bindings for KDE, then pyside seems the way forward. Joining that now will make that implementation better quicker, than waiting for it to be better before joining. If the aim is to use pyQt because of sip and the good architecture of it, then stick with that. It would not be the most rational and best choice for KDE though....

So, you're saying that the best choice for KDE would be for the people doing the bindings to drop what they're doing, do a load of work all over again, just so that some speculative group of people can create proprietary Qt-based software on Maemo? Then, you hope that you'll possibly have a set of LGPL bindings for KDE at some point in the future as a spin-off from this effort?


By davidb at Thu, 08/27/2009 - 09:30

I have the impression you are somewhat against proprietary development. Nowhere did I mention proprietary development. I said LGPL and not GPL only because that is the license pyside is under.

Allow me to say I am writing already 10 year GPL licensed code (mostly pygtk based should you want to know), and for work BSD licensed code. I find the idea of dual licensing for commercial use against the ideas of free software though. You have been living under a rock if you don't know many people feel like that, but this is not the place to repeat the why's of that.

The reason I would be more comfortable is not the licensing though, but the danger of spending time on a product that is not around in 3 years time (or on a product that says they probably will break the API real soon). I was thinking of a plasmoid and a maemo data reader.

About being impressed, I know pyqt is good. But if Nokia is serious about Qt on Maemo, then pyside will be good too.

The number of clients for pyqt I read in an interview with Phil where he says Pixar and Disney are paying him among others.

I did not say the people who do the bindings must drop what they are doing. I said the people doing the KDE bindings should get on board of pyside so as to get a voice there. You can do that without even coding by just using the mailing lists. I further _believe_ choosing the LGPL licensed pyside is the better choice from a licensing point of view, but as I said in the original post, they can choose how to spend their time.

This issue does make me think about the khtml-webkit saga though. However, Apple did not let others join the team. Here the other project is inviting other developers to join. What is your stake in this anyway? Do you really believe Riverbank will keep producing pyqt even if their revenue runs dry? If you allow me to speculate, once pyside is 1.0, qt will just add it in the support package they sell for qt to their clients. Then the revenue stream of Riverside for pyqt dries up. And then what? Oh, yeah, I guess the people doing the bindings for kde will then also have to support the pyqt bindings.
Is there nobody in KDE that can go speak with Qt so as to have a view of their plans and decide this issue??


By bmcage at Thu, 08/27/2009 - 23:10

I have the impression you are somewhat against proprietary development. Nowhere did I mention proprietary development. I said LGPL and not GPL only because that is the license pyside is under.

Allow me to say I am writing already 10 year GPL licensed code (mostly pygtk based should you want to know), and for work BSD licensed code. I find the idea of dual licensing for commercial use against the ideas of free software though. You have been living under a rock if you don't know many people feel like that, but this is not the place to repeat the why's of that.

It turns out that I am generally against proprietary software, having experienced many of its problems from a user's point of view, though I think that dual licensing has been shown to be one of the least worst business models around open source software (if not free software). I can understand why some people might not like that approach, just as other people might prefer a BSD license to the LGPL, for example.

I did not say the people who do the bindings must drop what they are doing. I said the people doing the KDE bindings should get on board of pyside so as to get a voice there. You can do that without even coding by just using the mailing lists.

From a pragmatic perspective, maybe people from KDE should be making their voice heard by the PySide people. It would be slightly worrying if those people haven't already considered the effects their project might have on KDE development. (Though there's no entry about KDE in their FAQ, I notice.)

I further _believe_ choosing the LGPL licensed pyside is the better choice from a licensing point of view, but as I said in the original post, they can choose how to spend their time.

But why is it a better choice from a licensing point of view?

This issue does make me think about the khtml-webkit saga though. However, Apple did not let others join the team. Here the other project is inviting other developers to join. What is your stake in this anyway?

My stake is that I've invested a lot of time and effort in PyQt and I'd rather not see that go to waste. If it does, I'm sure I can find another way to spend my time.

Do you really believe Riverbank will keep producing pyqt even if their revenue runs dry?

Isn't that the issue here? PySide actually creates a problem that wasn't there before.

If you allow me to speculate, once pyside is 1.0, qt will just add it in the support package they sell for qt to their clients.

Recognising that people want to use Qt with Python would certainly be a break with tradition, but anything's possible, I suppose. Perhaps you assume that there's this seamless transition where customers enjoy great service while the product they're using is sidelined, and that they remain happy and confident when told to switch to an "API compatible" alternative with a completely different implementation.

Then the revenue stream of Riverside for pyqt dries up. And then what? Oh, yeah, I guess the people doing the bindings for kde will then also have to support the pyqt bindings.

Like the Ruby people support both Qt and KDE bindings, for example?

Is there nobody in KDE that can go speak with Qt so as to have a view of their plans and decide this issue??

Go talk to one of your friendly KDE representatives who does community/corporate work. I'm sure they can take it up with someone at Qt, but I'm not sure you'll get a clear-cut answer.


By davidb at Fri, 08/28/2009 - 00:19


>Then the revenue stream of Riverside for pyqt dries up. And then what?
>Oh, yeah, I guess the people doing the bindings for kde will then
> also have to support the pyqt bindings.

Like the Ruby people support both Qt and KDE bindings, for example?

Interesting to hear you believe this is doable. I would be ok with kde deciding they stick with the pyqt approach and base pykde on that, and will continue pyqt themselves should riverbank stop with that product. That commitment is important though.

In my own development work, I keep having to stop other contributors who want to move to python 3.0, or use clutter, or whatever else is the new kid on the block. Many coders fail to see the need to support things which are 5 years old, and to only add things that will be supported in 5 years time. An OSS project that does not think in those lines might be a cool project but is not a good partner for its users if they want to use that app for serious work. To return to the issue at hand, it's hard to convince people to use your bindings if not somebody steps forward with a clear commitment and a plan for the future, as clearly pyside has changed the equation.

About the license thing, I think I am just not comfortable with building a module under GPL, using pyqt bindings, that if it is used by a commercial entity because they are interested in my work, they have to pay for pyqt, which for me is just a glue building block to make my module. Should I think people should pay for my module, I'd make it dual licence myself.


By bmcage at Fri, 08/28/2009 - 09:07

Interesting to hear you believe this is doable. I would be ok with kde deciding they stick with the pyqt approach and base pykde on that, and will continue pyqt themselves should riverbank stop with that product. That commitment is important though.

Well, in the worst case scenario, you would be starting with a set of SIP files for PyQt that you would need to maintain, which isn't ideal, but it's not like you would have to start from scratch. As far as I can tell, PyKDE would continue to be developed as it is now.

In my own development work, I keep having to stop other contributors who want to move to python 3.0, or use clutter, or whatever else is the new kid on the block. Many coders fail to see the need to support things which are 5 years old, and to only add things that will be supported in 5 years time.

Right. It's interesting that you mention Python 3 because there are lots of parallels here with the Python 2 vs. 3 scenario (and Qt 3 vs. 4 for that matter). Do you sacrifice existing work, community, public recognition on the promise that maybe you'll get more users?

An OSS project that does not think in those lines might be a cool project but is not a good partner for its users if they want to use that app for serious work. To return to the issue at hand, it's hard to convince people to use your bindings if not somebody steps forward with a clear commitment and a plan for the future, as clearly pyside has changed the equation.

But PySide is the new kid on the block here. Sure, it has a plan for the future, but it has no track record you can use to judge whether the plan is reasonable or not.


By davidb at Fri, 08/28/2009 - 12:08

Generally I don't agree with the guy due to his hardline on issues. But even he can see the common sense of how dual-licensing supports the free software community while still making money.

I think rdale already outlined how PySide's technology likely wouldn't scale to kdelibs (due to fundamental design decisions that would be hard to engineer out of, thought not impossible of course). But you're probably not interested in such facts, but just making a racket.

I'm also disappointed Riverbank and Nokia didn't come to an agreement. But I don't hold that against Nokia or Riverside.


By eean at Sun, 08/30/2009 - 13:21

I agree with RMS for dual-licensing of end programs and usefull small libraries. When it comes to my GUI kit or language bindings, I disagree however, and want LGPL at a minimum.

Every use has it's own best licence. Like the best licence for math or physics code examples is the public domain...

As I posted in another reply, pyside is aware using boost is not going to cut it on S60, and are working on an alternative. Not that I am attached to that project, but somebody needs to play the devil's advocate it appears as the reaction against people who welcome the pyside move is a bit hostile here (linking me to organized crime is really unneeded, see? :-P).


By bmcage at Mon, 08/31/2009 - 09:23

bah if you login during the reply process, it stops being a reply. :P


By eean at Sun, 08/30/2009 - 13:19

In case you missed it in the long slashdot thread on this, one pyside developer does say an interesting thing:

http://developers.slashdot.org/comments.pl?sid=1352369&cid=29251973


By bmcage at Mon, 08/31/2009 - 09:06

It's interesting because it's an admission that they have to take a step back and review the situation. This follow-up is also interesting because it leads to an observation about why nobody developed SMOKE-based Python bindings before.

The existing popularity of PyQt doesn't seem to count for much these days if people are so willing to reinvent the wheel.


By davidb at Mon, 08/31/2009 - 11:33

Pages