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.
Our 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.
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.