Thanks a lot @Kirsten to open up this important discussion.
I’ll react on various points. I do share all what you say, I have some other proposal on how to organize all that, but I am super aligned with the vision you bring here.
How money flows?
I would strongly vote for the option 2, to keep the consistency on “being a decentralized network”. As we are doing it with the Community Agreement (work still to be finished, I have that in my todo ;-)), choosing not to sign contracts with the Open Food Foundation but commit all together to share responsibility for the Commons, I would suggest to have the same intention for how we manage money flow within our network, not to centralize neither the budget nor the team nor the wallet (as a matter of fact as the project started in Australia, many core activities are still happening there, but we should structure our collective in a way that enable to distribute some of those core roles).
The challenge is then to find the good tool to do that in a fluid, transparent, and clear way, which I think Co-budget can do, and will do better soon (I will invite to this conversation Francesca, OuiShare community developer, working now on Co-budget)
Meanwhile we have the good tool, we can manage that alongside with a well-built and shared spreadsheet I guess, with links to the Co-budget bucket when needed (that’s how we do within OuiShare as well ;-)).
**See my very concrete modelization proposal here: **
Instead of having all the money flow to Australia (and some comes back to Europe to pay contributors there) and in order to support and empower the distribution of contributions, I also suggest that we don’t “centralize the money in one wallet” either, but just keep track together of the money we all have put aside for the Commons, and cofinance projects and ongoing CC through co-budget buckets. The wallet used to aggregate the money and pay the contributors for me depends on where the contributors are and who is the leader on the project/task. So technically most of the money might flow to Australia at the begining, yes, but let’s not put that as a rule 
On the OFN CC activities
I agree with your list of activities, apart on some small point.
Isn’t that a task that rely on every instance shoulder for their own server? As we all have have separate instances, I think that doesn’t go into the core commons, unless we have some mutualized system administration role 
If that could be, I would vote for as that’s a huge cost if we want reliable platforms (ensuring zero platform stop and zero loss of data) so we need to have a hotline able to do maintenance work on our servers, do the upgrade on each server, etc.
The fact of each local instance having its own server ensure the resilience, indepandance, and local governance of it, but wouldn’t it make sense to pay someone together to do the system administration for all our instance? Or should every local instance deal with that on their side? I’m not fully aware on how manageable this is on a global scale… maybe the time gap is a problem in case of emergency issue. And also as its a very strategic point maybe it’s just better to have it managed locally by people super highly committed to their own local project.
I also think we should add some “testing” activity in the code review and merge activity, testing to make sure nothing is broken due to the commit. I included it in my modelization in the bucket, but let it for now as a volunteer distributed task, but might be something to fund ideally (some of Sally’s work done for the global collective?).
Does “features specifications” go int tech overview or product management? For me it’s both, you need both a functional and technical view (cf the work we did Rob and I on VAT). I propose to budget that in both activities then, I put it in both buckets in the modelization.
How to we track contributions in order to pay contributors in a fair way within our global community?
We need to find an easy way to track the contributions though, as even if certain roles are not yet very much distributed, they are all a little bit more or less. And for me as a global community and for the resilience of the project our aim should be to slowly distribute a bit more those roles, following the permaculture principles (“one subject have at least three functions, and one function is fulfilled at least by three subjects”). For me in the resilience there is both a local version (in each local instance more than one person should know how to run the server) and on the international version (dev in at least three countries should be able to do code review and merge)
Ex1: code review and merge is only done by Rohan, Maikel and Rob for the moment. Do they track the time they spend on that specific role and then invoice Australia? Tomorrow hopefully one pers in UK, one in another country, etc. might be able to do code review and merge. Maybe for that role keeping track of time can work.
BUT
Ex2: product management, this task is far me much more distributed already, Lynne facilitated and worked on the spec for embeddable shopfront, I did that with Rob on VAT, Kirsten and Lynne on the bulk import of product. It seems to me very much more challenging to track the contributions, as on each topic, various people from various instance can dedicate hours to brainstorm together on how to do that.
Some of the product management work is done through funded projects. For example, VAT overhaul, I start to work on it, and other people jump on the task (Rob especially in that case). When the reflexion starts to be a bit clear, we raise a bucket to finance both the work the main contributors have already done, and the work to be done (all the estimation, dev, etc.)
So product management for ongoing core cc is more the reflexion for features developments that are done apart from funded project, am I right @Kirsten? But it there really a lot? As we don’t have a lot of unfunded developments done, no? Maybe I’m just not aware of what is that role outside of funded project, so thank you for clarifying it in the spreadsheet modelization bucket
I think for more distributed roles we can also use “contributive/value accounting” tools (basically in OuiShare we manage that with a spreadsheet), I shared an example in the modelization proposal.
My recommendation, based on my experience of OuiShare, would be to treat ongoing cc activities as one year projects and fund them every year through cobudget. The way money is spread within a bucket between the contributors to the task can be done through contributive/value accounting (which following time spent by each contributor is just an example of contributive accounting in the ex of code review and merge)
I think we should also, inspired by what @NickWeir told me they do in UK, let the people decide within a project about the rate they want to charge. We can set up a recommended hour rate equivalent to 80AUD/hour, but maybe some people working in a project will need more because they leave in a big city, and maybe some will need less because they leave in India, or in a small village (Nick feel free to tell us more on that)
How much should each instance give back to finance the OFN CC?
There are two levels of Commons:
- the local Common: OFN France for example. If I sell a service based on the Open Food France platform, I give back a % to the Common I use, which is Open Food France, so I give for ex 20% to the Open Food France association.
- the local Common entity uses the global OFN Common to operate, so this local entity then give back a % of what it earns to the global Common. This % should depend for me on “what is the % of value created by the global Common compare to the local Common” and “we need to make the local Common economically balanced for the global Common to survive”, so for me there is kind of a trade-off between those two dimensions.
I distinguish two sources of money to finance the global cc:
- 1- all services sold that use the global common (the platform build thanks to the contribution of everyone, etc.) contribute to the Commons. Basically, for me the rule is “if I earn money thanks to the Common, I should give back to the Common”.
→ In Australia the service sold to FC happen only because the OFN platform exist, you uses the Common to earn money, so you give back 20% of the turnover to OFN Australia, and OFN Australia gives back half of it to global OFN cc, which is actually a lot I think we can all give a huge hug to the Aussie team But there is a confusion when you say 10% between the local and global Common. The local Common give much more than 10% of its revenue to the global OFN CC. To clarify your example, I would say that you charge 20% overhead cost, and on those overhead, you consider that 50% of the structure cost are done by the global OFN CC so you give back 50%.
→ In France I have sold a first service based on the Common, I am going to give back 25% to the OFFrance association, and we have not yet decided how much of it will go back to the global OFN cc, but for the first mission, we need to pay us back first for the server cost we are paying with our personal money. Or maybe we’ll say that 20% of all that’s earned by OFFrance will be given back to the global cc. And if the global cc needs more we can make complementary contributions on co-budget depending on the buckets that are not filled up.That’s the trade off I was mentioning. Or we can say that at the beginning we try to give back 50% to help fund the global Common, and when the global Common is more secure, then we switch to 20%. I sincerly don’t know yet, we’ll discuss that with the OFFrance team in the coming days/weeks.
I think the % can be free, but conscious, and transparent, because the local situations are always different, a new or older instance won’t have the same difficulties to finance their regular costs, etc. So I’m not in favor of imposing a fixed %. What I experience is that with a well designed gift economy, people give more I’m confident it will be the same here, by letting the instance free to give, I’m sure they will give more, BUT we need to design well the process, the gift economy doesn’t work without a very precise process.
Probably the % will depend also on the amount, if we have a 1 million service sold, maybe (maybe not, we are not yet confronted to the case) this is disproportionate to give back 20% of the overhead cost to the global OFN CC.
My guess is that a form of indicative recommended contributions rule in this or that case will emerge somehow when practicing this gift economy.
For me some funded projects can also be in that sphere. It depends on each funded project, and the question is really “do we use the Common to sell this project and earn money, and how do we contribute to the Common in exchange?”
- So in the case of a software edition project: a client in France wants to use the Open Food France platform to operate its activity and ask us lots of modifications on the platform, that he pays for. In that case, the features he pays for go into the global OFN CC, so maybe we can consider that this funded project doesn’t have to pay more to the finance the global cc. Then when using the Open Food France platform, this client will also contribute on a more regular basis with volunteer contributions to Open Food France, and part of this will go back to the global OFN CC (see below). But if we share overhead cost for Open Food France on the project, I think a % should go to OFN global as OFFrance uses the Common to operate.
- In the case of a new feature development co-funded by the local instances, same, the project add value to the Common, so no need to contribute more.
- But if I sell a project which is not financing features dev or if the features dev is a very minor part of the project, so there is not much value created for the global Common, then probably the project should have a reflexion on “how much they use the Common and what would be a fair contribution”
A local instance can also apply to local Foundations and public authorities to get grants. Usually those grants will finance projects & services/new dev/local food systems initatives based on OFN, etc. So for me we should think, while budgeting, if the project is going to bring back value to the global Common (new dev that we will all use). For example supporting local food systems to use OFN, it will be more support work, no positive externalities on code, BUT those new users are going to pay somehow for their use of the local Common (Open Food Network UK for example), and OFN UK is going to give back a % of what they earn to the global OFN CC, so there is an indirect contribution to the Common in that case. But we can also in some grants try to contribute in financing directly some core cc if that sounds possible and appropriate. For example Norway received a free kickstart donation from two people, disconnected from project, and Norway can freely decide to give back a % or a fixed amount to the OFN global as it exists thanks to it.
- 2- a local instance can give back on the contributions from users (either hubs and/or final buyers depending on the instance model) (whether the instance take a 2% commission on sales, or whether, like in France, users donate what they want for the use of the platform) We have to discuss with the local community in France about the % will give back on all donation we receive, but for me 20% from all the donation the Open Food France receives sounds like right.
Collective budgeting and co-budget modelization attemp
Here it is: Global OFN CC budgeting tool - Google Sheets
Comments:
- for the ongoing cc roles bucket I suggest we raise a first bucket with the bare minimum, and if more money than needed come we extend to the next level of service (a bit like it works in crowdfunding campaigns, the logic of treshold) or raise a complementary bucket. That way, we secure first together all the bare min buckets before spending more money
- I suggest we agree on an annual process to fund ongoing cc roles, for example in nov-dec each year (January this year), we review collectively those cc roles and launch the cobudget campaign to fill the bare min buckets for next year.
- in every local budget tab, you can choose how you calculate the % or amount given to the Common, but it would be great to make it transparent.
- So concretely, every local instance will choose, on the amount they have transparently planned to put aside for the global OFN CC, to which of the 4 ongoing core common roles, and on which proportion, they affect it.
Making the actual payments
The money we put in the bucket is a budget, we won’t have already the money in advance to pay the whole amount at the beginning of the year for the whole year.
For instance on code review and merge, let’s say we raise quickly the bare min bucket. In France I have not received yet the donations from users, I will receive them during the year, but it means I commit to pay to the level I have stated. My question is: when should the money be released? Should it be a monthly process, like every month we send 1/12 of the amount? Should we say we need to be able to release half of what we promised from the beginning and the other 1/2 within the next 6 months? I’m not sure about that, would love your view on that @Kirsten
About accounting for volunteer contributions
I think it would make sense also somehow to recognize and account for the volunteer work that we don’t yet manage to fund, as this is a way to finance our OFN CC as well. I’m not talking about putting a $ on it, but estimating the volunteer time dedicated on the co-budget bucket and the open budget global spreadsheet. I have not yet integrated that in my modelization in the spreadsheet but did it in Co-budget tab.
About OFFrance contributions
About OFFrance I don’t have yet a strong visibility on our income this year but I know for sure there will be incomes. We have not yet opened our bank account, we are really only formalizing now our local instance (even if it’s been more that a year that the code is deployed, it’s been only 4-6 months that we work actively on it, especially since I came back to France in August) So I put some amounts in the document but we need to discuss it more deeply with the OFFrance team in the coming days/weeks. I think we can secure at least 1500AUD with the current donations from users. I’m almost 100% sure we will contribute more than that, but the discussions we have with potential paying customers are not concrete enough. We have planted lots of seeds that just start to grow, but it takes a bit of time
About global fundraising
I’m not sure if it is possible to try to raise fund for the global network project, I think it’s easier to fund local instance through local foundations BUT maybe we can try to contact big US Foundations that helps worldwide projects. We are building a very precise and extensive application document in France for a pretty demanding Foundation, so after that, in 2-3 month, we can probably build an English version of it with a “global community” entry door, and we can try to apply to some big Foundations in the US. Ping @Arthur as we are probably going to work together on that. I’ll let you know if/when we open that task, as we will definitely need some contributions from the other instances. If someone else want to take the lead on that, please feel free