Closing the Gaps: Making Joomla Harder to Ignore
Part 1: The Problem
Written by: Jason Crimmel

This is the first article in a series about a question that has followed me through more than twenty years of using Joomla!: what makes a platform useful in the real world? Joomla! Core matters enormously, but people rarely choose a CMS because of Core alone. They choose it because the platform can solve the problems in front of them. If one requirement forces a project into custom development, there are abandoned extension or an outside service that does not fit the rest of the site, that missing piece can matter just as much as anything built into the CMS itself.

That is what I mean by closing the gaps. I am not talking about stuffing every imaginable feature into Joomla! Core or adding extensions just to increase a number in a directory. I mean the practical holes that make Joomla! harder to choose even when the platform itself could support the solution. Those gaps are where extension developers can make Joomla! stronger, and they are a large part of why QuantaCade exists.

Part 1 is about the problem itself. Joomla! has a strong foundation, but real projects are built around workflows: people join organisations, pay for services, schedule time, attend meetings, ask for help, sign documents, protect data, recover from mistakes and connect one system to another. When too many of those ordinary requirements end with "Joomla! cannot really do that without leaving Joomla!," the problem is bigger than one missing feature. It becomes an ecosystem problem.

More than twenty years with Joomla!

I started using Joomla! around 2005, somewhere around the Joomla! 1.0 era. I honestly do not remember the exact release anymore, but what I do remember is that Joomla! was where I learned. It was the platform that showed me how a website could become an application without my having to build every piece from the ground up.

One of the early extensions that stayed with me was Appointment Booking Pro (developed by Rob Stevens, of Soft Ventures, Inc.). At the time, I was a one-man business. I was doing everything: marketing, scheduling, customer service, field work, compliance, accounting and all the other jobs that come with trying to keep a business moving. I certainly did not have time to build an appointment-booking system myself, but I still needed a dependable way for customers to secure appointments. Appointment Booking Pro solved that problem for me. Somebody in the Joomla! community had already built the missing piece, so I could put it to work and Joomla! suddenly did something much more valuable for me than simply manage pages and articles. That experience is still one of the clearest examples in my mind of why an extension ecosystem matters.

Over the years I have experienced the opposite feeling too. Anyone who has used Joomla! for a long time probably knows it: you need something that seems ordinary, you are sure somebody must have built it, and you start looking. Sometimes the answer is excellent. Sometimes the most promising extension has not been updated for years, solves only part of the workflow or assumes a completely different use case. Sometimes the answer becomes custom code, a separate SaaS product or a compromise you did not want to make.

I have flirted with WordPress over those years as well. There is no point pretending otherwise and no reason to turn that into a rivalry. WordPress demonstrates how much an ecosystem can influence a platform's usefulness: when users expect a plugin to exist for almost any common requirement, choosing the platform feels easier. My preference kept coming back to Joomla!. I learned on it, I like the way it thinks, I have rejoiced in what it can do and suffered through what it cannot, and seeing Joomla! succeed matters deeply to me.

Joomla! competes on two fronts

That history is why I think Joomla! competes on two fronts. The first is Joomla! Core. Core has to remain secure, maintainable, accessible, performant, modern and pleasant to develop against. Joomla's ACL, multilingual capabilities, content architecture, APIs, extension system, update mechanisms and all the other work that goes into the platform are the foundation. Without a good foundation, the ecosystem has nothing solid to build on.

The second front is what people can actually accomplish with that foundation today. A business owner or agency evaluating a CMS usually arrives with requirements, not an architectural scorecard. Can we manage memberships? Can customers book appointments? Can staff work with users without handing out Back-end access? Can we run support tickets? Can people sign agreements? Can we connect the files and services the organisation already uses? A CMS can be technically capable of supporting all of those things and still lose the project if the needed solutions are missing, outdated or too difficult to assemble.

That does not mean Core should absorb every business workflow. I would argue the opposite. Joomla! Core should not become a help desk, membership platform, booking system, digital-signature service, storage bridge, CRM and everything else someone might someday need. Joomla! is extensible precisely so specialised developers can solve specialised problems without turning Core into an impossible collection of unrelated products. The healthier question is not "Why did Core not build this for me?" but "Does Joomla! have a credible answer for this requirement, and if not, should someone in the ecosystem build one?"

That is where I think extension developers carry a responsibility that is sometimes easy to underestimate. Core developers give us the platform. Agencies and integrators see the requirements that recur across client work. Users discover the friction first. Extension developers are in a position to turn those recurring needs into reusable solutions. When a common requirement keeps ending with "Joomla! cannot really do that," I think we should ultimately challenge the ending of that sentence rather than simply accepting it.

Why QuantaCade exists

QuantaCade grew out of that attitude. I did not want the mission to be "make more Joomla! extensions" because more is not automatically better. If a category is already served by several excellent, actively maintained extensions, creating one more copy of the same idea may be perfectly good business, but it does not necessarily make Joomla! meaningfully stronger. The problems that interest me most are the ones where the absence of a good answer makes Joomla! harder to choose, harder to use or easier to leave.

That is what "Making Joomla! Harder to Ignore" means to me. It is not a claim that Joomla! should dominate every project or that every competing CMS is doing something wrong. It is a goal of reducing the number of times a person can reasonably say, "I like Joomla!, but it cannot handle this important part of my project." Every serious gap that gets closed expands the range of projects for which Joomla! can be recommended with confidence. Sometimes I may be the developer who closes one of those gaps. Sometimes another Joomla! developer already has, and that deserves just as much attention.

