In the land of emotions

I got a few comments on my phonon blog entry yesterday. A big thanks to everyone who posted comments and gave feedback. I was positivly suprised at both the number of comments and the general quality of comments. These things tend to quickly degenerate into mindless flamewars, but a high percentage of the comments where quite on point and reasoning. I will try to comment on some of the general issues raised, but after this thing got onto osnews and lwn the range of comments range is to big for me to go into them all here in a proper fashion, the thing with such debates is of course that they tend to stray far from their origin as they go on.

That said I am not going to do a detailed discussion per blog on this subject either, so for those unhappy about this debate even taking place feel assured I will not post on it again for a while :)

Maybe the most important issue brought up was that of API/ABI stability, which for instance Scott Wheeler brought up. I consider Scott a friend and I think his entry is well considered. My general response is that the bigger and more complex an API gets the chances of getting it right the first time goes down. Current use cases proposed for Phonon goes beyond the ‘playbin wrapper’ that Scott talks about, including adding VoiP support for instance. I am not saying Phonon is already has a scope where being ABI stable until 2012 is unrealistic, but I already see a lot of talk and pressure inside the KDE community to increase the scope of Phonon. And some of the expectations expressed through for instance comments to my initial blog or the article will not be met by the API Scott proposes. That is of course more an issue of expectation management than anything else of course.

Lessons from arts:
Another common point brought up was the lessons learned from arts in KDE. Why a project fails has many explanations of course, but I don’t think it would be fair to say arts in KDE failed because KDE decided to choose one media framework. A oversimplification of the argument made for sure, but it highlight why I feel most of the arts arguments brought don’t ring true to me. I would say that factors such as adopting a project with little prior use, a small development community and a design which was clearly not meant for video from the outset was the bigger contributing factors to its failure. So ‘burned child doesn’t play with fire’ might be old saying that applies here, I feel using it as an excuse isn’t fully justified. I also find it sad if the experience with arts have caused the KDE community to think that from here on out they only want to be a multimedia framework consumer, not development partners. Because that is why I want KDE behind GStreamer, to be our development partner on GStreamer. I think that will be good for GStreamer and help us increase our pace of development even more and thus good for KDE because you get better more advanced media framework features for your users and developers even quicker.

The application of force:
One common theme more among the user replies rather than the developer blogs is that of developers/users being forced to do something. I always found those kind of arguments a bit bemusing. So GNOME and KDE or GNUStep for that matter is basically a collection of development libraries, a suite of applications and also some written and unwritten rules about what goes and not. Those rules covers things such as programming languages used, what kind of dependencies are acceptable and so on. Philosophically I guess one based on that one can claim that these projects are vehicles of subjugation, but personally I see these things more as developer aid and guidance. But for those who disagree I guess its time to start printing the ‘Free software is all about choice subjugation‘ t-shirts :)

Anyway we could go on and on debating the various issues on the why and why’s not of chosing a multimedia framework or what is possible to abstract in what fashion in what timeframes or not for a long time. I think my arguments from the inital post still stands on their own and of course people now have interesting viewpoints from a lot of people on the subject too, like the people commenting on my initial post to other bloggers like Aaron Seigo, Jono Bacon,Ian Monroe and last but not least Scott Wheeler. While we all might not agree fully with eachother I think its been an interesting exchange of thoughts. Thanks :)
Update: The very cool Michael Pyne has also chimmed in, he doesn’t agree with me, but that doesn’t make him less cool :)

4 thoughts on “In the land of emotions

  1. Please, do not repeat again that crap about “GStreamer 0.10 begin API/ABI stable”. Just a few days ago Thomas Vander Stichele ( made a proposal to break API/ABI compatibility in 0.10!

    That’s exactly why Phonon is the right choice for KDE4. It may be right for Gnome developers to change their software everytime GStreamer changes API/ABI (which is too often, sadly), but it’s not for KDE.

    If KDE used GStreamer, either KDE app developers stick with GStreamer 0.10.5 for the whole KDE4 lifetime, or KDE app developers change their apps for GStreamer 0.10.6, 0.12, 0.14, etc.

    GStreamer releases so many versions with so many changes so often that it’s a very fast-moving target, and that’s definitely BAD.

  2. In my mind, the ability of the Free Software community to quickly change and adapt API’s to improve functionality, and supply application developers with the features they need to write great software, constitutes the very core of it’s appeal, and advantage over the proprietary software world. Look at Linus attitude towards breaking compatibility with binary kernel modules.

    API changes just require good communication and coordination among developers – which is what the distributed Free Software community *must* learn to be good at anyhow. Whether GStreamer devs need to do better communicating API changes to their users is a different question.

    I think the Phonon approach will represent much more work in the end than it should be to adapt to a changing GStreamer – whose API changes should slow dramatically as it matures (has matured?). And aside from that, if KDE wants to lose their ability to adapt and drag themselves down with paperwork and silly binary compatibility policies, that’s their problem.

  3. I don’t know why I even reply to people that choose their name on the first free variation of Anonymous they can find, but here goes anyway.


    1) which syllable of the word “pro-po-sal” did you not understand ?
    2) which letter can’t you tell is different between the acronyms “API” and “ABI” ?
    3) do you even understand what’s being proposed ? Of course we’re not just breaking ABI, and breaking the API isn’t even proposed at all.

    Good luck finding that rock again you crawled out under of.

  4. Re: the comment in that thread “if nobody is using an interface, does changing it count as a break” I’d have thought the answer is clearly yes … it’s impossible to prove nobody is using a particular interface so once shipped as stable it has to remain that way even if very obscure. Otherwise the interface is not really stable in the traditional sense of the word but rather “stable as long as we know about your app and believe it important enough to keep”.

    That’s a general comment, I don’t understand the details of that specific proposal so can’t say what effect it’d have on apps.

Comments are closed.