Ok let's try to make a first draft in english, and we'll update it with our questions around this proposition. Please fill free to improve, suggestions from natives speakers are welcome!.
Imagine a community develops a "commons". Say, a map of projects and initiatives called TransforMap! This "commons" looks pretty similar to what a city council would like to see developed for its own town.
How would such a council proceed? He would probably start with a "call for proposal", then select the most promissing ones and engage the best people working on its plan on a contractual basis. The council expects a service to be delivered and dedicates a specific budget to it. Should the commoners (in our example, the contributors to TransforMap) directly react to the council's request?
I think, they shouldn't for two main reasons:
First and foremost: The city council has its own agenda. It has its own idea of how the deliverable should look like and its own due dates. The council's agenda and roadmap are usually not the same as the commoner's agenda, for instance the "common" agenda of TransforMap, nor does an approach of a communal government necessarily express the will from all those who freely contribute to TransforMap. However, as the city council puts the money, such a cooperation on a contractual basis will heavily impact on the projects dynamic and evolution. The council's agenda could bring along all the usual constraints of the commercial world: all of a sudden "the need to deliver" trumps "the need to respect the project's rhythm". Therefore, a gap opens up between those who deliver a lot and get the money and those who (can only) deliver from time to time and do so without payment (which is pretty common in a commons project).
The adaptation of the commons project's goal and dynamics to the city council's needs, does not necessarily happen as a conscious process. People who work on TransforMap for example, might even modify the project's direction in a subtle, almost imperceptible way. This may lead to a situation where those commoners, who contribute for intrinsic reasons (fun, networking, trial-and-error-learning processes) will leave the project." What might look like a win-win situation at the beginning, turns out to be a win-loose one. The City Council gets its map. But TransforMap lost its community. And without community, no commons.
Secondly; by reacting to the call for proposals, a commons-project starts competing with other service-driven organisations and commercial firms. Such a turn doesn't only convert the commons into something that will now be forced to produce "a better deliverable" than others (according to the call's logic), it also reanimates the logic of competition instead of defending the idea of free and voluntary cooperation. In other words: instead of helping people to change the behavioral patterns triggered by a flawed economic system, it reinforces these patterns. This might motivate people to leave the "common" project, or because they have their own commercial organisation that could run for the council's call or because they don't wish to be driven by external needs.
One idea to avoid this kind of situation and to stick to the "commoners' spirit", is not to "compete for a call for proposal", but to help all those who wish to do so by making use of our commons (TransforMap) in their proposals.
For example, commercial organisation A and commercial organisation B react to the call and compete for a contract. We'll help these two companies to get all the information they need to include "commons" (f.i. the use of the TransforMap platform) into their project proposal. Maybe both companies will include the same "commons", so that no matter who wins, the "commons" will succeed, without forcing the commoners into the competition.
Of course, the commons projects should be paid for their provisions, for instance for the use of the cooperatively created mapping platform by all those who wish to make a business out of it or, like our commercial organisation A and B, who win a call of governmental institutions.
How would that be possible, without generating the same pressure on the commons project we've rejected before?
We think, that commercial organisations should just make their use of a commons transparent. They should publicly specify the money they contribute, as a donation to the commons and not as a service payment (!), without any right to get something in return that the commons project wouldn't freely provide.
Furthermore; to stick to our example, if the commons-platform (f.i. TransforMap) is of any use for the City Council's mission, this could be clearly stated at the beginning of each call for proposal or bidding process. It should be mentioned in the call for proposals and compensated with a public contribution to the commons (usually towards the end of such a process, as one never knows how a commons will in fact be useful for a specific purpose).
Here is a example of how to proceed:
In this example, two commercial organisations (MappingCompany and TrainingCompany) answered together to a call. There will be "two commons" that these companies will use to develop a solution for the city council. In our example, one of these commons is Transformap. For using TransforMap to produce the map for the City Council, MappingCompany is publicly declaring a donation of 2000€ to TransforMap and self-commits to put the features developed during the mission "open source". This an "in-kind" contribution to the commons.
Our idea is to help commercial organizations gaining confidence in the commons approach while helping the commons to be funded when they are used for business purposes.
This will help us identifying all those who are willing to cooperate with commons (organizations) in a respectful way. So that, when commoners are asked by public or private companies to develop a specific module, product and service, these commoners can redirect people to the companies that wish to do so while using and contributing to the commons.
Of course, there is a need to make public which companies contribute to the commons, so that the respective company can benefit from the publicity (that is: transparent information instead of paid commercials), while those who don't contribute to the commons remain invisible.
We started working on this approach at encommuns. Feel free to explore: http://encommuns.org/#/economique (@almereyda it's in the dataserver API)
Of course, once the commons get money, the other question (to be dealt with in another thread) is how to distribute this money among the contributors. Because as Benjamin Mako says, "it's easier for a successful volunteer Free Software project to get money than it is to decide how to spend it".
Gratipay.com is currently working on a great solution to this problem (others like Sensorica also try to do so). We already use it in our commonsdev team as you can see her, but not with Gratipay as the feature is being updrated and is not working for the moment.
More information, for the moment only in French on: http://unisson.co, especially here and here.