• Categories

  • Wayback Machine

  • My Defunct Podcast

    The Bungee Line was an audio podcast for web developers, covering web API's, software development, and the creation of richly interactive web applications.

    podcast feed  Main Feed

Compiz, Beryl, and David Reveman

Reveman on Beryl
Our latest Novell Open Audio, features an interview with David Reveman about the recently announced project called Beryl, which forks from Reveman’s Compiz project.

You may recall that David is the hacker behind Xgl and Compiz, which are collectively known as Desktop Effects. David has been on Novell Open Audio twice before, once to explain Xgl/Compiz and once from GUADEC to give us an update on the features he would focus on next.

We pursued the interview after a couple of Novell’s field technical specialists contacted us regarding Quinn Storm’s announcement. We recorded the interview last Thursday, but sometimes it’s hard to get stuff done relative to other commitments. Sorry for the delay on this one.

So why cover a fork? Don’t these things happen all the time? Well, when I first read Quinn’s post, I thought to myself, “Oh, no…this is one thing Novell doesn’t need right now.” Just when it seems that the community is starting to see that maybe Novell is a decent open source citizen, having a fork cite its impetus as, essentially, frustration in working with Novell goes against the culture that I think Novell has been working to live. It upsets me, since I have to be able to represent Novell with integrity.

I have had occasional learning conversations with a few community members–a couple of them very prominent people–who have stated a similar impression about Novell’s work in open source to what Quinn identifies in her announcement. So, I was very concerned that Erin and I were going to discover that we indeed really have been difficult regarding Compiz. Since that’s not what we want to hear about our company, we also were on a mission to get to the root of what about how compiz is being managed non-inclusively. Ultimately, we chose to cover this issue–which some may say is a tempest in a teapot–because we wanted to see whether Novell really was being difficult.

What we discovered was that the way that David manages Compiz is pretty much the standard way for a lot of open source projects. He has taken many community code contributions, and worked to explain better approaches to the people whose contributions he did feel were the best technical ways of doing something. In other words, he seems to be doing his work as a maintainer. But that provides only part of the whole context around the Beryl fork.
Does the fork tie into Compiz/Xgl’s history?
Maybe there is a relevant tie to Xgl’s controversial history [link1, link2], a “sins of the past” thing. Some may recall that after getting hired on by Novell, Reveman took Xgl in-house for a period of its development. As I have come to understand it, the two sides that I have heard are:

  • Critics: Novell pulled a piece of important work behind closed doors instead of following the community-based development ethos.
  • Reveman: David took Xgl in-house in order get it stabilized so that community would have working software to code against. Prior to his taking it in-house, David received no significant contributions, so it shouldn’t have been such a big deal.

Both inside and outside of Novell, different people have come out with varying evaluations regarding the means and ends in that matter. Many free software ethicists will not agree with the means: a project should be done in the open throughout it’s history.

Personally, I can see both sides’ position. However, being inside Novell biases me to favor the opinion that its okay for a company–just as it is any individual in the community–to take one of their non-working projects in house and develop it up to a provable state before bringing it back out into the open.

The announce-after-getting-the-code-working model allows a company to make big splash announcements for that work. If the company is otherwise contributing prolifically–which Novell is–I think the action needs to be weighed against the overall good for free software. And, as long as companies involved in Linux live or die off of their technical expertise–which I think is the way to keep companies from growing innovatively lethargic–they will sometimes need to show off that experise. Desktop Effects allowed Novell to do that in spades.

Anyway, whichever side you fall on–I really don’t much want to stir debate on an old issue–I think you can see how the Beryl fork announcement is opportune relative to the controversy around Xgl. Compiz is a very glamorous project, especially for end-users. There are many who would like to have their names affiliated with its capabilities. With the controversy about how Novell developed Xgl/Compiz still lingering, it’s easy enough for people to believe that Novell was not not inclusive enough regarding community participation in Compiz. (See? There really was a point to all that preceding text.) But the real question is not about history, but about the conditions that lead to the fork. Has David been managing compiz in a way that is inclusive enough for developers to get involved and contribute, or not? That’s what Erin and I set out to find out.

Maintainers, Project Autonomy, and Novell
My one worry is that the episode may sound like it was facetiously crafted to convince people on the opinion they should have. It wasn’t, but as Erin and I learned about what was going on, we started to see a broader picture.
David Reveman at GUADEC 2006Our initial reaction was that it sounded like it was a case of developers playing “he-said, she-said.” But after editing the audio–mostly cutting out the pauses and ums that come with English being David’s second language (and mine, too, apparently. You really don’t want to hear how bad I am at that before editing)– I came away tending to think that David has managed the project in a standard open source manner.

