The "customers" for Metagov infrastructure

[thelastjosh]

Problem: make architecture decision for Metagov infrastructure that optimizes tradeoff between medium-term potential value to devs and short-term work

In what follows, Metagov infrastructure = Metagov gateway = set of Metagov platform+service plugins.

Background: In the strategy sessions I discussed how we need to refocus in the near-term from the dev experience for gov services + gov tools to the actual governance experience for communities. In other words, we are prioritizing "end-user" communities as customers and de-prioritizing devs. HOWEVER, we still need to make architecture decisions related to Metagov infrastructure that may, in the medium-term, have implications for devs that want to use Metagov's infrastructure for their own services and tools. Note that Metagov infrastructure has a set of distinct customers compared to "Metagov policy mashups" and the UI product we discussed in the strategy sessions.

We agreed that a hosted instance with a UI for tool + policy management at metagov.org makes sense and should be implemented. The hosted instance will use the plugins we have built, expose settings + stats to end users (through monitoring & oversight), and expose the necessary integrations that our team needs to write and execute policies for communities that we serve. The main customers of the hosted instance will be communities and our internal team.

On top of that, we discussed an architecture decision for Metagov infrastructure between:

1. most restricted but easiest: Django app that operates within a driver
2. somewhat portable: Python library that operates within a driver
3. current architecture, most portable but problematic to maintain: co-located service with public endpoints

We felt the Django app route would be easiest; however, we wanted to understand more about what the potential customers for Metagov infrastructure would be. We also raised some concerns that certain end-user communities would not be satisfied with a hosted instance at metagov.org and would want to run their own instance on their own server.

Right now, the three potential classes of customers for Metagov infrastructure include:

1. Tool & driver devs who want lots of platform integrations so that they can deploy their project on top of those platforms
2. Web3 versions of the above, who may have specific concerns with consuming a hosted instance
3. Our internal dev + policy authoring team

Of the above, we've interviewed a few in (1) and it does not seem that they have burning need for these platform integrations. They are also not willing to trust the integrations we build in live products, at least not yet.