Should exporters be organized by Provider instead of by metric?

[etsauer]

We've been discussing how we are going to refactor our exporter directory structure to fix some of the upside-down-ness of our imports, but I'm also starting to wonder if the architecture itself might be flawed. We continue adding new providers, and also look to add more types of metrics outside of just Software Delivery, I think that we are going to end up with a many-to-many relationship between providers and exported metrics, but to any given customer.. they probably will only care about one provider of each of the metrics.

Let's look at software delivery with the providers we have and some that we might implement in the future

committime
- OpenShift (or Kubernetes or Public Cloud)
  - GitHub
  - Gitlab
  - Bitbucket
deploytime
- OpenShift
- (Kubernetes)
- (Public Cloud)
failure
- Jira
- ServiceNow
- (Trello)
- (Version1)

And now some future metrics we'll likely be adding, slightly less well defined:

Platform Adoption Metrics:
- OpenShift
- Kubernetes
- Public Cloud

Flow Load (breakdown of work types: bugs, feature, risk, debt)
- Jira
- SericeNow
- Version1
- Trello
- GitHub/Gitlab/Bitbucket Issue tracker?

It seems like we are going to be moving towards a model where we are gathering multiple metrics from the same tools, and I don't think it will make sense to have an exporter per metric anymore. Instead I propose this:

• We look to refactor so that we have a module/library that contains all of our individual metrics defined in abstract classes.
• We refactor our exporters such that we have one exporter per provider/tool, and it can implement ANY of the metrics that are appropriate.