Well it only took 13 years for the idea to be taken up.

https://www.mgateway.com/documents/universalNoSQL.pdf

An observation: the administrators of this forum regularly report the size of this community, currently an impressive number in excess of 12,000 developers, yet, as can be seen from the OP, numbers of views of even the most popular posts is tiny by comparison.  From what I've seen, a typical post will get around about 50 views, and each comment will add a further 50 - a meagre 0.4% of the total community.  This leads me to believe that there is actually only a small core (~50?) of regular contributors and readers (many of whom, I suspect, are actually ISC employees)

It does make me wonder what, if anything, most of those 12,000 Cache/IRIS developers read, and what site(s) they use instead. Perhaps they don't read anything? 

My reason for raising this is that, for a third-party developer of solutions for these technologies, reaching and informing those 12,000 developers is a significant issue and problem, and it's fairly clear to me that this forum currently doesn't provide a very effective solution to that problem.

My question/challenge for 2023 is therefore what do folks here (the regular 50?) think can be done to provide a more effective way to reach that reported developer base?

Use the tried and tested mg_python: 

https://github.com/chrisemunt/mg_python

If the applications you're providing to users are REST/web/browser-based, you can make use of connection/process pooling, eg via an implementation in another back-end language, to avoid/minimise these issues.  A good example is the Node.js/JavaScript-based QEWD framework or its recent evolution  - qoper8-fastify - I've described the latter in another recent posting here on Node.js. 

Another alternative is to use our mg_web interface (you may want to check out our mgweb-server framework which packages up mg_web for ObjectScript-based REST APIs to save you a lot of effort): this uses modern web servers (eg Apache/NGINX) to manage connections to IRIS in a parsimonious way.

Some holiday reading:

QEWD: https://github.com/robtweed/qewd

QOper8-Fastify: https://github.com/robtweed/qoper8-fastify

Using QOper8-Fastify with IRIS: https://github.com/robtweed/qoper8-fastify/blob/master/IRIS.md

mg_web: https://github.com/chrisemunt/mg_web

mgweb-server: https://github.com/robtweed/mgweb-server

Take a look at our other language interfaces and front and back-end solutions too -  see https://www.mgateway.com

Well, if it was me, I'd keep that and the rest of my logic in JavaScript/Node.js and access the Cache database using the mg-dbx interface.

... well they don't need to develop their own.  They could actively support and work with third party experts in this area and simply make available suitable public interfaces.

I should point out that if you use the in-process API connection to IRIS from mg-dbx, you don't need to install anything on IRIS - just enable the call-in interface and away you go.  You do, of course, need Node.js running on the same physical hardware as IRIS for such a connection, but it's significantly better performance than a networked connection.

Ideally yes, I would agree, but you're up against the publicly available interfaces for IRIS. What would you suggest?