Brainstorm

If [stars] => 3 then karma = [stars] * [votes]

Apps with 0 / 2,99 stars don't generate any karma since these ratings are considered low / bad.

The total amount of karma points received from an application through downloads, valoration, etc would be divided in equal parts among the maintainers of the application. Maintainers are identified at http://maemo.org/packages (the maemo.org admins might know a better way to find out who are maintainers).

The equal distribution among maintainers is probably the most fair and simple way. Maintainers have usually full permissions on packages and code base: usually these permissions are not given lightly just to anybody. It also balances efforts: a single developer of a medium-popular app would get more or less the same points than a maintainer of a larger team of a top popular app.

What about contributors not maintainers? Let's not complicate things too much, specially not in the beginning. No karma for them, contributing to a project should be gratifying in itself. This way we also avoid pressure to the existing members of a team from newcomers thirsty of karma points.

This seems like a more fair karma distribution, since there can be added developers with no contributions. Further the project admin should be able to additionally move some points between the developers up to a certain extent (not all of the points should be distributable).

Of course this a more complicated approach and probably should not be implemented from the start.

This proposed solution is combining solutions #2 and #3but factoring in versioning. The aim is for better apps, so if the developers themselves tell end-users to rate their apps as well as provide feedback, ratings and comments becomes then help improve the apps. When rating apps, it should be by version (major release only). A version 1.0 of an app can get 3 stars but on the next major version release, say 2.0, it can get 5 stars. As for distribution of karma, it should be by version (major release only) too. Version 1.0 karma can have 3 developers sharing, but for version 2.0, there can be 5 developers sharing.

When measuring just downloads, there is no indication how many users liked the software and how many have uninstalled it. When a new version is released, however, there is a spike in downloads that shows exactly this. The volume of the spike is the approximate numbers who still have the application installed. This way we can measure an active userbase, even if in an indirect form and use that as part of the karma calculation. Yes,  some people never update, but the point is that the metric will be equally wrong on all projects, so you do get a realistic comparison of userbases.

A list of categories could be established that would modify karma value for a package. The categories could be 'Maemo compatible' (as something coming straight from Debian, for example), 'Maemo port' (something that has been hildonized and adapted for use in line with other Maemo apps), 'Designed for Maemo' (something that has been written exclusively or primarily for Maemo). Of course more categories could be introduced to make the scale more fine-grained.

As the solution title says. There's several reasons why this might be a good idea, and a few why it might be bad.

Pro(s)

1. Ohloh have been thinking developer karma for longer than maemo have or will. It's their expertise domain and developers acept the ranking system.
2. A lot of the developers I know would consider ohloh competitive ranking a stronger incentive than a separate maemo community karma ranking simply because of the sheer number of people on ohloh.
3. I can't speak for ohloh but I imagine considering their raison d'etre they would be happy to get maemo development statistics piped into their system.

Con(s)

1. A quick skim of Ohloh's API documentation suggests that existing facilities are mainly for data retreival. Ideally, hooking the maemo development community into ohloh would be a more bidirectional data flow. This solution is probably going to require more than just the right code. Actual people will have to talk to actual other people (shock, horror!)

Implementation details

1. It would be good if developer karma rankings could be seen on ohloh against the whole developer body and also against the subset which is the maemo developer body.

In similar vein, Stackoverflow.com and superuser.com could also be hooked into to provide facilities similar to, say, launchpad's answers.

There's probably more good and bad reasons around this proposed solution but it's a Sunday morning and I've only had 2 coffees.