Posted on 2007-02-12
There have been a lot of discussions lately about the future of Beryl, and our relationship to Compiz.
Let me just start this by saying that I appreciate the work David has done, and continues to do with both Compiz and now X.org. He has an immense amount of knowledge, and he is responsible for getting us where we are today with a proper composite window manager. And he keeps giving to the community through is code. For that, I thank him. I do not belive, at this point, that anyone on the Beryl team has that same amount of knowledge of X and related libraries.
Beryl is very much a direct result of his work. We are gratefull for that.
So why the fork? So far there isn't really a significant difference between Beryl and Compiz, so did we do it just to further our careers? Did we do it because we want the glory? Did we do it out of ignorance? Did we do it because we prefer IRC over mail? Well, I wasn't on the team at the time of the fork, I was, however, a user of Compiz, and a user of compiz-quinn. And I have been a member of the free software community since 1999, and I am a true beliver. I have also been programming since 1992. At which point I was 9. I have not been directly involved in free software as a developer on some elses project until I started working on Beryl. So what do I know?
Well, I am a purist. My code is probably far from perfect, but I want it to be in all possible ways. I strive to master whatever I spend my time on. And I love knowledge, and I respect it. But I also realise knowledge is not everything. Attitude is just as important. Where would the free software community be without the attitude of the folks who started it all? Nowhere.
This brings us to the core of what I personally consider the main reason why a fork was necesarry. Attitude. Compiz is developed as a one-man project, and that could be a good thing, but it would require that it is done because of an attitude. Not because it is convenient. If the code was clean and smooth, I would surely have no problem understanding why someone would want complete control over every part of it. They would want to make sure it remains clean. However, this is not the case with the compiz code, nor is it the case with the Beryl code. There are som ingenious solutions in Compiz and Beryl, but the implementation is not pretty. There are functions that makes you forget C is a procedural language half way through reading them, it looks more like a dirty script. And these are central and crucial parts of the code.
When you add to the mix that this code is virtually undocumented, and only one person really knows what the code does, you have a problem. Sure, it's free software so you can read the code and EVENTUALLY you'll figure out how it works, but we all know "it was tough to write so it should be tough to read" is an example of a bad attitude. A really good programmer documents his code, because he knows it will help him in the long run. It's not just a way of helping others, it's about helping yourself. Because if you document your code, others will help you improve it, and thus, you help yourself.
Getting back to the core issue: How does this affect Beryl?
What I want to do with Beryl is clean it up. Make it better. I want to use the good ideas David had, and implement them properly. Make the code sustainable over time. Open it up to other developers who might not have the entire day to decode a single function. I want to increase the flexibility of the code, and make it more robust.
And I intend to do that. It takes time, however. And I can't spend all my time working on Beryl, I have school and other projects going on too that requires my attention. And I want to do it right, and to do it right, I have to cooperate with my teammates. Luckily, trunk has been unlocked, and we've slowly started. We are trying to reach an agreement on what specificly we want to do. We all know we want to clean up, but that's not really specific enough.
I belive that the Beryl 0.2.0 release will not make or break Beryl. Surely there will be flames and rants about how good/bad it is, all depending on who's writing. But in the end, I don't belive it matters. The real work will happen in 0.3.x and the future releases. If people still sais compiz/beryl in the same breath by the time we release 0.6.0 for instance, then I'll be worried. Right now, I say let people criticise us all they want. The Beryl team gets blamed for a lot of things we are innocent of and some things we are guilty of, but what will that matter if it turns out to be a great thing in the end? We get blamed for lying, stealing and beeing unethical. We also get blamed for what others say about us. If someone sais that beryl is more innovative than Compiz, then suddenly Beryl are the bad guys for creating a false impression of Compiz. I don't want to say wether we're more innovative or not than Compiz. David, surely does some amazing things that I'm gratefull for, like working on input redirection in X.org. So far, Beryl has mostly focused on Beryl. Our plugins haven't been that radical and most of them will still work on Compiz. So no, we're not really that much better yet, are we?
I can understand when others question the reason for our existence, but I say give us time. So far, we've mostly worked on getting our act together and cleaning up our OWN code, and getting some structure in the project. We haven't even started with the real fun. It takes time to get to know the source code of a program, at least a couple of months if it's big. We've finally had that time, and I at least finally feel confident when working on core. I can start doing what I set out to do.
So please, flame my comments, but remember: Rome wasn't built in one day, just like Beryl won't be built in one stable release.