Individual instances are creating a wealth of integrations to solve user problems. This work is being done in response to our slow delivery pipe and . In different countries, people are implementing the same things, duplicating time and effort. A problem might be solved in one place while another place is saying the users’ needs are impossible.
We are starting to realise some of the potential of OFN through integrations - a distributed commons of tools to solve the needs of our sector. However we are not managing our commons as a commons. We reinvent the wheel, wasting precious time and resources. It’s just not very aligned with what we stand for.
Using open source tools to create a global server that connects to each OFN instance with template integrations that any instance can use to connect their server to the tools we need.
The range of integrations we already have across the community is huge, including:
- Transforming reports
- Integrating with accounting tools
- Connecting marketing tools.
- Improved email communications between hubs and shoppers.
- Customisation of OFN processes
- Enabling simpler collection of user fees.
- Managing metrics in a more streamlined way.
- Project management and notification tools.
- And more
For the whole community to benefit from the commons we need to be implementing these such that if one instance builds it, every instance can see, understand and use it. THis will involve more than just development work. It will involve creating templates, documentation, simple videos. This means there is scope for technical and non-technical roles as the project grows. It will also create pathways for non-Rails devs to contribute to our global commons, which might be very welcomed by instances approached by technies that want to volunteer. The intention is that we make it possible for non-techie people to set up sophisticated integrations.
To implement this on a global scale we’ll need to meet a few requirements:
- We need to meet EU GDPR rules
- We will ideally make use of open source tools as much as possible
As such, the best option is to use N8N - a sophisticated open source workflow tool. We can host this tool on an EU server, meaning that data flows will follow GDPR.
N8N enables integration of any API with a range of already connected tools. It enables the creation of templates such that people can log in and create the systems they need easily from saved templates. Our own self-hosted version is free, with just the cost of the server, meaning we are paying a fraction of the cost of other workflow tools that are currently being used.
Coordination of this role will require technical and product input. Product will be responsible for coordinating priorities, building specifications for development and ensuring proper documentation. Technical responsibility to implement the spec. Already in some instances there are people employed in these technical roles so ideally these people will start moving their implementation focus toward the global integrations pool.
We can create a Github repo that will backup our N8N workspace and use Github to manage our priorities.
With the recruitment of a Global Metrics person it seems appropriate that the first set of integrations are based around global metrics. Building global metrics should extend the work already done building a metrics database in metabase, using the metrics already developed by Jana as a starting point. This will provide the opportunity to:
- Connect each instance to the integrations server
- Build some initial integrations with OFN reports
- Safely connect OFN databases for any data not available on reports
This will therefore create a baseline of interoperability and examples from which future integrations can more easily be built within N8N.
While this work is in development we can begin prioritisation of the global integrations tasks to follow, that will involve:
- Understanding the most pressing global issues that can be solved through integrations
- Moving bulk tasks out of Zapier to save on costs for instances