I also do not think every missing extension is automatically a meaningful gap. Some ideas are useful only to a narrow audience. Some problems are already solved well. Some belong in custom development, an integration or perhaps even Core rather than a new commercial extension. The harder question is deciding which missing pieces repeatedly create enough real-world friction to weaken Joomla! as a choice. That question deserves more than a paragraph, and it is where the next article in this series will go.

The gaps are in ordinary workflows

The gaps I am talking about are often not exotic. They appear in the routine parts of running an organisation online. A site may need memberships and renewals, appointment or meeting scheduling, document signing, support requests, dependable backup and recovery, user-facing self-service or a clean connection to an outside service the organisation already depends on. None of those requirements sounds unusual. In many projects, they are simply part of the work.

A gap also does not always mean that no extension exists. Sometimes the category exists but the available choices are no longer actively maintained. Sometimes several extensions each solve one piece, but the organisation still has to stitch together the actual workflow. Sometimes the only practical answer is to send users to a separate SaaS platform and manage two disconnected systems. Sometimes a solution technically works but forces ordinary staff into the Joomla! Back-end, requires repeated manual intervention or leaves an agency responsible for custom glue code it knows it will be maintaining for years.

Any one of those compromises may be acceptable. Joomla! does not need a native answer to every problem, and outside services can be the right choice. The concern is the pattern. If common requirements repeatedly push a project outside Joomla!, require custom development or depend on ageing solutions, those points of friction accumulate. A platform can have excellent architecture and still become harder to recommend because too much of the real work happens somewhere else.

That is why I think the extension ecosystem is not a side issue. For many users, the ecosystem is the practical surface of Joomla!. It is where the platform either becomes a membership site, a customer portal, a scheduling system, a community, a business tool or whatever else the project needs - or it stops short of becoming one. Core makes those possibilities possible. The ecosystem determines how many of them are realistically available today.

What I decided to do about it

For a long time, I was mostly on the user side of that equation. I benefited when another developer had already solved the problem I was facing, and I worked around it when nobody had. Eventually I decided I wanted to do more than point at some of the missing pieces. I wanted to try closing a few of them.

QC Digital Signature came from one of those moments. Electronic signatures were not interesting to me because Joomla! needed another feature to put on a list. They were interesting because a Joomla! site could already contain the users, forms, memberships, customer records or service workflows surrounding an agreement, and then the transaction often had to leave the site for the final step because the Extension Directory offered no solution for document signing. I believed there was room for a serious Joomla!-native answer to that kind of workflow, so I built one.

Other projects have also made me more cautious about the phrase "Joomla! can do that." Technically possible is not the same as practically solved. A feature label can hide an entire workflow behind it. "Digital signatures" is not just drawing a name on a PDF. "Memberships" is not just granting a user group after payment. "Scheduling" is not just putting a date on a calendar. Once real people depend on the result, permissions, communication, state, failure recovery, administration, mobile use and all the awkward edge cases become part of the problem too.

That does not mean every extension has to become enormous. Sometimes the best answer really is small and focused. It does mean that closing a meaningful ecosystem gap requires enough of the surrounding workflow to make the solution dependable in real use. I have learned that lesson repeatedly while building QuantaCade, and later in this series I want to spend more time on what it means to close a gap well rather than merely check the feature box.

Just as important, QuantaCade is not the point of Closing the Gaps. If this series becomes a tour of my products, it has failed. Some gaps will be areas I work on. Some are better solved by developers who understand those problems far more than I do. Some apparent gaps may turn out not to be gaps at all because a strong Joomla! solution already exists and simply deserves more attention. The mission is not to prove that I have every answer. The mission is to make Joomla! itself harder to ignore.

The next gap is already out there

After more than twenty years with Joomla!, I do not want to spend the next twenty simply noticing the places where that does not happen. I want to help close some of those gaps, and I want other developers to do the same in the areas they understand better than I do. The useful question for an extension developer may not always be "What feature could I add?" It may be "What ordinary problem is still making Joomla! harder to choose?"

Agencies and site builders are in a particularly good position to notice those problems because they see the same workarounds repeatedly. Users notice them because they live with the friction. Developers notice them when the same requests keep arriving from different directions. But noticing a missing capability is only the beginning. We still have to separate genuine ecosystem gaps from one-off wishes, weak demand, problems already solved elsewhere and ideas that do not belong in a new extension at all.

That is what Part 2 - Finding the Gaps - will explore. How do we recognise a real Joomla! gap? What signals should developers pay attention to? What do repeated SaaS workarounds, recurring custom builds, ageing extension categories and project requirements tell us? And how do we decide which missing pieces are important enough that solving them could genuinely expand what Joomla! can do?

I have seen enough of Joomla! to know that its strengths are real, and I have been frustrated enough by its weak spots to know that affection alone will not make them disappear. The platform deserves both confidence and honest scrutiny. Core has its work to do, and so do the rest of us who build around it. My goal with this series is not to tell people to ignore Joomla!'s shortcomings. It is to take some of those shortcomings seriously enough to do something about them - and, one gap at a time, make Joomla! harder to ignore.