Continuing discussion from Inception session: product chain data model
I am involved in lots of commons “prospective” networks, with both “product” and “tech people” in France. I want to share with you some updates about what is coming, what is happening right now, and how it can impact and influence our strategic choices for OFN.
We all share that vision in this ecosystem that the web is evolving toward small “modules” that do little but very well. Instead of big apps trying to do everything but not managing to do anything well. APIsation of the world mean that it becomes much and much easier to build a nice front end, taking various blocks and combining them through APIs into a nice offer. Of course for that you need open and democratically run standards so that all those blocks can easily be plugged with one another, like Lego blocks.
A- An analogy
I wanted to share with you a quick analogy that I use all the time now to describe this “world”:
- Software are roads. You have many roads to drive you to many places. Not one road that try to go everywhere.
- Roads are connected to one another through “road connectors”, “highway interchange”, that enable easily to move from one road to the other, switch from one direction to another and make my own custom path to go where I want. These are the APIs.
- Standards are the “highway code”, the “rules”, a form of “law”, that we decide collectively to use peacfuly our shared infrastructures.
- Data are cars and trucks on the road.
I also sometimes say that French is my standard. If I speak French and you speak English, we need either a “pivot language” to understand each other, either a translator. A pivot language is a common, shared standard (here a “de facto standard”, not open and democratic. Esperanto would have been). If we hire a translator each time we talk to another individual, it becomes very costly. APIs are my voice and your ear, the “support” for the communication to technically happen. Data are the content of my speech.
B- From open source software to open source interoperable modules
Let’s take the example of the product catalog. An agent (producer or distributor) needs a nice tool to manage its catalog, stock, and pricing table for their different customer categories. The agent wants to be able to share this catalog potentially through many distribution platforms, just like an agent offering a carsharing road wants to push it through many carsharing apps to maximize the chance to find passengers.
Concretely ALL producers today work with more than one distribution channel, and the different distributors they sell through are unlikely to use the same management tool.
There are activists that I know in France who want to build a dedicated tool for catalog management, based on the semantic web standard, interoperable with any distribution platform (using the Data Food Consortium standard hopefully). This module should of course handle connections between catalogs through the “product chain model” we have worked on, and “recipe” that makes the connection. So we can, whatever the application, display the product chain of any product in the world (utopia is what drives evolution :-)) This catalog module should be agnostic of the nature of the product sold, it can be food but it can be other things, the logic remains the same on what is and should do a catalog.
C- What is OFN? Where is the line between what we do and where we integrate?
I am deeply asking myself that question: should we persist in “internalizing the product catalogs into OFN”? Or "shall we join forces with those type of actors to build together a very well thought open source module that we will “consume” through a nice semantic web API in our marketplace? I think we should stop talking about open source software. And start thinking open source interoperable modules.
Maybe you’ve seen the open source software for CSA OpenOlitor? It is a platform presented as many modules. One for instance is “membership management”. There are hundreds of apps proposing membership management. Let’s stop building again other membership management modules. Let’s take it out of all our OS software and build together a nice module as a base block we can all use to offer membership management to our users. Same for volunteer planning for packing. Same for accounting. Invoicing. Maybe Shops ?
We are now doing that in France with the network of commoners and coops (like energy coop, telecom coop, etc.), we are building on Odoo a shared module to handle the life cycle of “shares”.
I like the question we asked ourselves in our last gatherings: what is OFN ? And where do we draw the line of what we do and where we integrate with others? I think the thing we should really build ourselves might be thinner than what we do today. Product catalog for me should be out of OFN, but we could be cobuilder of that module. Invoicing, even the basic module, should be out of OFN.
We can do customer integrations for some users who have specific needs. BUT we need in our mainstream offer, in our public platform to offer a basic aggregation of blocks that work well together in a single user experience. Like the user will not see that we use some external invoicing block. Or some external product catalog. So she can create and manage her catalog within OFN, event if it uses that external block. She can invoice directly within OFN, even if it uses that block, etc. It will not really be “within OFN” but it will look like when she is in OFN. But if she wants to access her catalog in OpenOlitor platform she will be able to, without any friction. She will have a single source for her product catalog and can handle her stock, etc.
I know this is pretty aligned with the discussions we had about “breaking OFN into domains” and building our API and displaying our front end based on that API. But I think my vision goes further than that. I think we should get rid of some of those domains purely and start building some of those blocks with others.
Happy to discuss on some concrete cases and opportunities soon…