Continuing the discussion from Building your OFN group or organisation in a new country:
This topic is especially for non-technical people who want to understand how they can concretely get the platform up and running. Maybe you don’t have yet a developer in your team to explain you that / lead that, so here is our experience from Norway, and what we learnt from it.
1- The basics
“OFN is open source, so any developer can basically copy/paste the code (which is on Github here) on a server and run it.” Ok, that sounds simple, and it is a bit like that, but maybe not so simple
I’m not sure I have understood everything, but here is my understanding, from a non-technical point (even if you are not a tech, it can be good to understand the IT):
Here is a first try to describe the IT architecture:
Please have a look and change whatever need to be change! Ping @openfoodnetwork
I guess this architecture may differ from instance to instance.
2- Why having seperate local OFNs?
in Australia, UK, Scandinavia… the local OFN are running on different “instances”. That means basically that each region manage its own server and put the code on it, and build the governance around it. It may seems a bit less efficient, as we need to redo the installation job everytime, but here are the main reasons why we have chosen that strategy:
- technical - so we don’t currently need to deal with country specific customisations, taxes, currencies and languages within the same app (one step at a time
- resilience - we think it’s important that local food systems are not reliant on people or software running somewhere far far away and out of control. We’re still a pretty small outfit with lots of good will contributions etc - we don’t want the whole world going down if something goes wrong with a production deploy
- philosophical / political - we think that local ownership and control of local food systems is a critical counter-balance to centralising corporate industrial ag - we want to protect against centralisation of control of our food systems, including protecting us against ourselves
3- Having a first version to test and demo
In Norway, we started the project without technical skills in our team. So in order to have a first version of our local platform up and running, so that we can demo it to people and start showing what it would like for Norway, we asked the international community if they could do that first install for us, without customizing anything (or just the location so that we see we are in Norway). Not everyone can work for free all the time, so we paid a little bit the Australian team for that, but it was really a small amount of money so we were able to put some personal money (being confidend we would pay ourselves back when we have money in, which happened!)
To do the install for Norway, we needed to buy a domain (we couldn’t buy a .org.no domain, not allowed in Norway, so we bought the openfoodnetwork.no) and an SSL certificate. After some investigation, we choose the ssl.com basic SSL (49$), and it worked well. We had a bad experience with StartSSL, the free SSL didn’t work for an “e-commerce initiative”, and we tried the paying option but they didn’t want to validate the domain as the name of our organization was not Open Food Network (the local non-profit is called Altifrem).
So with that, we could have our first version and start testing it and playing with it
[Of course if you have tech people in your team, you won’t have to go through that step, they will directly install it locally]
When testing, we of course discovered some bugs, or features to adapt for the local context. So we created a “Milestones” on Github for Scandinavia and started opening issues. For those who don’t know about it, Github is a library where all the developers people share the coding files. So if someone develop a new feature within the OFN repository, everyone can access it and install it. So it’s a tool for developers to coordinate, manage contributions, and compile them.
And we started opening and contributing to discussions on Discourse.
4- Building a dev team locally
But we soon realized we won’t move forward if we don’t build a local community around the project and have involved developers locally. First because we didn’t have money to pay other people to do it, even within the community, and then because everyone is very busy already with trying to get their own local instance. So we started talking at open-source developers gatherings (conferences, meetups, etc.) and we launched a “call for developers” 1 min video on facebook (https://drive.google.com/open?id=0B_HDFsX1e_2Vcm9FOUlxQ0R2WDg&authuser=0)
And that worked!
5- Take over the server and move forward
The next step was to “take over” locally the installation that had been done for us by the Australian team. The install had been done on the Digital Ocean account of the Australian instance, so we have to transfer it to a local one. There are other technical things I didn’t get, but the tech people talked together
The technical environment is described on the Wiki on Github
The idea is now, we will have our local team of developers, with one of them taking the tech lead, and they will be able to work on the specific bugs we will have on our local instance, do the dev job for the features we need locally (like adapt the language, the VAT, some wording, some API with local payment systems, or accounting systems, etc.) and of course contribute in the permanent improvement of our “commons”