[compiz] The future of Compiz

Where are we going?It's time to start thinking ahead and really figure out how to make Compizsurvive, specially in lieu of Dennis' suggestion.The reality is that there has been the equivalent of no progress since themerge. We've basically only been in maintenance mode. The reason for this,from my point of view, is a complete lack of direction and leadership.We've constantly been waiting for something that will change everything,and whether we call it an object framework, nomad or Compiz++, the realityis that all these branches are counter-productive, regardless of how fun orflashy they are. If we are to have a healthy development environment, and any hope ofbringing Compiz out of a constant alpha-stage, we need to have cleardevelopment goals and a way to cooperate. Before somebody puts 6+ months ofdevelopment into their work then present it as a final solution. Our current situation is rather dark, but not without hope. We have verylittle development power, and we are risking loosing even more, and unlessI'm missing something obvious, we haven't seen a single new core developerthat contributes significantly to master, since the merge. We have,however, lost a few. We MUST turn this trend around if Compiz is tosurvive.So why do we loose developers? I see a few important reasons:- The project has no goals, and essentially all development and design is done as a solo race. There's no way to know whether you can work on something without loosing your work because some obscure branch gets merged.- We have an inconsistent organization. Two bugtrackers, one isn't really cared for. Two places to find code. Some plugins are here, and some other plugins are there. Two development mail lists. Messy.- The code is undocumented, specially core, and not particularly pretty. Even new code is added using this same style of no documentation and functions that do more than C functions should do. This is not something new, but even people who realize the problem are ignoring it.It is my honest belief that we should focus on these three major problems,before we do anything. The first step is to decide what to do with thethree branches we have going. And we need to know exactly what benefits anddrawbacks each branch have, how compatible they are and how the authorsenvision that they will be maintained. This is where the authors/owners of those branches should come together andstart explaining their thoughts about merging and compatibility andmaintainability. If not, we really have no other choice but to considerthose branches forks of Compiz, and move ahead based on master.It is my wish that we have clear goals for every major release, and findingthose goals should be the top priority after a stable release. For eachpoint-release in a development series, we should also have a clear goal.This will make it easier to predict releases and for developers to help.And it's not that hard to figure out. There is also a fourth point that's causing us problems.- Compiz is a research project. Essentially, there's been very little work to bring Compiz into a statewhere it can be considered truly stable. We need to stop using Compizmaster as an experiment. Examples of this is XCB and objectifying Core andPlugins prior to the object framework being ready. That's if we ignore thebranches.I've been very passive since the merge, as I was quite outspoken in myobjections, however, it's time we actually talk about Compiz, Compiz Fusionand project management. I am ready to do the boring development work, butnot until these management issues have been sorted out.- Kristian-------------- next part --------------A non-text attachment was scrubbed...Name: not availableType: application/pgp-signatureSize: 189 bytesDesc: Digital signatureUrl : http://lists.freedesktop.org/archives/compiz/attachments/20081231/778efeb1/attachment.pgp