i consider kicker to be a software failure.
ok, now that i've laid down the shock line let me back pedal a bit here. a lot of people use kicker and it works pretty well for them. there are few other desktop panel apps out there that are as flexible or offer as many features.
on the other hand, there are a number of highly intractable bugs in kicker. and very few people work on it; in fact it has gone through periods of complete neglect in its 5 years of life. why?
the code is too complex as it grew "organically", feature after feature. and for an open source app, that's all it takes to neuter development. this is because that most open source apps change hands several times over their lifespan. open source code therefore need to be highly transferable between people. how does one achieve that? i'd be lieing if i said i had the answer (i have more questions that answers ;), but here are my current thoughts on the matter:
in open source we work with very small teams of developers with high turn over. these people do it because they enjoy it. our software processes then must support that. how?
clarity: when starting the application, a clear goal must be had in mind. one needn't add in every feature necessary on day 1 (in fact, one shouldn't) but it is absolutely, positively critical to know where you going. because unlike closed source software where code can get uglified over time due to the shifting sands of requirements and still develop successfully simply by throwing more money and (begrudging) developers at it, open source code needs clarity. clear code makes it simple to learn and easy to debug; this makes a coder happy, and happy coders are open source coders.
simplicity: good open source code doesn't get overly fancy in its design. it may be neat to use 10 different design patterns in an ever growing display of coding prowess, but all that tends to do is make it harder for the next person to come along and untangle your thoughts. if the design is clever, there's probably a simpler way of doing the same thing that results in more maintainable code. remember that you won't be the last person to work on this code, and as an open source developer you are likely doing this only a few hours a week so even you probably don't have time to build the eiffel tower of software.
extensibility: if the design doesn't allow for easily adding features without touching the core code, expect the core code to become a nasty dog pile of features as features that people Must Have(tm) are added. a lack of extensibility is a killer to clarity and simplicity, and will therefore in turn damage the project's future. plugins, scripting or even just a cleanly compartmentalized design are key concepts here.
documentation: is there high level documentation for how the app works? how the various classes and components fit together? the purpose of things? if not, then the bar is raised much higher for new contributors. they end up spending a lot of time up front reverse engineering instead of contributing and this will cause most people to just walk away.
reuse vs invention: if there's well written code out there that does what your software needs, use that code. if it isn't exactly what you need but it's close enough, let go of the perfectionism and don't reinvent the wheel. and for goddess' sake don't fork the code if you need to adjust it a bit; fix it upstream so we don't end up with N slightly different flavours of the same component. however, if the best thing out there isn't a good match, don't try and shoe-horn it in (the use of kioslaves for imap in kmail is a good example of this IMHO).
make it easy to contribute: be willing to accept patches. write unit tests so it's easy to see if a patch breaks something. ensure the code is clear and documented. today's patcher may be tomorrow's maintainer. dole out the praise when its due; have fun.
make it hard to dump crap code: be willing to reject patches because they suck. explain why they aren't good enough, and even be ready to help get them into shape because that investment may result in a good, long-term contributor. but don't accept every patch just because it gets emailed to you.
kicker has or does fail on every single one of the above items. that's why i've said it's a failure, and that's why so few people work on it. i fear for both kontact and evolution because from what i've seen they too fail on most of these concepts as well. ditto for kdevelop. this is not a slam on the developers involved, i just don't think we were all that aware of these issues and were too busy (and having too much fun) creating a byzantine empire.
on the flip side, if a code base accomplishes the above it can get by with fewer developers, survive team turn-over better and will attract more developers over its lifetime.
as for kicker, i'm going to try and not repeat that saga in kde4. i'm tired of spending days and days hunting bugs down by myself and trying to figure out how to add needed features without breaking anything else. i want to have fun again. =)
if a group of crows is called a murder, i couldn't think of a better description for the herds of thoughts that race around my head.