You run / want to run a food enterprise and need a marketplace for your project?
Maybe Open Food Network can be a good starting point, maybe it only needs a few tweaks to meets your needs 
There are three ways you can build your marketplace on Open Food Network AND have your own specific front end at your image:
Option 1: a specific front end but built on the local OFN public infrastructure
Maybe there is already a local community who has deployed the OFN and made it accessible for all local food enterprises? If not we can help you gather contacts to help you bootstrap a local community who could make this public depoyment
In that case you would use this local deployment, maintained by the local community hosting the public infrastructure (for example a local non-profit) and making it available as a common. SO you don’t have to make your own deployment If course the local community may need your support to set up a secure and scalable infrastructure that meets your needs.
Pros:
-
By choosing to use the public infrastructure deployed by the local community, you can play a role in activating the development of local food systems in your territory, beyond your project. The producers you would work with will become visible on the general OFN map where all the communities would have started mapping producers and hubs. So you can be connected to the other local food systems network. Also, the producers you work with could open their own direct shop if they want to, or start supplying other local food hubs, without having to duplicate their inventory.
-
you might be the main user of the Common locally so you might have to cover the infrastructure/overhead costs to start with. But with more users on the “public” platform, the cost can be slowly shared by those who use the most the Common (fair contributions). It doesn’t cost you more that if you would deploy this only for your project, but it benefits the whole community, so that means a good return on investment in terms of impact.
-
As an active contributor & user to the local community you will be invited to take part in the local governance of the Common (i.e. the local association running the public infrastructure)
-
At any time, you can decide to make your own deployment and extract all your data to take your independence, there are no hidden chains here. You don’t know what will be the project tomorrow, it’s a security to know that the investment you make in the Common will benefit you on a long term whatever happens.
-
The fact of using the “master code” version, which is deployed and upgraded regularly by the local community hosting the infrastructure, means that if you need developments, some of your needs may be shared by other people/communities in the world, so the cost could be shared, gaining in cost efficiency. Also the security is ensured and improved all the time by the community, so you don’t have to ensure and maintain the security alone.
-
Even if the governance of the platform is shared, your users will access via a separate interface (website / front ed) which is fully under your control, enabling you to manage all your customer strategy. So you will have a full flexibility on what you want to do, and the OFN platform can work quietly in the background enabling your system to do what it needs to do.
Cons:
-
You will not decide alone on the evolution of the Common, you will be part of the collaborative governance of the local OFN host/ and Open Food Network for the global code, so you won’t decide on your own about the evolution of the code. The governance process is super collaborativeon the evolution of the product. But that is something you need to be conscious about. We are all doing our best to always find solutions to answer local needs by some flexible solution that enable to answer all needs simultaneously. There is no reason why this would not continue.
-
You need to trust the security process of the provider chosen by the local host (the local OFN association might delegate the system administration to some local company) and the OFN security features, that guarantees you that there will be no data loss, no interruption of service, and no intrusion in the system / hack resulting in data corruption. There is a high probability that the local community will be happy to work hand in hand with you on that, if you propose a super secure plan and are ready to pay for it no one would block this proposal as it would benefit the whole local community
It is also possible for you to ask for a security audit if you want to assess the security features. -
Developments can take a little bit more time to be implemented as there is usually a conception stage where we discuss with the rest of the community to agree on how to implement this feature in a way that fits every local instance. While this can take a little longer to agree, the robustness of the solution and flexibility to support varied uses will also benefit you in the longer term.
Option 2: self-deployment of the master code
You can make a separate deployment of the code only for your initiative. You choose to deploy the “master code” and stay connected with it (no fork) to keep co-developing with the rest of the community.
Pros:
- As you stay in the “master code”, you can still work hand in hand with the other communities and co-finance developments, etc.
- You are totally independent on the governance of your platform, not only the website you built on it.
Cons:
- You have to pay alone all the infrastructure/overhead costs, no mutualization with other actors.
- You can’t activate local food systems beyond your initiative as your network data are in a separate infrastructure/database.
- Developments can take a little bit more time to be implemented as there is usually a conception stage where we discuss with the rest of the community to agree on how to implement this feature in a way that fits every local instance.
Option 3: self-deployment of your forked version of the code
You can make a separate deployment of the code only for your initiative. You choose fork and make your own version / branch.
Pros:
- You are totally independent on the governance of your platform, not only the website you built on it AND on the evolution of the code base, you do whatever you want without discussing with anyone. Developments may go faster (but maybe not as far?).
Cons:
- You have to pay alone all the infrastructure/overhead costs AND development costs, no mutualization with other actors.
- You can’t activate local food systems beyond your initiative as your network data are in a separate infrastructure/database.
- You will no longer be drawing on the shared experience and knowledge of the global community in what to implement and how, including losing access to on-ground experience of other users in feature design.
We recommend of course the option one, but you are free to consider other options as well and we’ll be happy to support you whatever your choice
Among the various OFN instances and networks, we can find the people and skills to support you in your project to deploy an OFN based marketplace. Just contact us at hello@openfoodnetwork.org.
If you want to make your own deployment on your side you will find the source code on GitHub and a lot of precious information on the GitHub wiki