Metabase includes a core set of the most common database drivers, but there are many more databases which we are unlikely to want to take on the burden of maintaining/testing/distributing/supporting for various reasons.

We have lots of documentation for writing new drivers https://github.com/metabase/metabase/wiki/Writing-A-Driver and a way to load drivers from separate .jars, but AFAIK there's not a lot of instructions on how to release a community developed/maintained driver in a separate repository, which is mostly likely how we will want new drivers to be handled.

I'd suggest that "Chapter 10: Submitting a PR" of the driver documentation (which is not yet written) should actually have instructions for releasing/distributing drivers in a separate repository, rather than submitting a PR. If a community driver gains enough usage we can potentially work with the maintainer to merge it into Metabase proper.

A few things we might want to do:

• "hello world" example driver
  • https://github.com/metabase/sudoku-driver
• suggest a naming convention for repositories (e.x. metabase-driver-foo for a database called foo)
• suggestions for how to publish built versions of the driver? (if we do that rather than suggesting users build from source we should have a strong disclaimer about security)
• instructions on how to set up CI
• suggestions around versioning?
• have a wiki page linking to community drivers (with a disclaimer that they are not tested/supported by us)
  • drivers linked to on the wiki must set up CI and be passing