I think it is easier said that done. The GTM completely changes of a product like this. Now you have to build API, DSL and eco-system to support it. I absolutely agree that your take. But building an eco-system is hard.
You don't need a DSL if you, for example, "just" use Javascript. You need an API anyways. You do need to do some operational fudging around of course.
I'm going to also counter with something super important: you build out stuff like this, and suddenly you can handle your own feature requests faster. User wants X to happen after Y? Write a tiny event script that they install into their env. They need some bespoke field? You have custom models, and now your events reply to that.
In the fractal of requirement differences that is sales pipelines, not doing this just feels like causing yourself a bunch of dev pain.
From a technical perspective, how would one structure a program like this? Where the main developers also use the same 'engine' to develop the product itself, while also exposing the same engine to the third parties?
The first such case I have seen was Maya (the 3d software) when it first came out use a custom scripting language called MEL(Maya Embedded Language) to develop the entire user interface and corresponding actual entity manipulations. Third party plugin developers also use the same MEL.
I thought wow, and that is still impressive today.
I work with a CRM that allows users to add additional functionality by uploading definitions in XML "spec" files.
The XML specs are a combo of metadata and code and define all functionality in the system including SQL tables, forms for adding/editing data, query nodes for the internal query system, arbitrary business processes etc. They can include SQL stored procedures to run or call out to bundled C# code, and they can be accompanied by HTML templates that generate UI elements where appropriate (e.g. user facing forms).
There are a lot of moving parts and the documentation is a bit patchy but it's a really ingenious system for adding modular functionality, particularly in a CRM setting. Pretty much all of the "official" functionality is built using this spec system.
> You don't need a DSL if you, for example, "just" use Javascript.
I'm in agreement, but I think you still need to build tooling around it.[1] At the very minimum:
1. The code editor needs to be part of the system - pointing the customer at VS Code is a dealbreaker.
2. Debugger needs to be provided: you can't ask the customer to hit F12 and learn how to use the browser's devtools.
3. Documentation is still needed: At least one folder of samples/examples, and at least a single exhaustive reference of all the functions provided by system.
Finally, I wouldn't go with Javascript: Non-developers are less-likely to understand something as complicated as Javascript.
You're using a language that has subtle and hard to find bugs if variables are declared in one of three ways, when a different way is more appropriate. Same with the two different ways to define functions. Same with the difference between all the forms of a for loop. Same with the distinction between a prototyped object and a class. Same for the usage of instance variables vs class variables.
Add typescript support to the mix and you may as well not even bother looking for customers.
[1] I just created a system that uses a vanilla webcomponent for client-side includes of HTML snippets, using only HTML. It's not possible to now set breakpoints in any `script` element that is included using this webcomponent, e.g. `<my-include remote-src=./common-stuff.html>` where `common-stuff.html` has script tags.
This is a developer's answer to a business problem. Scriptability added to a non-developer's tool is usually just enough rope to hang them on IME, and often ends up in a whole arsenal of footguns.
IME, this is how an enterprise-contender product should generally be built when it wants to touch many domains across the business. Starting with a reasonably rigorous access control model enables deeper business integration--and this is a product that, to be successful, can't live without that.
Man, if only SaaS would do just this instead of reinventing the wheel with their brain-dead scripting languages and limited APIs where they remove useful information and links between data.
