It would be nice to have Flattr buttons integrated into the PackageKit UIs, so that users could make donations to developers of packagers that they liked. Flattr (Flattr.com) is a micropayment provider that uses a cake-slice model: a Flattr user pays in an amount of their choice every month (minimum 2 Euros) and then clicks on flattr buttons on items around the web and elsewhere that they like and want to support. At the end of the month their amount is divided equally between each thing they clicked on, and a Flattr fee, currently 10%, is deducted from each payment. (Disclaimer: I work for Flattr.) There are two questions here about how this should be implemented: 1. Should it be implemented as a plugin, or into the core? 2. How should PackageKit discover a flattr button for an item? Should it fetch the web page listed for a package, if any, and look for a flattr button on that page, for example? That technique would work for the Fedora nbd package, for example. We'd be happy to either send a patch, write a plugin, or recruit someone from our community to do the work. But first I wanted to file this request for enhancement to see if anyone has any comments or suggestions.
(In reply to myself) > It would be nice to have Flattr buttons integrated into the PackageKit UIs, so > that users could make donations to developers of packagers that they liked. ^^^^^^^^^^^^^^^^^^^^^^^ oops - that should say "developers of packages", sorry.
I guess there are two problems sets here, three technical and one legal. From a technical point of view, it's quite hard to identify a single developer from a package, as the package may have an aggregate of applications (for instance, the gnome-games package has about 25 developers. Another problem, is that if we install an application by default, for instance libreoffice, then the user does not have to explicitly install the application and no opportunity is give to flattr the developer. This actually puts the "best of breed" applications at a loss, so to speak. The final technical problem is how to map an application to a final development team. I put emphasis the word team, as for instance I'm the main developer of PackageKit, but I'd feel terribly guilty about taking 100% of the share of flattr payments when it's probably only 70% my own work. Even if the flattr developer was listed as X-Flattr-Developer in the .desktop file and enough application authors agreed to add this to their desktop files, then it still leaves out the non-desktop software, like vim, NetworkManager, upower etc. Putting it in the package makes this distribution specific and isn't probably a great idea to let the packager decide who the "recipient" should be. The final problem I see (IANAL) is that if a developer takes payment for a service in many countries then that implies a certain amount of legally binding responsibility and support. It might be difficult to negotiate this especially for the big corporate distributions that really want to avoid the implicit contractual clauses. I think the workflow needs to be looked at by some user interaction designers, as post-install probably isn't the time you might want to flattr the developer, it might be after it's just recovered your CV from a corrupted .doc file. In this way it's probably better to have a flattr application that just lists the installed software on your computer and allows you to flattr the developer if they have _opted-in_ to the service. I think it would be quite easy to maintain a shipped database of flattr usernames to projects, and would work better than any heuristic. Such an application can easily *use* PackageKit to be available on all distros, but I don't think it makes sense to integrate it in PackageKit itself.
Adding self to CC if not already on
We moved the upstream bugtracker to GitHub a long time ago. If this issue still affects you please re-create the issue here: https://github.com/hughsie/PackageKit/issues Sorry for the impersonal message, and fingers crossed your issue no longer happens. Thanks.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.