“Extensibility” vs. “User Extensibility”
When users “customize” software against a requirement, this requirement fits into three levels of “vendor predictability.”
General: This are requires that the vendor expects and their software exists to handle.
For example, every CMS vendor knows their customers will want to model content to fit their requirements. This is a plannable thing, and CMSs literally exist to support this.
Patterned: These are requirements that fall into patterns – they’re common enough that a vendor will provide options for them.
For example, when modeling content, every customer will likely want a simple text field to store some aspect of their content, and they will likely want to be able to require that field. So every vendor provides the ability to specify a mandatory text field, because they’re used in 99% of implementations.
Specific: This is a need that the vendor can’t predict – this is a specific to the customer.
For example, every CMS customer might want to model content, and most of them want mandatory text fields, but this one customer wants to store the name of the song they were listening to when they wrote a blog post, and they want to find this song using the Spotify API, then retrieve the lyrics from Genius, then run some sentiment analysis on those lyrics text, compare it to the same analysis on the blog post text, and use those numbers to compute a “Music-Content Emotional Difference Coefficient” and store that on the content so it can be used search, ordering, and templating, where it would be output with “smiley” or “frowny” icons based on the value. This is an utterly unpredictable need.
It’s that last one that’s problematic. How well does a vendor support “creative” requirements?
Some vendors wouldn’t support this at all. They would require the customer to do this completely offline and just copy and paste the resulting value. They would require a “manual intervention” for this requirement – a human-gapped process.
Other vendors might provide a toolset for this. Their software would have a set of features that are optionally used to enable these requirements without a manual intervention, and presenting the illusion to the user that the software was designed to do this all along.
For our last example, here are some tools a vendor might supply:
A custom property type for “Music Selector.” This type would allow for a customize UI which enable the editor to enter a search term, and select from results displayed in the editorial UI.
A event-based programming model which would allow some executable code to “catch” the event of content being saved, checked-in, or published, then perform the communication and calculations necessary to retrieve the lyrics, and calculate the value in some manner.
A templating system which allows the value to be turned into variable text.
And here’s a key: each of those tools solves a patterned need. When combined together, they can solve a specific need.
Now, this is just a general view of extensibility. If you look at the all the tools up there, they can all be created in such a way to require root access to the application.
The trick to user extensible software: how can we create these tools in such a way that they does not require root access to create or modify them?
Some of the above list are easier than others:
Properties are usually configurable to a point, but something like this requirement would need logical code to be deployed somewhere.
Event-based programming is quite common, but the code that executed is always compiled into the application (it has root access). To use external code, you would need a webhook. This is also common, but presumably the webhook would return with a calculated value, and how will you get that inserted into a property? Is it even possible to do this without some logical code execution?
Templating systems are commonly – but not always – extensible without root access.
Put in colloquial terms, the core question of user extensibility is –
How much can a user adapt the software to their specific requirements without requiring root access?
Or, in much more common terms –
“How much can we do without a developer?”