We have been getting a steady stream of feedback from users of the PAX compiler about our new business model for PAX’s evolutionary successor, Apex Athena.
In this post, we address some of the specific issues that are recurring in this valuable feedback, and offer a path for users of PAX, or any other traditional embedded scripting engine, to explore the new paradigm Apex Athena and Apex Muse are attempting to pioneer.
Does this mean drinking a bit of our Kool-Aid, so to speak? Sure, but it’s great tasting stuff, and we’re willing to give you a generous sip, in the form of our Community Edition (soon to be released) and an “Early Adopter” program that we’re in the process of putting together to help us finalize the Professional Edition feature set.
Before we talk about the Early Adopter program, let’s first provide the definitive explanation regarding why we’re departing from the traditional Delphi component vendor model.
Many PAX users are intrigued by our new direction, but some are concerned, because they’re used to the traditional Delphi component model where you pay a small (usually single developer) fee, get full compilable source, unlimited distribution rights, and lifetime use of the product (or at worst, pay an annual renewal to keep new editions coming along).
In other words, they were quite comfortable with the no-strings-attached model, but this was one in which the success of PAX compiler itself could not be sustained.
Unfortunately, this model doesn’t suit the purpose we envisioned for the runtime when we acquired it. Nor was it suitable for PAX sustainment, either.
What many PAX customers don’t appreciate is that, although for their narrow application purposes PAX really rocked it compared to almost any alternative in the Delphi space, PAX as an ongoing business concern failed.
Among other reasons, PAX failed because it’s simply not sustainable for a technology as sophisticated and frankly value-added as PAX was (and now Athena is, even more) to be commoditized to this business model.
Additionally, malicious users pirated PAX, in some cases using it for less than legitimate purposes. These plagued the original author and undercut his ability to make a living with it.
The reality was that Pax wasn’t a toolbar widget or some new fancy grid component that any intrepid Delphi developer could create and support, but a full-on compiler/interpreter with both general purpose and domain-specific uses that span the full range of possible computing applications.
The market for embeddable scripting technologies, however, is relatively small, or in any case deeply niche, and overpopulated with free or low-cost alternatives, even in the Delphi market.
“If that’s the case,” you wonder, “then why did you, Apex, buy it?”
The story of how we came to acquire PAX is interesting, at least to us, but more important for this discussion is to understand the reason for our acquisition.
The truth is, we didn’t initially seek to acquire PAX at all.
Rather, we were interested in building a new kind of scripting runtime, initially as an R&D effort, eventually to be utilized as a low-level component of our Unify! stack. To that end our team worked with the original author of PAX to devise what later became (and is still in the process of becoming) Apex Muse.
As Muse evolved, we realized PAX had nearer-term potential for the kinds of use cases we were devising Muse to satisfy, and it made sense to acquire it and align it with that vision rather than simply to deprecate or discontinue it. We gave the completely re-envisioned, deliberately re-designed PAX a new name: Apex Athena.
Now, we initially thought the first release would be a bug-fix on PAX and released quickly. We were ready to promote it as a drop-in replacement for PAX and even beta tested it as such. Because of the re-design and the broader vision enveloped in Athena (versus Pax), the release of Athena was delayed until the Community Edition could support the broader range of capabilities envisioned for this technology.
In the end we acquired PAX and turned it into Athena in order to further our vision for legacy application modernization and data interoperability, seeing Athena as a kind of ying to Muse’s yang. It also allowed both runtimes to be optimized for the different kinds of languages they support, with different target developer profiles in mind.
Apex Athena’s mission is to bring enterprise developers skilled in popular imperative, statically compiled languages like C#, Visual Basic, Pascal, etc., into the 21st century of serverless computing, specifically in the context of complex data exchange orchestrations and semantic interoperability supported by our Unify! stack.
While “serverless” platforms on all the major clouds already exist, the model we offer in Apex Unify! will be entirely domain-customizable and not dependent on a particular cloud infrastructure. Rather, it will be easy to deploy into environments at any scale.
By “serverless” we mean to support a flavor of Rapid Application Development (RAD) in a distributed n-tier environment, which is very different from the traditional front-end GUI application world that PAX Compiler grew up in. Our vision for application extensibility is in the service of modernizing monolithic applications, not in the service of native GUIs only.
This modern vision for “application extensibility” is achieved by converting large monolitic applications into micro-services across all the layers of the modern enterprise stack. This model for RAD fits nicely into Embarcadero’s new focus on IoT and server-side Delphi, but more importantly, it’s where the industry is going.
Apex Olympos Community Edition aims to provide the initial “taste” of this strategy—our “Kool-Aid” if you will—to the smallest possible scale: the desktop. It aims to provide hobbyists and independent developers the kind of tooling to create distributed applications that previously were only possible by the Googles, Amazons and Microsofts of the world.
The Professional Edition will provide additional features, including an SDK for import libraries and special tooling around refactoring monolitic applications, toward that end. RAD Studio IDE integration, as well as editing support for popular text editors on non-Windows platforms, will also be part of the Professional Edition.
Our “Early Adopter” program will make this available to select developers sooner than we plan to make it generally available. We are still trying to figure out exactly when that will be, and currently are focused on getting the Community Edition out the door first.
We hope this helps explain our intentions behind transforming PAX from a conventional component in the Delphi vendor market into a transformative technology squarely focused on legacy modernization and distributed computing.
Our expectation is that as Athena’s new mission is made clearer with the release of the Community and Professional Editions of Olympos, not to mention the Unify! stack, developer uptake will be broader and more enthusiastic than if we simply continued to commoditize it per the PAX model.
We believe the Delphi toolchain can play an important role in the future of distributed computing. Our vision for Athena and Muse as enabling technologies for Unify! is key to giving Delphi a truly full-stack presence in the modern enterprise.