After the interview, Erin and I recorded the outro segment, in which we briefly analyze our take on the matter. The main takeaway for me was that the management of compiz has not been done by a big nameless, faceless corporation, but by an individual who works at Novell. Yes, an open source developer in a big corporation will have some priorities set by the mothership, but Novell seems to allow a maintainer a fair amount of autonomy in managing his or her project.

Certainly David believes that the Beryl fork was unnecessary, and that he has been quite open in how he manages the compiz project. However, David’s opinion will reflect his own view, and does not necessarily settle the debate.

One other thing to mention: I have not spoken to Quinn about the issue (but Moosy has), nor have i tried to at this point. I have just read her announcement, and much of the follow-on commentary. It was some of that commentary that prompted us to conclude with a message that essentially says: however you interpret the issue, please also consider that Novell provides maintainers like David with a lot of autonomy about how they manage a project.

Your Turn
I would be very interested in some intelligent opinions on the matter. Read the announcement and other materials linked from the podcast, then after coming to understand Quinn Storm’s reason for the fork, give the audio a listen. I welcome and appreciate well thought-out analyses, for or against.

About these ads

12 Responses

  1. Well, here are my two cents:
    (First of all this was the first “podcast” ever listened to – I prefer transcripts, but anyway, the topic was to interesting.)

    The idea of such an interview was good – its good to hear David’s position and impressions, and it is important to spread the word about it. Not to battle anyone, but to give others the possibility to get an own opinion, to see both sides of the coin.
    I have to admit though that to my ears most questions and conclusions sounded pretty biased – Erin balanced it with asking questions from Quinn’s position, but the overall impression is a slightly biased view of the interviewers. Could have been a bit more balanced, but on the other hand I know that this is never easy.

    The things David told were also very interesting: one of the main reasons many people like Beryl is the obvious non-gnome dependency: I do not use Gnome, and therefore I do not want to use compiz with any gnome dependency. It was the first time today that I heard that compiz does not depend on Gnome hardcoded – you should spread the word about that much more!
    On the other hand, David didn’t mention any KDE or independent solution which is already existing: All plugin-structures do not help if there is no plugin but only Beryl’s non-dependency solution.
    So, do spread the word more about this plugin technology – and provide also the basic plugins everyone needs, like a non-gnome plugin for the KDE folks.

    It is also interesting to see that the ways of communication differ quite a lot: Beryl came out of a forum centered community, David is used to e-mail and Bugzilla. That is probably one of the main roots of the problems.

    As a result, it (now) does not look like that it is David’s fault, but that there has been some misunderstandings as well as some fundamental problems.
    And it looks like that the fork happened without trying to solve the problems on a different way. The developers should have talked about such steps before! That didn’t happen, and that’s sad somehow. Forks should happen when everything else was tried (or when everyone agrees).

    Still, there is one thing I miss completely in this interview: one of the main reasons of Beryl’s huge success is the fact that Beryl build a community – there is no community source for compiz around at the moment except for a opensuse-wiki entry afaik.
    compiz-quinnstorm provided a forum, something which is a users place (developers use e-mail lists, users use forums), and there was a wiki as well, I think – things I miss around David’s compiz.
    Also, when, as a user, I now want to get an idea of the current development status and the features coming with the next release, there would be no place to turn to.
    So David should really think about the stuff for users he already mentioned in the “podcast”: a web site for easy up- and downloading of plugins with rating systems, discussion sections, roadmap… And there should be an open ear to users with clear needs: from the beginning it was obvious that every KDE user would have strange feelings about compiz because of gnome dependency. That should have been sorted out as soon as possible.

    Ok, a bit much for 2cents, but it is my opinion.
    So at last the most important question: what is your native language, then? ;)

    liquidat

  2. My (2 cents)^2 ;)

    I been standing on the side line for a while and to be honest both parties failed to communicate.

    When compiz was first released, the only real place beginners could go to was either 1.opensuse’s Xgl wiki or 2.#Xgl irc channel on freenode.
    The support came mostly from the community and there was no david around to guide all those helpless beginners.

    I believe around that time quinn was on the ubuntu forums providing support etc.

    It kind of felt compiz was closed and there were serious talks about writing gnome-window-decoration etc all from scratch because there were no comments etc in the code and no idea what some pieces of code did.

    Even some of the best of us had no clue to implement a couple features.

    Eventually compiz.net started etc all. No real attempt made to get david involved more or even ask novell to open the project more.
    note: alot of the new features to compiz back then from compiz.net were mostly useless.

    But I’m glad for the fork, it’s kind of like gnome VS kde.(feauture wise) Although stability is a serious isue with beryl at the moment.
    (like gconf replaced by csm, I mean replaced stable with highly unstable software, they should have waited)

  3. Isn’t this the beauty of free/open source software though? The ability to take the code that you feel affinity for and do with it as you please?

    I personally feel that it is better on many levels to develop a working prototype of software before bringing on the community. However when you have a company as large as Novell bringing that project to light the infrastructure to accept a community should be ready to go. This is where Novell has already shown some level of failure. Where has the Novell contributions and focus for iFolder and Hula been? I don’t see or hear much other than ‘We’ve released these projects to the community’. When you don’t see the major developer of the code using/promoting/leading he project it’s hard to get behind.

    Novell has strong history being able to do OS releases and maintence. Suse as a project has had a large community supporting it over time so getting the OPENSuse project together was fairly easy to get going. Yet as a community application project leader, we haven’t seen much.

    As for the Compiz/XGL fork in particular that is a risk with any project. It would be great if the sides can get back together. There might be more cooperation and acceleration now that there have been issues identified. However if that does not happen, hopefully the two sides can at least feed off the development of the other. It might evolve that one side or the other fails and proves who knew better. Hopefully this split does not destroy a great project.

    I believe that Novell is a great company who is trying to ‘get it’ when it comes to open source projects. There is just a learning curve that I don’t think they realized was there. But this is a lesson and hopefully they’ll learn from it.

  4. Would really recommend a follow up interview with Quinn. Otherwise I don’t think it’s possible to get a realistic view as to what happened.

  5. I think we need to be 100% clear here. I don’t think any of this would have occurred had Novell been more open with the whole Xgl and compiz code initially. Even now Xgl is *STILL* not merged into xorg git master. So let’s not attack Quinn when it’s been clear from the get-go that Xgl/compiz were not done in a open process AT ALL. It was dumped onto the community as a finished project. We have AIGLX because the Xgl code was never done in the open. So, this radio show did not mention this in the first place.

    It was discussed on IRC before this was announced that the fork would occur because of the lack of communication with David. Responses of ‘well, when I get some time’ and ‘well I am currently working on’ were not good enough. You have to be open with your ideas and not code them in the background like Xgl/compiz were done as.

    It also didn’t help that compiz itself did not have all of it’s ‘plumbing’ done (the internal framework) completed that beryl needed very much for their plugins.

    Now that David has become more open, the fork has made compiz somewhat more open and that’s a good thing.

  6. Another thing I should point out is some of the beryl developers are in communication with David on the compiz mailing list. If you follow it.

  7. Something that irked me about the interview was the way the end of the interview was lead to cover some corporate issues such as Novell’s innocence in the process as well as making Quinn’s lot out to be a bunch of unreasonable renegades.

    While I believe the fork is bad for all involved an fervently hope to see a rethink on the part of Quinn, I found this podcast to be extremely disquieting. Sorry Ted. I realise there is a corporate responsibility from your side, but I believe the community can make up their own minds without it being fed with cue cards. I don’t mind the pro-Novell stuff, after all, its your show, but in the spirit of the community you are now participating in, lets keep the podcast as novell *OPEN* audio.

    thanks for the place to air my view.
    ___
    Ted replies by email:
    Hey, got your comments on my blog. I agree with some of it. It did come off too biased. I think we probably need to interview Quinn.

    –Ted
    ___
    Ian replies by email:
    Hi Ted *AND ERIN*,
    I actually regretted sending the comment as I didn’t actually convey
    the fact that I *DO* enjoy your show.  I pretty much listen to
    Lugradio, TLLTS, yourself and 2 or 3 others.  I am extremely jealous
    of my time and I *DO* make a special note to catch up with NOA
    regularly.
    I do think that we all (especially you) want NOA to continue and grow
    and become a community of sorts and I just found that this
    particularly issue was a bit like “checking off the bullet points”.
    However, based on the show, I have re-evaluated my feelings about the
    fork and I agree its a BAD thing.  What David is doing with regard to
    multiscreen and the architectural design is key to the success of
    compiz in general.
    Funny story.  I actually met you at a Brainshare in Johannesburg, but
    literally it was an event where you shook a million hands and we
    didn’t chat.  I think one of the things I remember was you and Howard
    (surname eludes me Taylor??) ribbing each other on the panels.
    Thanks again for the show and tell whoever that sent out the t-shirts
    for the Easter Egg on the Novell Homepage that mine never arrived :(((
    Keep on preachin’ Reverend.
    Cheers

    ___
    Ted replies by email:
    Ian:
    (Erin now copied.)
    I think you conveyed your meaning just fine in your original message. I took it that you were a regular listener who took some time to give us some feedback on our approach on a specific episode. I can’t get upset about that! :)
    May I append some of these emails onto your original comment?
    –T
    ___
    Ian replies by email:
    okay.  no problem

  8. Hi i am just regular user.
    I dont get it.
    Why so much “fuzz” about.
    Lets be real.
    Open is open. Person is a person.Corporation is a corporation.
    Novel probably payed enough money to David for his work and this is good.
    Quin efford is good for other reasons.
    Main conclusion:
    Linux wins.
    Windows goes down.
    I think this is more important.
    Security. Open source. Stabillity. And desktop beauty.
    Can you amagine after some thimes what desktop interaction could be?
    Thank you Novell.
    Thank you David.
    Thank you Quinn/Beryl.
    Future is Linux.

  9. […] But while I read this announcement on the list I started thinking again about the “Beryl vs Compiz” discussion which started when Beryl finally forked away from Compiz. There was an interview with David Revemann, the man behind Compiz. Ted Haeger asked him several questions and tried to show David’s point of view while the media mostly covered the statement of the Beryl people. The interview was quite interesting and covered quite some information I wasn’t aware of, like the fact that Compiz isn’t hardcoded against GNOME with its configuration done through gconf but has a plugin structure where you can exchange the GNOME stuff against some KDE stuff (or Xfce, or whatever you prefer). […]

  10. […] Ted’s Related Blog Post […]

  11. Ted: “I came away tending to think that David has managed the project in a standard open source manner.”

    You’re deluding yourself! Name another open source project where the main developers disappear for a year and then drop a huge wad of uncommented code on the community. It never happens.

    Dave made his choice. And, I agree, he’s absolutely free to do that. However, ask yourself this: just because nobody is contributing patches, does that mean nobody is watching? Would XGL adoption have been higher if the community could have seen it develop, even if it doesn’t contribute anything back?

    I hope Novell learns from this. And, Ted, I’d really like to hear how you can claim that XGL was developed in a “standard open source manner.” It clearly was not!

  12. sb [11]:
    Thanks for your comments.

    You may notice that I did not say “the standard open source manner.” There are many approaches to developing open source. With the thousands of projects out there, you can find examples that run the gamut of development styles.

    Your question regarding Xgl adoption misses the mark, The fork was not from Xgl but from Compiz. Xgl is merely an enabling component–an X server that allows Compiz to work. AIGLX is an alternate that was not mature enough to support Compiz at the time David was working on Xgl. Nat Friedman, the lead strategist for SUSE Linux, has stated many times that we may cut away from Xgl and over to AIGLX when it makes sense to do so. The combined window manager and compositing engine called Compiz is under broad use now, since it works with both Xgl and AIGLX. Counting Beryl users, I’d say that Compiz has been rather well adopted.

    The real difference here is more of a cultural thing than anything else. It would seem that to David’s thinking, a mailing list and IRC are perfectly valid methods of communicating. To Quinn’s and others, you need to have more than that to be truly open. (Interestingly, the Compiz developers apparently use plain old C, whereas I have heard that the Beryl developers use C++ a lot more.) Neither one of these approaches is inherently right or wrong, but certainly you could say that David is much more of a heads-down developer compared to Quinn’s more open, heads-up approach.

    Finally, David took the Compiz/Xgl code backstage for a few months. Watchers or not, serious contributors were not forthcoming, and David did not think that it would cause such a hullaballoo to work on it in-house in order to get it working. What he finally produced was working code that people could start hacking against. Today, Compiz is proven as a solid enough platform that people are hacking against with fantastic results. Best of all, Quinn’s heads-up approach has made Beryl into a spectacular project for for staging innovative (sometimes radical) ways of using the Compiz base.

    So, ultimately, these two projects (which now seem less and less forked) seem to be settling into a healthy relationship.

    –Ted

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Follow

Get every new post delivered to your Inbox.

%d bloggers like this: