In that case, that might be more dangerous then. There is a chance that the developer might stop improving an app if the peak is already high, despite a lot of requests to add more features. The result: stale apps.

Another thing that might happen is the developer(s) might release that same new app with new features added and appending a 'pro' or 'ultimate' to the app name. The developers get to preserve the high peak on the old app, and get new karma on the 'pro' and 'ultimate' versions.

I believe in rewarding the developers who continuously improve their apps. If they get a million karma because they keep improving their apps, then good. They deserve it.

I'm not sure I follow... Someone is afraid to post a new version of his software because he fears more users might have uninstalled than installed it in the meantime ? That almost sounds like a psychological problem...

Now, if someone wants to abuse the karma system, he will do so, you can't stop karma wh*ring, no matter what system you come up with, especially if the karma system is public and the users are anonymous. The whole thread started off because now we can't tell important projects from unimportant ones. Not to mention there are a LOT simpler ways to fake karma than such constructs.

But this is the problem, what's the non-karma-abusable measure of app improvement, if it exists at all ?

How about project karma has an expiration. After a set time development karma would expire maybe a year. this would stop people from sitting on a project and not updating it because their karma would go away. Equally karma from blogging and helpful posting could also expire. If a user used to supply a great deal of information but after a new device or os upgrade comes out becomes very quiet the high karma currently does not reflect the users activity. Questions directed toward a quiet user based on current karma may not get answered with the same speed or quality of response.

I don't think that karma should be subtracted just expired hopefully this would avert negative karma.

If there is negative karma this to should expire. Maybe after a longer time than positive karma expires. people sometimes do bad things but should have the ability to re-hab and not have bad karma follow forever.

If a developer's primary motivation is to accumulate karma points then their apps will get stale no matter what the formula used. I don't think there's much risk of that though, as most reasonable developers would value their time much higher than a potential device discount or weekend attending talks in Amsterdam :-)

I would like to see some more quality (as opposed to popularity) metrics used however. User ratings certainly, and also things like ratio of open/fixed bugs, code checkins and so on. Yes, all of this can be "gamed" to an extent, but let's please assume that someone who bothers to climb the steep learning curve, negotiate the autobuilder etc to publish an app does so because of a genuine desire to scratch an itch and contribute. There are far easier ways to get karma points after all.

Here's the thing. I'm suggesting to bring in the end-user to reward the developer(s) so apps keep improving. If you provide a solution that somehow stops the development of the app, even how small, then that's a potential problem.

I like how the site versiontracker works. Users provide feedback for each version, and each version gets to be rated (e.g. this). You can immediately see that the system works. The only problem is how to incorporate karma to it.

Is there a successful system that rely on peaks?

There was a scientific paper of this phenomenon in the latest Open Source Systems conference (OSS 2009). Here is the reference:

Wiggins, A., Howison, J. & Crowston, K. 2009. Heartbeat: Measuring Active user Base and Potentieal User Interest in FLOSS Projects. In Boldyreff, C., Crowston, K., Lundell, B. & Wasserman, A.I. (eds.): Open Source Ecosystems: Diverse Communities Interacting, Proceedings of 5th IFIP WG 2.13 International Conference on Open SOurce Systems, OSS 2009, Skövde, Sweden, June 2009.

Agreed, and maybe the best way to keep karma current is to constantly calculate it within a moving window, say 1 year. If people cease to be active, their karma will naturally decline... and this also ensures that karma reflects currency.

The ratio approach makes the most sense to me and should be used where ever possible and practical. So maybe a download metric incorporates percentage of views converted to downloads? Or maybe the first released version of an app is solely a benchmark, and karma is applied to ratio (and/or number) of updates after initial download? Surely loyalty to a developer or app is an excellent indicator of quality... and addresses the uninstall question to an extent.

May I just throw in a number of criteria that may be useful or not. I'm not very good at doing the maths in terms of karma=(a*b/17)^2+(e)*f, and I'm also not sure if i got the idea of what "developer karma" should be... anyway:

Port vs. native development
I once ported a command line application and used it on my device without publishing it. When packaging and extras became an issue (developers told us here that the whole process is broken and oh so difficult), I tried if I could bring it to extras without prior knowledge of debian packaging. I could. An I went the whole way and included it in /downloads/OS2008/. When I asked on the mailing list who I should name as the author of this package, I basically got "whoever you want to get karma for it". Now I wanted to be named as a contact person, I wanted receive karma,... but still: Is it OK to apply the very same developer-karma calculations for someone who'd only re-package an existing tool without even touching the source code? Maybe using two fields in the downloads page ("author" vs. "contact") could be a starting point to change this.

Dependencies
What about packages that are listed as dependencies of other packages? Say I port either a library (or an interpreter for a new language...) to Maemo, and 359 applications start using this library (or interpreter). Most probably nobody would ever download it from /downloads/OS2008/ or comment on it, but without it, 359 high-rated apps wouldn't have been possible. So: Count dependencies in packages.

Rating vs. downloads vs. comments
Relevance is an underdefined term. Whats relevant? Is a game relevant because it has high download rates? Is mplayer relevant because of its download rates... or is it relevant because it pushes the boundaries of the platform? I don't know. - I do believe, though, that counting only the average rating or the number of downloads or the number of comments given for this application will probably give a wrong result.
Downloads can be wrong for a number of reasons already discussed in this thread
Rating is a most irrelevant figure as long as it's the average rating. I give my own application 5 stars and have a higher multiplier than a really popular app that users find minor bugs in and that therefore ends up with 4 stars.
Number of comments could be nice to throw in. How many people think your application is worth writing about? (These could be, of course, all bad reviews like "What's that? It doesn't even install!", so it needs to be just one factor of many)

The penguinbait-effect
There must be a way to gain karma by doing things that don't quite fit the "install a deb from extras" scheme. Many interesting concepts that show how versatile the whole ecosystem is will not, cannot or should not be deployed to end users this way. Still, I'd personally consider them at least as (if not more) relevant than a game that gets downloaded 2000 times a week.
We used to have thumbs up/down on the maemo.org profile pages. This never worked for karma, IIRC, and is now disabled. How about adding a way for developers to add specific projects to their profiles (name of project, link to project homepage, short description, no screenshot) and allow others to give karma via thumbs up?

Fire exit
Karma calculations are one thing and will always be "wrong" for some people, no matter how good the system actually is.
The developer device program is another issue. It can be, but needn't be exclusively tied to karma. You could, say, make it public that a list of x developers will receive a discount based on their karma. Afterwards, those who're not part of this list should be given a chance to be elected by popular outrage ... you know, any developer should be able to stand up and say "hey! community! i think i do deserve it for my projects, but the karma system doesn't work for me. you know me. you love my projects. vote for me at...". we're missing the "at ..." for such a community-ticket.

non-developers
During the N810 device program, I read:
Is this still valid or will we fall back to developers only again? Just confused because this thread is about developers only. (And no, I'm not asking for myself... I live in a country without a Nokia online store, so I wouldn't be able to use any discount code, anyway.)

You realize that if you go through with this chain of thought it means development should NOT relate to karma ? If you have karma, you have competitiveness, and if we really want to hair-split that in itself can result in scenarios that stop development (isn't this the crux of the penguinbait conundrum is this very thread ?). As Texrat pointed out, there is no 100% scoring system, the best we can do is come up with something that works in as close to 100% as possible while covering as many scenarios as we can.

No idea, it was just a random thought (which apparently popped up in other places, too). This changes the question into is there a system that relies on peaks and failed because of it ?