Bringing a Revenue Focus to Delivery

Most of us across the OFN community are concerned with building revenue, for our instances, food enterprises and for the global community. In this post I want to share some of the thinking that has been going on within the product team to consider how we might build a more diverse revenue strategy and help this project to become more sustainable in the long term. The hope is that this post will help us all think about revenue in different ways and hopefully build a collective global conversation.

Where does OFN Global Income come from now?

Currently the global project, which is primarily the delivery pipe (though it could and should be much more than this!) is funded through the contributions of individual instances. Our paid delivery team totals over 200 hours a week, 150 hours of dev and the remainder split between product and testing. This currently costs the global community €25,000 a month, down from a peak of €35,000 earlier this year. This amount is simultaneously not enough (everyone is tired of how slow the pipe moves) and already difficult to fund.

The vast majority of this paid time is covered by contributions from three instances, UK, FR and AU. CA, US, BE and DE have contributed small amounts at different times and IE is starting to contribute too.

UK have been fortunate to receive philanthropic funding that has meant the UK team currently covers around 60% of the pipe. Philanthropic funds have also been granted in AU and FR in the past when they have covered the majority of delivery expenses. Currently FR contributions come from a combination of social investment and user fees. AU funds come from a combination of user fees and consultancy work, alongside occasional funded projects.

Currently when people contribute funds to the ‘global pot’ these funds go toward general project delivery. For the past 2 years this has mainly meant reducing the tech debt load of the project. This has taken a huge amount of clever fundraising but the great news is that the OFN code base has never been in a better state, something we can all be proud of.

While we have had a lot of good fortune and have worked incredibly hard to get to this point, we live in interesting times and the world ahead of us is not going to be the same as the one behind us.

Some things I have been thinking about:

  1. It is possible that fundraising will become harder after the COVID blip, as available funds become more competitive and money supply slows down
  2. We know that many of us as instances and community food enterprises have specific needs that we would be able to raise funds for if we could promise they would be delivered
  3. Many funders want to see specific deliverables, and right now all money is going into a global pool which is hard to justify
  4. We need to balance between ensuring that we fund bug fixes and keeping on top of maintenance, but also delivering the exciting features that many of us dream of

Can we combine thinking about revenue with building the platform?

Thinking about the work that goes into building the platform, it falls into 5 main categories:

  1. Bugs, maintenance
  2. Tech debt, cleanup
  3. Hygiene Features - things that should work but don’t (compliance, reports)
  4. Differentiation features - things that set OFN apart from the rest (network feature)
  5. Sysadmin/devops - ofn-install, server maintenance

1. Bugs/maintenance

This is work that will always need to be done, but that no one will pay for specifically. We need to ensure that we have the funds available to do this work from reliable funding sources eg user fee contributions

2. Tech debt/clean up

Again this is work that will always need to be done. This work minimises bugs, fixes security issues, helps feature delivery to happen faster and helps contributors onboard more easily. We need to ensure that we have the funds available to do this work from reliable funding sources eg user fee contributions.

3. Hygiene Features

These are features that users just expect. For sure there is no clear definition of a hygiene feature, but hygiene features are often the reason why people will choose a different platform to ours. These features should help us to attract new users, keep existing users and should also help existing users to grow their revenue. In turn this should mean more revenue for the OFN global project to continue to improve.

4. Differentiation features

These are the exciting features. Features that make us different from everyone else. These are the kinds of features that are easier to attract philanthropic funding for - like DFC integration or the network feature. If we can creatively conceive of these features together, we can often find funding from multiple sources. In fact, historically this is something we often do and a big reason as to how the project has grown to this point!

5. Sysadmin/Devops

This is all of the work involved in maintaining the ofn-install project, as well as keeping servers running. Whether an instance is managed by the core team or not, the core team maintains the deployment scripts that are used by everyone. Our strategy around infrastructure is also a crucial factor when considering how to make OFN accessible to regions of the world less able to resource servers.

I’ve had a few initial thoughts about how these different kinds of tasks that need to be prioritised in our delivery pipe could overlap with the thinking and work around our global revenue…

Fundraising:

  • Can we think about differentiation features as a core part of our fundraising strategy?
  • What do we need to have in place to help fundraisers incorporate specific features in their fundraising?
  • If our fundraising strategy continues to have a global south focus, how can we better resource our infrastructure strategy as part of this work?

Core Roadmap:

  • Can we start to include factors like the business case when thinking about upcoming pipe priorities?
  • Would including tech debt and compliance features on a roadmap support fundraising efforts for things like this?
  • Can we start to think about prioritising the features that will attract/retain the most shoppers and community food businesses? Are there ways we can understand which features will do this?

I realise that there’s a lot here and a lot of questions. This post is intended to spark thinking and conversations rather than lead directly to solutions so please do share any thoughts it raises for you.

8 Likes

Aloha,

I’m planning to start an OFN in Hawaii. I feel it needs to be self-sustaining at every level. As someone just looking at what others have done, I’ve noticed that a lot of items in shops don’t have any extra fee for the hub.

From my perspective, the grassroots support is where things must start. AKA, producers must somehow agree to include a margin for the network operation. I think that they can decide themselves what it should be in consultation with an instance manager.

Regarding delivery, in our neck of the woods the terrain is mountainous and expensive in gas and time to travel. We are much better off sourcing everything within small boundaries. In fact, we would be better off using scooters, bikes, and walking in most cases.

Most delivery planning aims for minimal contact and maximum efficiency. The whole concept of delivery as some kind of independent service is really only suited to maximizing profit of the carriers. In the same way that OFN disintermediates food, we need to dis-intermediate delivery.

I am suggesting re-thinking delivery, making it more of a social event than a chore. In many cases, if I’m delivering something to my neighbor, I already have some sort of relationship. We can use the box of groceries as a talking point. If there isn’t a lot of time/cost involved, I’m probably bringing it over for free.

Practically speaking, this means having lots of little hubs, shops, stands, etc. instead of one major one. There need to be lots of little “distribution points” that can either serve as a place nearby to pick things up, or can be a starting point for a last mile delivery.

So there also needs to be some way to move inventory throughout the network. In my view, this would be best accomplished by produce “hitchhiking” with people already in motion.

In order to connect people who need delivery with those who would like to provide them ( for free or not ) we need some sort of Uber for produce that is hyper local and works for any mode of transport.