Opinionated Software

From our current perspective, limits on the extension of a built-in model might seem incredibly simplistic and self-defeating. And it is, but this introduces us to the concept of opinionated software.

With all software, you’re very much bounded by the target use case that software was designed for, and, by extension, the opinions of the development team that built it. What they think is a good idea is passed down to you, and hopefully you think it’s a good idea too. You don’t get an opinion other than the one they give you.

Some software is a platform on which you can build anything. Other software is designed to do a specific thing. The former tends to allow a wide range of customization, while the latter allows a much narrower range. Indeed, some software is designed to do something so specific that the developers have imbued it with extremely strong opinions of how it should be used, and you can’t easily overcome those opinions to get it to do anything else.

Why would anyone agree to this? Because if your opinions do actually line up with theirs, then it can make your life easier.

What if someone designed a software system to work for the exact usage scenario you have, in the exact way you think it should work, and no other way? Those are some strong opinions, but if they line up perfectly with yours, then everything is fine.

And this is the crux of opinionated software. Your affection for it is directly proportional to how closely its opinions line up with yours.

All software is opinionated to some extent, the only question is how strong those opinions are. It’s a spectrum.

Strongly opinionated software tends to thrive in industry verticals. For example, museums have a sub-genre of content management called “Collection Management” which is used to manage all the information related to items in their collections. These systems are quite opinionated, which works because managing a museum collection is a specialized practice, around which a lot of patterns have developed. In scenarios like these, there’s a better chance the development team’s opinions will line up with the user’s.

Beyond industry verticals, almost all content usage falls into patterns. Let’s consider the common requirement to display a list of pages. Here are some of the patterns you might see:

Each entry in the list of pages displays the title which is linked to a dedicated URL for that page
The title of each entry is accompanied by a summary and perhaps a date
The list can be ordered by a specified attribute (often Date Published or something similar); this order can ascend or descend
Each entry in the list displays an image in a standard alignment and size, also linked to the dedicated URL for that page
The list is paginated to a set number of entries per page, with page navigation links at the bottom

Make no mistake – this list is, in itself, a set of opinions of what you might need to do with a list of web pages. But in my experience, these are a pretty mainstream set of opinions. (And, yes, that statement is also an opinion.) A system might provide the capabilities of this list as base functionality, and those features would likely satisfy a significant percentage of customers.

Does this list of features address your specific use case? If so, perfect. If not, you have a few options:

Customize your implementation using the tools provided by the system
Find a different system that gives you the features you need
Change your use case

That last one is more common than you might think. Often the evaluation of a system involves some level of “requirements settling,” where the purchaser is aware the opinions of the system don’t totally match up with their use cases. Since it’s good enough in other areas, and the concessions they need to make aren’t huge, they just settle for what it offers, adjusting their plans and expectations to match.

Ideally, however, you usually want CMS software to be generalized. The trend in the market – above the very low end – is for platforms on which you can build or configure a more specific set of functionality to serve your individual situation. In these cases, fewer opinions are better.

Here’s a dynamic that’s often true, but few customers will confess to: some customers want a piece of software to enforce its opinions.

I’ve seen this in the intranet space quite a bit – intranet usage falls into very common patterns, and many intranet managers want both a system to manage their intranets, and opinions on how to manage it. An “intranet in a box” is an attractive product for many organizations, because it promises to deliver both practical functionality and a suggested model of usage.

Many customers look at software vendors as some of the most experienced practitioners in their field, and these customers consider a software product to come with a bundle of built-in, hard-won consulting. They take comfort in this.

There’s often an unconscious bias to think the way packaged software does things is correct, and if it doesn’t do something, then that thing didn’t need to be done. Vendors are selling both a software product and a philosophy/methodology for its usage and the practice area it addresses, and for some customers, this is exactly what they want.

Evaluation Questions

Is the system designed primarily for any specific vertical that might dictate the content model it supports?

Is the system designed primarily to publish content to a specific channel – web, mobile, etc.? What opinions does it enforce on that channel?