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.
Subscribe to:
Post Comments (Atom)
9 comments:
Amen, brother. You get kicker easy to modify and I will start working on it. Right now - whoaaa - it is damn confusing for someone like me to "get" to fix a small problem I might have during a plane flight.
Kicker still rocks, btw. Thank you.
Could you please clarify why you think Kontact and KDevelop are affected by these? I agree that both don't fare as well as it'd be possible in some of the issues you mention. But generalizing them as software failures just like Kicker is very strong meat you should really explicate more than this.
>Could you please clarify why you
> think Kontact and KDevelop are
> affected by these?
sure.
neither have as active development as they could or should because both are rather complex internally (i've hacked on both kontact and kdevelop, so feel mildly qualified to say this)
for the user, both are complex and often just plain baroque (how many times have i been asked how to add a file to a project in kdevelop? or how to adjust any number of basic features in kontact?) and the current releases have lots of "fun" bugs (this is not my opinion but is based on talking with many people from california to germany over the last few months)
there are also deep design flaws in both. for example, in kontact it won't check your email until you load the mail part by clicking on the icon; this is because the data retrieval and the UI are connected and the UI is not loaded until needed (for obvious reasons). in kdevelop it's mostly the absurd amount of copy 'n pasted code and duplicated functionality between modules.
now this is a very harsh review of both of these apps, i know.
the good news is that a lot of people use them every day and love them both. =) in that sense they are successful.
as open source projects, however, they are teetering on the edge of disaster. look at the development activity (or lack thereof) in these two projects to see what i mean.
and this isn't because the hackers involved are subpar, it's because the software does not lend itself to being developed the way open source software gets written.
what do you think?
I was always under the impression that Kontact was a fairly thin shell around all the applications it brings together.
I'm sure you know of nastier bugs, but not checking email until the UI is loaded is a tiny concern in my books. Most people will load kontact to display the email component by default anyway.
In any case, if these applications are disasters, kudos to the developers, because I sure haven't noticed.
Also, do you have any thoughts on how one could go about fixing the problems? (short of a complete rewrite, which may be feasible for kicker, but not exactly for KDevelop.)
@leo
the apps are not disasters from a user's perspective.
they are problematic from a development perspective.
those are two very different things.
> I was always under the
> impression that Kontact was a
> fairly thin shell around all the
> applications it brings together
it is. several of the apps it wraps, however, suffer from the problems i noted in this entry.
> but not checking email until the
> UI is loaded is a tiny concern
> in my books
it affects all parts in kontact, not just email. so you don't get notified of new feeds until you actually select the feeds icon. this is one of the reasons you don't see kontact as the default in certain linux distributions (i kid you not)
so the question becomes: how easy is this to fix, and who will actually do the fix? and that's the rub. the fix is non-trivial and there aren't many people around who can or will.
we've obviously survived this long with the current state of affairs. but we can do a LOT better.
I find your analysis of application design and its ability to encourage or discourage contributions by outside coders to be quite astute.
I also think it is worth considering what projects successful in keeping active development are doing right. For example, amaroK is getting lots of contributions from non-maintainers – could this be just because music players are in vogue, or is something about its organization making it easier for outsiders to improve it? If the ladder, could other applications be molded to follow the same model?
"open source code therefore need to be highly transferable between people."
This is extremely important in the open source world, and I think the people who are starting to get it are the people who are asking for official high level languages for desktop environments.
If you would allow me to use my own personal bias as an example, Python offers high readability and concision, and a set of built-in useful abstractions that really reduce code length. Other languages of similar "level" (ruby for example) achieve similar results.
Even small projects written in C or C++ grow in LOC dramatically very quickly. Pass the code around a few times and you get something that isn't grokkable anymore in any realistic ammount of time.
Even with the abstractions in Qt, which are excellent, doing simple things to high level objects is not simple when using C++. When I notice that this is the case on any project (doing low level things with high level languages are often similarly infuriating), red flags go up.
When I write simple util's for myself using Python, I barely ever see a signal handler that has more than 10 LOC, because dealing with the high level objects in my program (gui elements) at an equally high level. I was able to write a decently complex piece of ad-hoc network visualization software using Qt with about 2000 LOC in Python; just getting the interface off the ground (particularly, a custom canvas object) in the initial C++ implementation was 1500 LOC.
Your question was, "How does one achieve that?", referring to passing around open source code. I think that the answer we will eventually agree upon will be higher level languages.
Speaking about KDevelop, or more specifically, KDevelop's debugger that I work with, there are just two things that are really missing -- comments and tests.
With enough comments, I could understand everything in no time. With enough tests I could refactor any design into another design in no time (and be sure that new design does not break things). And it would not matter if existing design uses stack of 10 design patterns, or is not extensible, or is complex, since that all can be changed.
I'm afraid it will take a long time for the situation to change. After all, even in Qt, comments for methods sometimes leave much to be desired.
I really don't think kicker is a failure as an open source software. It used had a somewhat complicated code (for me) but especially in 3.5 branch I really like it. It provides interfaces for other projects to use (applets and so). It's highly configurable for users. It's scriptable. But I won't insist in on my arguments, as you are the maintainer ;).
I could give very little efford for bug hunting on kicker on last months. But it's because of the busy times (at my work and personal), not because it's hard to contribute on kicker :). I'm pretty sure that I'll be more active real soon :).
Btw, you really do a very good job maintaining and promoting kicker.
Post a Comment