Ik heb een nieuw donaties systeem bedacht voor ubuntu. Ik heb het voorstel in het Engels geschreven, voordat ik het op een mailinglist gooi wil ik graag jullie mening horen. Het voortel:
A new approach to Ubuntu donations
People can make contributions by writing code, but most users don’t have the knowledge or time to do that. Writing documentation is easier but requires a lot of time. Not everybody want to spend their free time behind the computer, especially not if you are already working in IT. Supporting new feature is then limited to hitting “+1” on Ubuntu Brainstorm or by making a donation. I believe that making a donation is a good way support an open source project and allows the user to get more attached to it.
Ubuntu got millions of users, all over the world. I don’t know the numbers, but most users have valid arguments for not making a contribution (e.g. lack of time, knowledge, interest). But this large group got also a huge potential, what if thousand users pay each ten euro. Ten thousand euros can make a difference in the life of a developer, especially if it’s still a student. When viewing from the developer perspective: they need to eat and pay their bills, they need to make money somehow.
The current donation approach is not sufficient enough to support above ideas. Therefore I suggest a new system, which for now I’d like to call “uFUND”. uFUND is a crowd funding platform for Ubuntu which allows users to support a project by making a donation. I suggest the following process. First, people should be able to submit and vote on ideas via Ubuntu Brainstorm. This is an important step to warm the crowd and make them connected to ideas. In the second phase developers can write detailed specifications for ideas and feasible ideas get promoted. Again users can vote on the new shortlist. The third phase is about the implementation of the ideas. The user that is paying should get updates about the progress of the development.
There are some nice advantages with this system. First, it is democratic; Ubuntu is improved in areas that people like. Satisfying the majority of your users is always a good idea. Second, with this approach paying money is fun. By making a small donation with a large group of people, you get the features you want to have. uFUND can tap into the hundred thousands of users that want something to change in Ubuntu, but are not in a situation to do this. This all result in supporting the ultimate goal: faster Ubuntu development.
As often, success is in the details, so it might take a few iterations to get it right. Here are some aspects that are highly important:
CANONICAL BACKING
The time estimation of a feature can be incorrect. I believe that it is highly important that the idea is implemented, even when it takes more time. This might be a role for Canonical. Maybe, in the beginning, all the developers who can participate should be working at canonical.
IN LINE WITH VISION
Ubuntu got some vision/plan for the next couple of years. Ideas should follow the plan. For example, the idea “Continue Gnome2 development” might get a lot of votes, but is not a very good idea.
HALF YEAR CADENCE
I think it’s a good idea to stick with the Ubuntu cadence. So when people pay for an idea, they get it in the next version of Ubuntu. Otherwise seeing the result of your payments take too long, this doesn’t stimulate to make another donation.
SMALL IDEAS
I ideas should be small, concrete and feasible. All the ideas should small, because they should be implemented in the next version of Ubuntu. Small projects are also easier to fund. The ideas should be concrete, vague ideas result in endless discussions and unsatisfied users. So “Firefox support for Unity scrollbar” is a good idea while “Fix the world” is not.
LAYOUT WEBSITE
The design plays a key role and can make uFUND fail completely. The website should be simple, clean, and give a reliable impression. Otherwise people don’t trust their money with it. A progress bar is also a little detail which can be the difference.
PAYMENT OVERHEAD
A disadvantage is that a lot of small transaction require a lot of overhead. I don’t know much about this.
SPEC INTERPRETATION PROBLEMS
Everybody who wrote code for a customer knows that no matter how detailed the specification is, there is always discussion. uFUND will have the same problems, especially because of the large amount of stakeholders.
PROMOTION
Enough people should know the idea otherwise it will fail.
So I think this is worth an experiment. What do you think?
