PHP didn't conquer the web because it was the most elegant language. Plenty of people will tell you it isn't. PHP won because of what was built on top of it.
Anyone old enough to remember the Betamax vs VHS war already knows this story. Sony's Betamax was the better format by most technical measures. VHS won anyway, because JVC's open licensing brought longer tapes, lower prices, and bigger shelves at the video store. Ecosystem beat engineering. By 1988, Sony was making VHS players too.
That distinction matters more than it usually gets credit for, and it's the lens I want to use to look at where BoxLang is right now.
The WordPress effect (and friends)
If you came up through web development at any point in the last twenty years, you've used PHP applications even if you've never written a line of PHP. WordPress, Drupal, Joomla, Magento, phpBB, MediaWiki, Moodle, osCommerce. None of those required the user to be a developer to deploy. They needed someone who could follow installation instructions, click through an admin panel, and maybe edit a config file. The five-minute install was a real cultural phenomenon, not a marketing slogan.
The numbers tell the story. PHP currently powers around 72% of websites with a known server-side language, and WordPress alone accounts for a substantial portion of that footprint. The web of installable PHP applications didn't grow because PHP was technically superior to its peers. It grew because there were things to install, the things were useful, and they ran on the kind of cheap shared hosting anyone could afford.
There's a corollary to this that the CFML world has been living with for years. If you're part of the CFML community (or even CFML-adjacent), you've inevitably heard the complaint at some point: "we can't find ColdFusion developers." And I get that, we can't, at least not easily in most cases. Meanwhile, somehow, everyone seems to be a PHP developer. Your nephew. Your cousin's roommate. The intern at the marketing firm. The guy who built his dad's restaurant website over a weekend.
That isn't because PHP is inherently more learnable or more interesting. I'd be willing to bet that the vast majority of those people walked into PHP through an application. They installed WordPress for a side project, hacked a theme, fixed a plugin, and one thing led to another. The application was the entry point. The language came along for the ride.
The language became popular because of the applications. Not the other way around.
ForgeBox and the shape of our current ecosystem
ForgeBox is awesome. I want to say that first because the rest of what I'm about to write could be misread otherwise. The catalog of modules covering authentication, ORMs, caching, mail, payment processing, file storage, security, and on and on, is a genuine strength of the BoxLang and CFML world. None of what follows is a complaint about ForgeBox.
But here's an observation worth sitting with. Almost everything on ForgeBox is aimed at developers who are already building something. ForgeBox is the npm of our world, not the WordPress.org of our world. Those are different markets with different needs, and serving one well does not automatically serve the other.
A non-developer can't install a ForgeBox module and have a working blog. A small business owner can't install a ForgeBox module and have a help desk. The modules are the parts. What's missing is the appliances.
The gap I'd love to see filled
What I'd love to see, and what I want to gently advocate for in this post, is a richer catalog of complete, opinionated, ready-to-run applications built on BoxLang. Things someone could clone, configure, and deploy without writing CFML or BoxLang themselves. Categories that come to mind:
- Forums and community software
- Help desk and ticketing systems
- Newsletter and mailing list tools
- Small e-commerce starters
- Wiki and documentation platforms
- Event and meetup software
- Portfolio and gallery sites
I'm not asking anyone to drop what they're doing. I'm naming what would be exciting to see. The difference between an ecosystem with a hundred modules and an ecosystem with a hundred applications is enormous, and it shows up in places you might not expect: developer mindshare, hosting providers' willingness to invest, conference talks, hiring conversations, and the kind of stories that get told about a platform.
"But it has to be enterprise-grade"
This is the objection I'd push back on gently. WordPress in 2003 was a fork of an abandoned blogging platform called b2/cafelog. It was the side project of a 19-year-old college student named Matt Mullenweg and a UK-based developer named Mike Little. The first release was barely different from the thing it forked, and fewer than ten people were using it at the start.
That is not enterprise software. That is a side project, shipped in public, in 2003.
Today, WordPress runs CNN, The New York Times, TechCrunch, Disney, Sony Music, Microsoft, and the official site of the White House, among many others. It did not start there. It got there by being shipped, used, improved, and adopted, one site at a time, over the better part of two decades. The lesson is that enterprise follows mass adoption. It very rarely leads it.
The mistake, I think, is starting from the wrong end. If you set out to build "enterprise help desk software in BoxLang" the project never ships, because the ambition is calibrated to a market that hasn't even noticed BoxLang exists yet. If you set out to build "a help desk a five-person company could self-host," you might actually ship something. And once you ship, the rest of the path becomes available to you.
Why BoxLang is well-positioned for this
A short list, without overselling. BoxLang is free and runs on the JVM, which means deployment options are broad and the underlying platform is battle-tested. It brings modern language features without abandoning the CFML community that produced its core ideas. CommandBox makes installation and dependency management approachable for the kinds of developers who would otherwise reach for Composer or npm. The Ortus module ecosystem already exists to build on top of, which means the parts are there even if the appliances aren't.
What's not there yet is the cultural habit of shipping complete applications. That's the gap I'd like to see closed.
Walking the walk
Before I get into what I'm building, an acknowledgment I want to make plainly. I'm not the first person to ship a ready-to-run application on the CFML and BoxLang stack. ContentBox, the flagship CMS from Ortus Solutions, is the obvious and important example. It powers real sites, it's mature, it's actively developed, and it's exactly the kind of application I'm advocating for more of. The point of this post isn't that the catalog is empty. The point is that it could be much fuller, and ContentBox is proof that the model works on this stack.
With that context, here's what I'm working on.
BX-Blogger
BX-Blogger is the engine running this very blog. It's open source, in active development, and deliberately small.
BX-Blogger is not a smaller version of ContentBox, and it isn't trying to be. The two scratch very different itches. ContentBox is a full content management system, built for sites with multiple editors, multiple authors, structured content types, and the administrative tooling a content team needs. BX-Blogger is the opposite end of the spectrum: a hyper-focused, purely markdown-driven, developer-blog-centric application. No full WYSIWYG editor. Limited content workflows, content written in markdown, a few opinionated defaults, and a clean reading experience.
The relationship is roughly analogous to Hugo or Jekyll versus WordPress. Both have their place, both serve real users, and neither makes the other unnecessary. If you're a developer who writes in markdown and wants a quick and easy application to share them, BX-Blogger is for you. If you need a full CMS with full editorial workflows and a non-technical admin experience, ContentBox is the right call. Different tools, different jobs.
TesseraBX
TesseraBX is the deliberately larger example. A full help desk and customer support platform built on ColdBox and BoxLang. The current architecture includes PostgreSQL 16 with pgvector for AI-powered search and similarity, CBWire for reactive UI without a JavaScript framework dependency, AdminLTE for the admin interface, a modular structure so pieces can be reused or replaced, and the proven Ortus modules underneath: cbSecurity, CBFS, and others.
The point of TesseraBX isn't that it competes with Zendesk on feature parity. It's that help desk software is currently a market that punishes small teams. As of 2026, Zendesk plans run from $19 to $169 per agent per month, with AI add-ons that can push a 10-agent team's bill well over $1,000 per month before any negotiation. For a self-hosted alternative, the math works out very differently. That gap is the opportunity.
It's worth saying that both BX-Blogger and TesseraBX are still in active development. They each have a few bugs to work out, but both are largely ready for use today. They're also designed to be deployed in containers, which keeps the install path short for anyone who wants to try them. That's part of the message. The ecosystem grows when people ship version 0.1 in public rather than waiting for version 2.0 in private.
The platform is ready. The builders are the question.
Here's what TesseraBX, more than any project I've worked on, tells me about the state of BoxLang. A single developer can build a help desk platform with vector-backed search, a reactive UI, modular architecture, and the kind of security baked in that mid-size companies actually need. None of those pieces required exotic workarounds or hand-rolled infrastructure. PostgreSQL with pgvector, CBWire, ColdBox modules, cbSecurity, CBFS. All of it sitting on BoxLang. All of it composable.
The platform is ready. That's the part I want to be plain about. Whatever the reasons are for BoxLang not having a richer catalog of ready-to-run applications, technical capability is not on the list. The runtime, the framework ecosystem, the database tooling, the deployment story through CommandBox, none of these are the bottleneck. If a single developer can build something like TesseraBX on BoxLang, the platform isn't waiting on better tools. It's waiting on more builders.
What's missing is people choosing to ship version 0.1 in public, and then version 0.2, and then 0.5, and so on. WordPress wasn't built in a quarter. ColdBox wasn't built in a quarter. Every meaningful piece of open-source software is the result of someone deciding the world should have it and then putting in the years. The opportunity sitting in front of the BoxLang community right now is exactly that kind of opportunity.
An open invitation and the hard ask
I'm not in the business of telling anyone what to build. If you've already got a full plate, you've got a full plate. But if you've ever thought about building something on BoxLang, and the question in your head has been "is this platform really ready for what I want to do," I think the answer is yes, and I'd love to see what you make.
Here's the part that needs to be said plainly. As a community, we can't expect Ortus to build these applications for us. Ortus Solutions has already done more for the CFML world than almost anyone has any right to ask. They built ColdBox. They built CommandBox. They built ForgeBox. They built ContentBox. They built BoxLang. They've kept this community alive and growing through years when the rest of the web was busy declaring CFML dead. The work that Luis, Brad, Jorge, Cristobal, and the rest of that team have put in is staggering by any honest measure. Asking them to also build the entire application layer on top of their own language is neither realistic nor fair.
Did Rasmus Lerdorf build WordPress? No. He built PHP, and let other people build WordPress. Did the PHP core team build Drupal, Magento, phpBB, MediaWiki, or any of the other applications that put PHP everywhere? No. The community built those, and the language rode that wave to dominance. The split between the people who build the language and the people who build the applications is not a CFML problem or a BoxLang problem. It's the natural shape of every successful ecosystem.
Which means this part falls on us. Not Ortus. Us. The developers reading this post.
If you're working on something already, share it. Even if it's rough. Even if it's only half-built. Star the repos of projects you'd like to see succeed, including the ones I've mentioned and any others you know about. Open issues. Send pull requests. Write about what you're doing.
That's how PHP got its empire. It happened slowly, one project at a time, and at every step there was a moment when someone decided that the messy version was good enough to make public. We can do that too.
Well, anyway, that's just my $0.02.
