Hi all
I’ve been asked to put together a couple of points about what I think this session is for - so here’s a big brain dump. Possibly too much for this one meeting, but I think is a conversation that will benefit immensely from brains in the same room with a whiteboard!
Basically I want to take the opportunity while we have lots of people together to get ourselves all on the same page (or at least aware of each others’ pages) about HOW we want OFN to evolve technically - particularly re. being more open/connected. For example, there are conversations around about interoperability, micro-service architecture, APIs, separating / connecting to different front-end apps and frameworks.
I’m not sure that I understand what all these things mean, are they the same? are they different? do we agree what they are? do we agree what we want to do about them?
I suspect there are three needs behind these discussions . .
- How OFN connects to other software services
- enabling easy connection for users with other software like CRM, accounting, ERP (Odoo) etc
- How OFN works with / interfaces with and shares with other food software
- most basic is the map / directory stuff - for example should OFN map be able to stream info about food hubs on other platforms, and share ours?
- but then more functional like sharing products / inventory and sending/receiving info from other systems to amend those
- can/could code / features / modules - gems? - developed within OFN actually be packaged to be reused by others?
- the meeting on friday will include people from two large Australian food hubs for whom these are very pressing issues:
- Food Connect: which uses OFN for wholesale but not retail and deals with a whole lot of internal integration issues (re-typing data)
- CERES Fair Food: currently does not use OFN but we are their software development team. It does not make sense to attempt to migrate them to OFN at the moment. But nor does it make sense to continue down the path of them being the only users (and financiers) of their software, especially when there are things they want that OFN already has. and they are investing in building things that OFN wants. How do we most effectively share code/features with OFN and vice versa?
. . which leads to
- How OFN actually works within itself
- OFN is very complex and frightening / off-putting for new developers - it is difficult to make significant changes without upsetting other things. does it need to be this hard?
- We have a tendency - and increasingly so - to deal with a quick fix for a user by further complicating an interface with something that no one else needs
- We have problem with the arduousness of upgrading things, perhaps due to the deep embeddedness of different frameworks
- to better achieve anything of 1 & 2, it seems to me that we would need to be taking a long hard look at how OFN actually is built and developed so that what is doing what is evident and can also be more easily changed
In relation to 3., I had an incredibly useful conversation with Andy Palmer yesterday (doesn’t appear to be on discourse, will invite him to this post - to see if I have this even vaguely right). He’s currently working across both CERES and OFN and seeing similar architectural / style issues in both. I will attempt to capture what I got from this conversation in a couple of dot points:
- the problems we have are extremely common. It is more rare for people to have overcome this than to drown in it
it is hard but not impossible to get better - we want our own business logic in our own code - then we call and send to spree or other software for what we need, but we are only changing our own code. This makes things much easier to maintain and improve
- it may be possible to simplify code by reducing if/else statements e.g. if user is A do this, if user is b do this . . if we can stipulate that user A can access service A, and user B can not then the code for service A can just execute service A, and be much simpler because it doesn’t have to deal with User B. I am not sure if this is called ‘micro-service’ architecture or not, also he mentioned ‘domain driven design’ which may have been in relation to this . .
- OBVIOUSLY our eternal resource constraints and users at our shoulders make this kind of thing extremely difficult to deal with. We do not have the resources for a mega-refactor or rewrite even if we wanted to
- BUT we may be able to address it like a ‘strangler vine’ in that every bit of it we hit, we quietly improve the ‘extraction’ of business logic, gradually gradually making things more readable, less complex and easier to change. Everything NEW should be separate and simple . .
- maybe? if we did this then the things waiting on spree upgrade could actually be done, because we can see what spree ‘passes’ now and what spree will ‘pass’ when upgraded and write code that just needs to deal with that change? i know i’m not a developer so this might be nonsense
- AND I am not sure the extent to which the non-negotiable work on Spree Ugrade is an fork in road / opportunity to understand and begin to apply a way of working/coding that leads us more into a world OFN is a friend to developers, and to other software services that want to talk to it
it is hard but not impossible to get betterThese seem to me to be all connected aspects of the same questions - do we want OFN to play a role in connected ecosystem of food systems software, if we do what does that actually mean / look like, and - critically - if that is where we’re going, HOW do we do it and WHAT do we need to do?
So, having written all that, I think I would summarise the intent / possible agenda for meeting on Friday to be:
- as food system activists - how do we want our software ecosystem to work? The Vision for open collaboration in food software
- what is underway already to help us head in the right direction
- @MyriamBoure present Food Data Consortium?
- sharing developers and resources across systems
- others? @enricostn @sauloperez re. Odoo? or talk to what you’re finding in Spree Upgrade?
- what is stopping us?
- what else do we need to do?
- how can we move forward? Next steps . .
- could we get to agreeing a couple of key areas to focus on - like making products/inventory accessible to other systems?
ping @danielle @serenity @oeoeaio @maikel @lin_d_hop @Matt-Yorkley @Olivier @RohanM @tschumilas