[compiz] The future of Compiz

[Kristian Lyngstol]

Where are we going?

It's time to start thinking ahead and really figure out how to make Compiz
survive, specially in lieu of Dennis' suggestion.

The reality is that there has been the equivalent of no progress since the
merge. 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 reality
is that all these branches are counter-productive, regardless of how fun or
flashy they are. 

If we are to have a healthy development environment, and any hope of
bringing Compiz out of a constant alpha-stage, we need to have clear
development goals and a way to cooperate. Before somebody puts 6+ months of
development into their work then present it as a final solution. 

Our current situation is rather dark, but not without hope. We have very
little development power, and we are risking loosing even more, and unless
I'm missing something obvious, we haven't seen a single new core developer
that contributes significantly to master, since the merge. We have,
however, lost a few. We MUST turn this trend around if Compiz is to
survive.

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 the
three branches we have going. And we need to know exactly what benefits and
drawbacks each branch have, how compatible they are and how the authors
envision that they will be maintained. 

This is where the authors/owners of those branches should come together and
start explaining their thoughts about merging and compatibility and
maintainability. If not, we really have no other choice but to consider
those branches forks of Compiz, and move ahead based on master.

It is my wish that we have clear goals for every major release, and finding
those goals should be the top priority after a stable release. For each
point-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 state
where it can be considered truly stable. We need to stop using Compiz
master as an experiment. Examples of this is XCB and objectifying Core and
Plugins prior to the object framework being ready. That's if we ignore the
branches.

I've been very passive since the merge, as I was quite outspoken in my
objections, however, it's time we actually talk about Compiz, Compiz Fusion
and project management. I am ready to do the boring development work, but
not until these management issues have been sorted out.

- Kristian
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://lists.freedesktop.org/archives/compiz/attachments/20081231/778efeb1/attachment.pgp