In these weeks I’m wondering what will be the evolution of Business Central AppSource. I had already spoken about the issues working with third party APPs with closed source (IP Rights and Open Source) and with V24 Microsoft will take a step forward:
For resellers who develop per-tenant extensions for customers, or for publishers who create AppSource apps, it isn’t uncommon for them to build on the work by other publishers, and thereby take a dependency on these. However, in order to develop or test, they need access to the AppSource apps they depend on.
Today, this involves a tedious manual process where resellers and publishers with dependencies must contact publishers owning the applications they depend on and ask for symbols to develop against or runtime packages to test with. This is not only required once, but continuously as new versions of the Business Central first-party applications and the publishers’ applications versions emerge, making the whole process tedious, time-consuming, and error-prone.
In this version we plan to unblock developing and compiling against external applications in containers and test in online sandboxes.
So, reading this news, I’ve noticed the two scenario defined by Microsoft: “resellers who develop per-tenant extensions for customers” and “publishers who create AppSource apps“.
Interesting.
For sure, many partners confuse these different approaches and if you want to go fast with the implementation of BC, you need to be on the right track.
No AppSource, no party
Be on the AppSource with serveral APPs is considered mandatory for partners. AppSource is a global shop window and there you can show your muscles and prove the ability to maintain APPs over time.
But the question is: all the partners that have APPs on AppSource are real publisher?
Being a publisher requires strong methodology, dedicated team, R&D and a continuous chase to changes of the new versions.
To be a good target for publishing, an APP requires hundreds of users, documentation and onboarding guides.
Moreover a third party support is necessary to help who develop on-top of a published APP.
Currently there are 4800+ offers on AppSource for Business Central but only about 800 of these are four-star rated and, in the first page, the APP most rated has about 70 reviews.
“It’s a long way to the top If you wanna rock ‘n’ roll” 🎶
Choosing the right app
Imagine you are a multinational corporation that needs to implement Business Central in Italy and wants something specific about our electronic invoicing. So, you go on the AppSource and search for “italian invoicing“.
You count a dozen of APPs, one for each major italian partner. The APP most rated has 8 reviews.
Maybe you find a good partner (if it has time to help you 😅), but with so few reviews, it’s hard to choose.
The reality is that currently the AppSource APPs are more partner-driven that customer-friendly.
Once again: “It’s a long way to the top If you wanna rock ‘n’ roll” 🎶
Localizations issues
Imagine you have published an APP to calculate salesperson commisions and you targeted it as world-wide.
Imagine you have published an other APP to calculate sales prices with several algorithms, still for world-wide.
Imagine a new APP to change commissions based on calculated prices: you need to publish a “bridge” APP:
Now imagine a local tax on commissions and a local indirect tax on prices: you need to publish two another “bridge” APPs:
In the end, imagine that you published a local reporting tool for commission per prices:
Six (!) APPs to maintain… now it’s clear why Microsoft has only one “Base Application” 😅
I think that optional dependencies or conditional compiling will be necessary in the future of AppSource.
Other approaches
Some days ago I read this interesting article on LinkedIn:
Unveiling BcNuGet: The Future of Business Central App Distribution
https://www.linkedin.com/pulse/unveiling-bcnuget-future-business-central-app-distribution-bmsie/
And I remembered an old post which described the benefits of PTE in a complex scenario with an intelligent usage of preprocessor directives and conditional compilation to keep several logical APPs in only one APP.
I was recently surprised by a new colleague and the speed of doing his first APP. He did everything himself after less of two week working with Business Central. This means that BC is easy to customize and on-line there are a lot of resources to help the new developers. Full cloud approach is the success factor to go fast.
So I imagined a future with a kind of “AppSource-NuGet” with the same shop window but with the ability to “cherry pick” the libraries that you need, compose your dream customization APP and above all view what is inside…
Conclusion
Do a project only with AppSource APPs requires a skilled helmsman 😅 and the time to wait a good engineering. Do a project only with PTE makes difficult to reuse the code.
In other scenario (non BC), a stable APP has at least thousands of installations. Here (BC) we are talking about hundreds or, most probably, tens of installations. Few installations means few experience. Few experience requires continuous adjustments and reengineering, in the AppSource world you cannot do disruptive changes. Mixing the same APP before in PTE and after in AppSource is not possible at the moment.
Something different is needed, stay tuned! 💡