This post is an attempt to pull together various discussions that have been happening in multiple posts, private messages and emails about the tricky business of funding work on ‘the OFN Core Commons’, particularly here in Aus and with @MyriamBoure. It’s a basis for discussion and would be great to get a clearer agreement on this for 2017 . .
There are activities that are crucial to the development and nurturing of the commons and community that we’re all so passionate about, that are always needed and rarely (if ever) funded. They tend to fall on the shoulders of the passionate and committed people who will just always do more / what is needed. We have been able to cover some of these costs through previous grants in Australia, but that money is LONG GONE! The current cobbled together and unfunded situation means that things inevitably fall through the cracks, don’t get done, cause tension about who/how is going to handle them, and stress people out (increasing risk of burn-out and loss of people!)
So as we mature, we need clarity and a smarter system for resourcing this ‘OFN Core Commons’ work so that it gets done, done well and both new and existing members of the community feel supported and welcomed.
Definition: what we mean by OFN Core Commons
Activities include:
Community facilitation, particularly ‘product management’ - facilitating development of agreed specifications and approaches. This often leads to
Estimations, definition of how work would best be done / support for newer developers
Code review and merge - ensuring code quality and the integrity of the code base that we all love and rely on
Tech oversight - scanning for and dealing with risks, security updates, emergency server support
Global governance and coordination / facilitation, potentially including management of co-budget, hangouts, ‘meet and greet’ of new instances etc
We think OFN CC generally excludes work within funded projects e.g. for development of an instance or new features. For funded projects:
Costs associated with (1) code review and merge and (2) product management should be considered as part of the job and costed as part of the project.
This is the way it has been handled to date e.g. with the UK, but obviously with a major volunteer and developer subsidy contributions reducing some of those costs
How much this costs then becomes a discussion within contract (NB. draft Aus proposed cost structure for 2017 is below, pending discussion / agreement with all in our planning weekend on 3/4 Feb)
It also generally excludes work that is undertaken ‘for an instance’. Who gets paid, how much, and for what within each country / organisation / instance is the responsibility of that instance. We’re also not talking about the work of each of those instances in engaging with the commons, so when someone from Australia is checking to make sure a proposed invoicing system will meet Australian requirements this is ‘australian’ work, not commons work. If the person coordinating all the international requirements is working within a funded project to upgrade invoicing then this is also ‘not’ commons work (as outlined above) as it is part of that project.
We’re looking at the ‘core OFN commons’ work that is needed to support and coordinate the work of those instances etc.
So examples of the kind of OFN CC work that remains include:
tech oversight, security, emergency server support etc
developer exploring OFN and needing support, or submitting pull requests that need attention. We want to encourage new developers and build the community, so they need attention when they ask questions, get stuck, submit pull requests etc
community management and estimates e.g. someone had an idea for feature, it connects with lots of other areas. Connect up, analyse, advise . . estimate / design approach if necessary and progress to set-up of co-budget to raise money for project, if not lead by existing instance or project
introduction and setting up of a new instance and community [as an aside, I would love for there to be a bit of money available to jump the hurdle for new instances e.g. to get Nepal and India started, but I think we’re a little way away from that]
LOANS? how do we handle work that goes into informing funding submissions / quotes e.g. estimates? Track these as ‘loans’ to instances that get paid back to the commons if / when funding is received?
How much is needed?
Suggest define four streams of activity, with ‘bare minimum’ hours per week in brackets:
core code mgmt, tech oversight (1)
product management (1.5)
code review and merge, dev support (2)
global community facilitation (0)
At $80AUD per hour this is $14,560 for the year. See google sheet here for this and other scenarios
How could this be raised?
Starting point for how these funds could be raised:
Seek / obtain funding explicitly to support commons work (who writes these?)
Each instance contribute XX e.g. % of turnover, funds received etc
see Aus draft cost structure for 2017 (below)
very keen to hear others’ thoughts on how they might contribute
key question re. Aus allocating 10% / 20% of revenue that is coming from other instance’s funds e.g. would it be better for (e.g. UK) to allocate X% directly to OFN CC when funds come in, rather than us have it built into our funding model i.e. this contribution is from UK more than Aus?
part of the reason for doing it this way might be that it’s harder to justify contribution to commons in funding submission, and easier to manage if it’s just a ‘cost of development’
Crowd-fund among global community e.g. co-budget
Probably a mix of all the above!
How is it managed / allocated?
We have set the ‘rate’ based on what we’re wanting to pay people in Aus because the current reality is that is where the work described is mostly based (with exception of Myriam’s global coordination) BUT we are keen to see this activity become more globally distributed over time.
This raises questions of how these OFN CC activities are paid for and where e.g.
if most ‘to be paid’ activities are currently happening in Australia, should money all be transferred here
if that is not how we want things to ultimately operate, should each instance maintain their own ‘commons’ pool and pay for contributions towards it
if the latter, what do we actually need to do to enable distribution of these tasks, particularly code review and merge? what would be the timeline for doing that?
Aus DRAFT cost structure for 2017
We are proposing to charge time at $100 per hour for all work in funded projects, with a 20% project management cost on top of that. We will then offer people $80 (including for funded components of OFN CC). People can then choose to volunteer extra time, or charge ‘OFN Aus’ less. If there is any surplus, it will go towards OFN CC or be allocated to co-budget projects [TBC]
We will then allocate 10% off all money we receive for OFN-related services to OFN CC and another 10% to Australian overheads. The reality is that services income is more significant for keeping our team operating than OFN sales revenue at the moment. See OFN Services in the spreadsheet for our rough projections (hopefully conservative) for this year.
This is a really challenging discussion and will be held in depth at Aus retreat in Feb, as we’re all inclined to do much more and charge much less, and we don’t want to spoil the ‘energy’ of freely given contributions. We’re well aware that we wouldn’t have got this far without a lively spirit of freely given contribution AND that it is important to be fair and not expect those who have all given a lot to keep giving, especially when they are feeling pressured to do so.
We’re really open to thoughts / discussion about how this is being handled in other places?!
great to have this so well thought-out. thanks Kirsten. Let’s talk this through at our next UK management meeting @mags@Sara@lin_d_hop and decide a contribution.
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
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
I continue to be impressed with the frankness and authenticity with which this community tables and discusses ‘thorny’ issues - like this one Eventhough we’ve had the platform deployed in Canada for a year - I only now feel like we are beginning to get some users. I am now starting to do some funding proposals and to create a vision and ‘business plan’ for (1) building an OFN community here, and (2) rolling out the platform across Canada. So this budget discussion is timely for me.
I have thought of this as a layered set of different commons that all have to be maintained. There is the OFN CORE commons, then the OFN-CAN national level commons, and then I think we have a third set of commons at the regional/provincial level here. Because the only way I can effectively disseminate and build across Canada is to stimulate additional groups/networks working in BC, the prairies, Quebec & french speaking CAnada, the far north, and the maratime provinces. So - I’ve been trying to work out what each of these embedded commons needs and what percentage of OFN receipts (from platform users and from other fundraising) should be designated for each commons.
so for me, I totally expect that OFN-CAN would contribute a percentage of receipts to OFN CORE. In addition - I think we imagine paying the AUS team for the support we are currently getting to deploy the platform here (our server support, training help/Q&A, and of course new feature development). At least until we have a team to do that here. I feel like we’ve been a ‘free rider’ for a long time and I hope to turn that around. That all said - I feel like I don’t have a good handle on all the costs and the percentages yet - so I appreciate the number crunching from those of you with more experience with this.
ok. I think I’m across what you’re saying @MyriamBoure. Will keep my response brief
emergency server - you’re probably right, and it would be the ideal that each instance has this under control and increasingly that is the case. There are times though when stuff goes wrong and - especially for newer instances - it is really nice to have someone with a lot of experience w the system to ping/call. This currently does still tend to happen to rohan, rob or maikel. Like everything will be better when it is not. So perhaps this is more about having a global person designated as a touchpoint - almost like an on-call person, and some funds to cover their time if they are used.
I’ve made a couple of changes in the spreadsheet to reflect what you’re saying about instance contributions. Main change is so that the Aus calculations are now nested e.g. we will take 20% commons overhead on all work that we do, and then allocate a proportion to the global commons depending on the project. So I’m suggesting that we initially do this as 20% of the commons overhead for australian clients and keep the 50% for global projects.
I think I disagree about funded clients and the feature development being their contribution. People coming to OFN now are getting a MASSIVE saving compared to what they would need to spend to build from scratch. Yes they are contributing features, but I think there should also be direct contributions to the other costs of the commons. These are the ongoing and necessary costs of providing the infrastructure that is enabling them to get what they want for much less than they would otherwise! So I am very comfortable keeping 20% commons overhead on these projects, until such time as the clients wish to manage this contribution themselves, then Aus happy to negotiate and happy for contributions to not come through us
At our UK admin hangout on Thursday we agreed that OFN UK will commit a minimum of £3,000 (5048AUD) to the commons for 2017. We hope to be able to pay more in future years. There is a chance that we wont be able to pay as much in future years. It all depends on income from users and grants.
We are happy to discuss this more
Your right @Kirsten, I agree with what you said, it’s clearer now.
That’s not exactly what I said, basically my thought is that on top of the new features they have contributed to pay for, they will already contribute a % for the Common they use, which is not directly the global OFN Common but the local Open Food France Common. So they do pay for the work of the global community by paying to Open Food France, which is their contact point with the OFN Common. Then we can discuss on how much OFFrance should give back to the OFN global Common. Every local community is the contact point for the global Common, it’s important to keep that direct contact and proximity with the users and client.
As an image worth always more than a long talk, I represented my vision on all that:
I’m not sure that I explained all right, especially I’m not sure about “when are the payments supposed to happen”? I made an assumption at the end of each bucket, but probably as most roles are taken in charge by Aussie people you need to tell us how you see that happening… That can also impact what people promess to give, for example in France I can’t promess anything if I have to pay in the coming month as we don’t have money in our wallet yet :-o When we commit to give money, when are we suppose to give it basically?
Also I’m not sure if I understood well the product management bucket you were thinking about. I thought of it as a distributed role (especially if we think of a product curation team, cf discussion from the last hangout) so anyway, I kept it pretty large and started to put some names on it, but I think it’s important that the product management team talks sooner rather than later about how the money will be spread among contributors (when the bucket is raised of course) so that every contributor is clear with that and feel it’s fair.
So @Kirsten you can edit the buckets in co-budget if you want, and when you are ready we can launch them
Just confirming that after discussion today, we in Aus have decided that we won’t ‘charge’ OFN Partners for OFN CC contributions when doing work for them IF they have agreed to make contribution independently (e.g. UK as above). Where that is not clear, we will charge it in our service rates and make it on their behalf
I have just gone to launch the co-budget buckets, and I am a little bit confused about the Product Management bucket too . . I am going to launch it so that money can be pledged towards it BUT I think we’ve got a bit of ‘learn as we go’ here. Aus team are now starting to track time against these projects so we’ll get a better idea of whether these project categories cover everything or not.
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.
Eventhough we’ve had the platform deployed in Canada for a year - I only now feel like we are beginning to get some users. I am now starting to do some funding proposals and to create a vision and ‘business plan’ for (1) building an OFN community here, and (2) rolling out the platform across Canada. So this budget discussion is timely for me.
