Microsoft Access has an Anemic Third-Party Ecosystem...But There is a Silver Lining

During Access DevCon Vienna 2023, conference host Karl Donaubauer and Kevin Bell teamed up to propose the community should build a VBA/Access package manager:

It will come as no surprise to this audience to learn that neither VBA nor Access has a package manager.

Kevin Bell and Karl Donaubauer teamed up to propose that the community should come together to do something about that. ...

The two each reviewed the years of stagnation when it comes to official feature releases from the Access team, the highly fractured existing marketplace for custom tools and addins, and the negative impact the lack of a package manager has had on the Access/VBA ecosystem.

They are not wrong.

The lack of a robust package manager has no doubt had a dampening effect on Access and VBA's recent popularity, especially as other languages have made it easy for new developers to get started with advanced functionality by simply pulling in the right packages.  The "Batteries Included" mantra of Python was a big part of what led to its meteoric rise as one of the most popular programming languages.

But all those easily accessible dependencies have a dark side...

How Azer Koçulu Broke the Internet

You've likely never heard of Azer Koçulu, but his private feud with an obscure chat app and JavaScript package manager, NPM, briefly brought the internet to its knees in 2016.

Programmers were left staring at broken builds and failed installations on Tuesday after someone toppled the Jenga tower of JavaScript.

A couple of hours ago, Azer Koçulu unpublished more than 250 of his modules from NPM, which is a popular package manager used by JavaScript projects to install dependencies. ...

Unfortunately, one of those dependencies was left-pad. ... It pads out the lefthand-side of strings with zeroes or spaces. And thousands of projects including Node and Babel relied on it.

The Long, Black Dependency Train

One of the key features of modern package managers, like NPM and NuGet, is the ability to automatically chain dependencies.

I wrote about the concept of manually chaining dependencies in the context of my own personal code library:

Let's say that each train car represents a code module in your code library.  Each seat on the train represents a function within that module.  And the literal couplers between train cars represent the figurative coupling between code modules.

Now, imagine that you need to use a single function from a single module in your code library.  So, you import that code module into your application.  Your train is now one car long.

Following the import, you compile the code to make sure you're not missing any dependencies.  Sure enough, there is a problem.  The module you just imported won't work unless you also import a different module.

Funnily enough, the compile error has nothing to do with the one function you need.  Rather, it is a different function in the module that has the dependency.  It doesn't matter.  The only way to get the code to compile is to import the other module.  Your train is now two cars long.

It turns out the second module you imported calls procedures in two other modules in your code library.  You import those two modules.  Your train is now four cars long.

The third module you imported calls procedures in another module, but luckily it's one that we already imported.  Unfortunately, the fourth module calls procedures in four modules, only one of which has already been imported.  That means you need to import three more modules to get your project to compile.  Your train is now seven cars long.

With my personal Access code library, this is a manual process.  The manual nature of the process is annoying, but it means I'm constantly reminded of each and every dependency in my applications.

Contrast that manual process with the automated dependency chaining that you get with a modern package manager.

Let's say you use the package manager to import a single package–named Foo–into your project.   You may think your project now has a single dependency.  But the Foo package could depend on three other packages.  And each of those packages could have dependencies of their own, just like in my example above.  The difference is that you don't see all those dependencies.  But they are still there.

That's how a package with a single line of code can wind up with 72 dependencies:

As a result of learning about the left-pad disaster, I started investigating the NPM ecosystem. Here are some of the things that I observed:

• There’s a package called isArray that has 880,000 downloads a day, and 18 million downloads in February of 2016. It has 72 dependent NPM packages. Here’s its entire 1 line of code:
  return toString.call(arr) == '[object Array]';
• There’s a package called is-positive-integer (GitHub) that is 4 lines long and as of yesterday required 3 dependencies to use. The author has since refactored it to require 0 dependencies, but I have to wonder why it wasn’t that way in the first place.
• A fresh install of the Babel package includes 41,000 files
• A blank jspm/npm-based app template now starts with 28,000+ files

Those poor JavaScript developers whose web applications broke back in 2016 had no idea they were riding on such a long, black dependency train.

About that Silver Lining

Let's get back on track, shall we?

If there is a silver lining to Microsoft Access's lack of a robust third-party ecosystem and modern package manager, it's that Access applications rarely have dependencies more than a single layer deep.  In fact, outside of dependencies on other Office applications (e.g., Excel, Outlook, or Word), many Access applications have no dependencies at all (OK, besides the Access runtime itself).

While open source advocates love to bash Microsoft, the fact remains that Microsoft has a very strong profit motive to keep its software in good working order.

While the marginal value to Microsoft of adding new features to Access remains relatively low (see chart below), the potential reputational cost of an Azer Koçulu-style disaster is astronomically high.

With almost every large company relying on Access applications in some way, a critical bug in Access could diminish its standing among enterprise customers. And that is the last thing Microsoft wants to do in the middle of an AI arms race. If you're pushing $30 monthly MS 365 Copilot subscriptions, you don't need any negative public relations with those same customers.

Yes, Microsoft Access has no real third-party ecosystem to speak of.

While that is one of many factors keeping new developers from learning Access, it's also helped keep dozens of my own Access applications in service for decades.  And, in all likelihood, for decades to come.

Acknowledgements

• Cover image created by DALL-E-3