Donations for free software through Software Center

Registered by Steve George on 2010-10-21

Discuss adding the capability through Ubuntu Pay and the Software Center for users to donate to free software that is within Ubuntu. Technically this will cover all software that is within the archive that is not commercial and consequently covered by the sales capability.

Blueprint information

Status:
Not started
Approver:
Rick Spencer
Priority:
Medium
Drafter:
Stuart Metcalfe
Direction:
Needs approval
Assignee:
Stuart Metcalfe
Definition:
New
Series goal:
Accepted for natty
Implementation:
Unknown
Milestone target:
None

Related branches

Sprints

Whiteboard

Specification (someone with permission should make this the specification URL): https://wiki.ubuntu.com/SoftwareDonations

Work items:
[mpt] (USC) Define UI for donations in app description page: DONE
(USC) Define metadata format (for supported donation apps) and how the data is provided: TODO
[mvo] (USC) Add button to SC app description page for supported apps: POSTPONED
[mvo] (USC) Display donations metadata on description page for supported apps: POSTPONED
[mvo] (USC) Initiate donations workflow when "Donate" button clicked: POSTPONED
[mvo] (USC) Add menu item to manage donations: POSTPONED
[mvo] (USC) Open dialog to manage donations when "manage" menu item clicked: POSTPONED
[mvo] (USC) Display "donated to" in app description page if user has donated to app (will change "Donate" button?): POSTPONED
(server) Web contact form for app owners to apply for donations: TODO
(server) Registration of apps/recipients in web UI (admin only?): TODO
(server) API call to return apps which can receive donations: TODO
(server) API call to donate to an app: TODO
(server) API call to get donation metadata for app: TODO
(server) First visit workflow: TODO
(server) Define models for donations: TODO
[mpt] (server) Define "(create or) top-up 'pot'" workflow: POSTPONED
(server) "Top-up 'pot'" workflow: TODO
[mpt] (server) Define "confirm donation" workflow: POSTPONED
(server) "Confirm donation" workflow: TODO
(server) List previous donations (management dialog): TODO
[mpt] (server) Define "Cancel donation" (if not yet paid) workflow: POSTPONED
(server) "Cancel donation" (if not yet paid) workflow: TODO
(server) Finance report generation: TODO
(server) Cron script to process unused donations: TODO
(dev) Create config branch: TODO
(dev) Buildout/fabric dev setup: TODO
(dev) Packaging prep for deployment: TODO
(dev) Set up translations infrastructure: TODO
(dev) Deploy staging app: TODO
(dev) Deploy production app: TODO
(dev) Add ISD scaffolding (South / oops / logging / web theme): TODO
[allison] (biz) Confirm with Google that they're OK with us using GSOC approval: TODO
(biz) Finance process to pay recipients: TODO
(biz) Define finance report criteria (data, frequency): TODO
[slgeorge] (biz) Decide what happens with unspent donations: TODO
[slgeorge] (biz) Check with legal about any liabilities: TODO
[slgeorge] (biz) Organise any contracts we need people to sign: TODO
(biz) Define process for registering apps: TODO

----

[Copied from Gobby document: packageselection-desktop-n-donations-for-free-software-through-software-center]

Agenda
 - Intent
  * accept payments through software center for free software in the Ubuntu stack, and have those payments make their way to the developer
 - Proposed model
   * token model: prove you can modify package/code/whatever before receiving $$$
     - Use package homepage from package file, and inspect that home page for token?
     - Has other problems (this is open source software, after all)
 - Implementation elements
 - Issues
   * Donation/Software registration

 * the word "donate" sometimes implies "charity", but these are not charities
   - or are they? (Gnome Foundation, etc.)
 * could donate to server application, etc... via the web or a cli
 what about when an app doesn't have a clear person to donate to?
  option 1: don't donate
  option 2: take $ for all apps and donate to a single place
  option 3: do a general donation
  Developer Portal could help define who is the person
  - If we restrict our initial implementation to packages with very clear answers and existing 501c3 foundations, then someone would soon make a 501c3 foundation to handle "the rest" -- so we may not need to worry about individual donations to individuals

Sourceforge lets the maintainer specify a single person, as well as a portion to other projects (eg upstream library)/general foundation

rickspencer3 feels strongly that we should only accept donations for projects with clearly defined "end points"

we could add a "I would like to donate" button

we would need to figure out how to change the ability to pay on the server side? would there be meta-data external? a token in a package?

Possibilty to make Donation per feature ?
 a specific feature inside a specific package/app needs X money, people donate that sum and the one which implement it got the money.
People tend to donate more if they know the thing will happen !
  * donate for a potential future feature ?
Many people say that they will pay for the one who will make Games working in Linux (Add a Gallium StateTraker, etc..), but now there is no model assuring that when they will pay they will receive something.

All this needs a model to handle people requesting specific features, other people dividing that feature into sub-parts with how much time it needs to be implemented, other people validating the process and then the new state of the feature.

  This is traditionally called "Bounties". Probably a different discussion
 So it should put in the future pipeline.

How do you prove that you own assets related to the projects?
 * we could check the defined homepad and see if there is key there?

Provide fundraiser-like (justgiving.com) donation messages.

Unresolved questions
 * how to have people register as project owners to receive funds
 * how to respond to and resolve disputes
 * how to pay $ out to the parties
 *

(?)

Work Items