[compiz] The future of Compiz

[Sam Spilsbury]

So I probably look naive being the only one to reply to this post, and
add my ideas about this issue, however I do feel that it's been
plaguing the entire project for quite some time.

On Wed, Dec 31, 2008 at 9:09 PM, Kristian Lyngstol
<kristian at bohemians.org> wrote:
> 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.

Definitely. I've been quite annoyed about this ever since David
dropped off the map because he was really our only full-time paid
developer on this and while I do appreciate some of the work that
Danny and Dennis do for core, I could quite easily say that 80-90% of
all commits are something like 'Fix X niche bug, Optimise for Y
hardware, Fit into Z Standard /  Guideline.'

There is nothing big that we are actually working towards as a project
because there is a lack of communication as to what we should be
working towards. There is no page so far that says 'we want A, B, C in
X.Y.Z release', the 0.7.x series so far IMO has really been
wishy-washy 'We haven't release in a while and the code has deviated a
bit from the last release. Let's release again' .

All non-maintenance changes really come out of left field and we get
the situation above.

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

Indeed. When I look at it in retrospect, 'waiting' for those branches
was really not 'waiting', it was just procrastination. I personally
think that compiz++ is a good future for core, but the way it was
developed community-wise was quite poor as some have established. I
don't blame Dennis for this, and really do appreciate the work he has
put into the branch, but having him develop the project in an
explicitly secret manner really says something about the project as a
whole.

Why do we still have 'secret projects?' Haven't we decided they were a
Bad Thing [TM] ever since David pushed 2-3 months worth of commits in
one go breaking absolutely everything and forcing us to maintain
multiple branches as we tried to sort the situation out?

The answer is fairly simple in my opinion. It's that we never agree on
anything, so in order to not be covered in flak by the time their
hands meet the keyboard, people _have_ to develop projects in quiet if
they ever want them to go anywhere. People have limited lives outside
of compiz so in order that anything might actually get done, they just
skip any potential endless argument and get the job done.

I think this is something we really need to fix as a community. Dennis
should have just been able to post a mail to the list saying 'Core is
broken,  I have time to work on it, here is a list of features I
propose', have minimal discussion, have him present to us a prototype
and if it works then we think about merging it. However, I really
don't think that would have been possible with the current kind of
community we have now. Notice how much of the argument so far has been
zealotry about a C++ based core? 'Ohhh, but look what Linus Torvalds
said, he called C++ "bullshit"' NOBODY has taken serious notice of the
other things compiz++ includes, which do fix some really broken
application-wise things about core.

Then after all the endless argument and discussion a conclusion is
hardly ever reached. The conversation just dies and contributors get
so sick of waiting that they just take control themselves, push out
some change without asking and get yelled at by everyone else and a
few people decide to quit the project because 'it doesn't go their
way'. And that is the only we actually make significant progress! What
have we learned from that? Don't make changes because you will get
yelled at by everybody and a few people will quit the project. This
doesn't just happen with the code, but also everywhere else in the
project. We have well-discussed forum reworks that could be applied
tomorrow but have been sitting in the moderator section gathering dust
for over a year.

So we need to start agreeing more. Start thinking about not 'What is
good for my credit within the project'  to 'What is good for the
project at all'. 'I might not like some particular caveat that a
proposal introduces, but will it fix the main issue?'

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

Definitely. To be quite honest, I've abandoned all compiz related
stuff for a while to work on something else because I really don't
know what the deal is with compiz++. If it gets merged, everything I'm
working on will be broken. If it doesn't then I'm fine.

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

That needs to be fixed, but I really don't think its a major problem
in terms of the project stagnating.

What is more surprising though is the fact that we still have two
separate projects. We own both core and fusion now, let's just decide,
either compiz or compiz-fusion.

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

Agreed. New developers need specifications on how core's interfaces
work and just saying 'Look at how other plugins do it' is just lazy.

As for the messyness and longness of code, I can think of a few
example that really need fixing straight away.

display.c handleEvent()
display.c addDisplay ()
screen.c addScreen ()
screen.c All output related code should go in output.c
window.c addWindow ()

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

Here's a real dillema. We're actually forced to consider compiz++
_now_ before anything happens. If we do go ahead and fix Kristian's
problems with the project it's going to bring compiz++ out of sync
with master and we would have essentially missed a huge window of
opportunity again. Unless onestone can maintain compiz++ with compiz
master for a while as we sort things out.

> 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 agree and don't agree with your there Kristian. While I do think
that compiz needs to be stable and out-of-the-way, it really becomes
no fun for other developers once it is that way. Think about it, since
the merge, where the project has stagnated into what it is now, the
number of active fusion and core developers has gone from about 14:
Quinn_Storm, roico, racarr, lupin, nigel_c, Griswold, marex, maniac,
onestone, davidr, moppsy, mikedee, RYX, iXce, gandalfn to 2, Dennis
and Danny with Kristian, Guillaume and Erkin making the occasional
contribution here and there and myself, b0le and OasisGames being the
most outside contributors.

If we only concentrate on making compiz stable then we will continue
to go down this path where we lose developers to more interesting
things. The 'experimental' branch is fundamental to our project,
because it adds the 'iz' in 'compiz'. With that kind of thing, that is
the way we really attract developers. Compiz is becoming more
irrelevant every day without it. When was the last time you saw
'compiz' as a bullet point on a distribution release? When was the
last time you saw 'compiz' on the front page of digg?

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

I think that we need to have this kind of turning point now, before
it's too late. I'm also signed on to fixing up the project as a whole.

To finish, let me end with a quote from an Linux user that really sums
up our situation quite clearly:

"Dramatically ugly, unusable, slow, badly animated and unconsistent.
Open source development without a serious, expert mantainers can
result in chaotic grouth of the project and waste of human resources
into pointless code. The Compiz-Fusion project is certainly the most
representative example of all this"

Source: http://au.youtube.com/watch?v=yLFRgWCEpjk

- Sam

>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.6 (GNU/Linux)
>
> iD8DBQFJW2Dk8aD+nxnFLQIRAjI1AJ0Uf2sICVZ7+kUgwKTGc2xiuCqhfwCeJx+Z
> oN1g+5nIeiPyunjD9MyuKbk=
> =nfnF
> -----END PGP SIGNATURE-----
>
> _______________________________________________
> compiz mailing list
> compiz at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/compiz
>
>



-- 
Sam Spilsbury