Donations
Research and design page for adding donation/payment support to Software.
Goals
- Enable application developers to generate revenue from their software.
- Enable the GNOME Foundation to generate revenue.
- Don't cut off potential revenue streams for the future.
Restrictions
- Limited administrative/financial capabilities on the GNOME side.
- Not all applications have the financial/legal apparatus to absorb funds?
Research
Existing Free Software applications that accept donations:
|
Paypal |
Paypal subscription |
Cheque |
Bank transfer |
Credit card |
Bitcoin |
Flattr |
Yorba [1] |
X |
|
X |
|
|
X |
|
Inkscape |
X |
|
X |
|
|
|
|
GIMP |
X |
|
X |
X |
|
X |
X |
VLC |
X |
|
|
X |
|
X |
|
Krita |
X |
X |
|
X |
|
|
|
Mozilla [1] |
X |
|
|
|
X |
|
|
Blender |
X |
X |
|
X |
|
X |
|
Ardour |
X |
X |
|
|
|
|
|
[1] Donations seem to go to the organisation rather than for a specific app.
Application Developer Perspectives
Application developers - we want to hear your thoughts on this. Feel free to add comments here or to contact us by other means.
From IRC: "GIMP as a project likely leans more towards making donations possible/easy, rather than interaction flows making it seem mandatory".
Discussion
Issues to be resolved:
- One time payments vs subscription models.
- Pay on install?
- Can projects redirect funds to other causes (eg. Scribus suggests giving money to LGM)?
- Should applications be required to explain what they will spend the money on?
- Pay per app, or one payment that is divided?
- One integrated system, or redirect to application websites?
- What about apps that are pre-installed by distributions?
- What about apps that are part of larger projects (eg. KDE, XFCE)?
- Will distributions want a cut?
Payment Models
Possible payment models to consider.
Mandatory donation at install time
Suggested donation at install time
Suggested donation after using the app for a while
Mandatory donation after using the app for a while
Flattr Integration
One subscription, divided between installed apps and GNOME