Upgrading to 6.2.1 and the latest Nativescript-angular (if using angular) and the latest proplugins; should fix MOST issues that 6.2.0 had. However, I still highly recommend the webpack rewrite rules at the bottom of the post to solve ALL the issues.

NativeScript follows the SemVer process; so normally they would have bumped a major version on breaking changed. This break is mostly an un-attended side effects of a couple things. And unfortunately they didn't realize it broke things, so we now have 6.2 which breaks things... Oh well, mistakes happen, life will go on. And so this post is to make you aware of what things you want to change when you upgrade to NS 6.2.0...

To Upgrade or not to Upgrade, that is the question!

I do want to make sure I am VERY clear -- I do NOT think this was a bad change, nor do I think NS 6.2 is a bad release! My apps will be upgraded to it. It offers a lot of good features and fixes. It is just that being aware of the issues will help you make sure you don't have any issues with it when you do upgrade to it.

Lets dig in to the issue.

So lets get some details, first about 3 major versions ago in 2017, my business partner and buddy Nathan Walker proposed on issue 4041 to move the nativescript tns-core-modules into its own namespace. @nativescript along with other nativescript pieces being put into that parent namespace...

So based on this you might guess where the source of the issue lies now.

If you read the above issue; you will notice Peter (another awesome developer) and I both recommended that they do this in the 6.0 release. I personally felt like a hard break would be the safest course of action. Just eliminate tns-core-modules totally. Since they already were totally breaking the build tools, and also breaking other plugins things in v6.0 -- they might as well add this to the pile so we deal with all the breaking changes at one time in plugins. Unfortunately, our advice wasn't taken, or it was missed and so here we are with a very interesting breaking change that I honestly did NOT foresee when I recommended they do it in the initial 6.0.

There are three different issues here that stem from the same cause:

First, if you are using NativeScript-Angular and use any third party plugins -- you might find that they are failing because NativeScript-Angular was moved into the @nativescript/angular namespace. The compatibility imports for the old namespace; is apparently missing a couple redirects so plugins trying to load them fail. I'm sure these plugins will be updated shortly; but right now they are broken. (This has been fixed in the latest version of NativeScript-Angular)

I do NOT know yet if NS-Vue, NS-Svelte, or React-NativeScript have any issues; but odds are a fairly low with them because they are third party and were not moved into the @nativescript namespace, so apps depending on this probably are NOT affected directly (other than by any other plugins.)

Second, because of the design of the tns-core-modules redirect, the redirects waste a little bit of running memory. If your app or plugin imports tns-core-modules/BLAH (which all apps do before 6.2) then webpack will give you Object #1 tns-core-modules-blah, however, when a plugin or the core modules loads @nativescript/core/BLAH you get Object #2 nativescript-core-blah -- they LOOK the same but they are different objects each using memory. This does increase a little bit some parsing and memory that the V8 has to use because you now have basically more than a single framework in memory. Some of this is mitigated based on how objects are tracked; but some of it isn't. So this creates some other un-intended side effects of little bit more GC pressure, more ram usage, and the nasty pitfall we will discuss later...

Finally, if you are using any plugin that does any sort of class monkey patching, they will now all fail -- in this category is things like my very own nativescript-platform-css, nativescript-orientation. The reason why is because of the above allocation issues. Object #1 != Object #2. monkey patch Object #2, doesn't monkey patch Object #1. This is a corner case; as it requires you to actually replace the class (i.e. the top level object). So any plugins that rely on nativescript-global-events which extends and enhances the page class; were affected.

As an aside: The good news is virtually every one of my plugins on https://proplugins.org has been updated to have a NS 6.2 version. If you find a plugin that no longer works after you updated to 6.2; let us know and we will attempt to get it fixed. The 6.1 -> 6.2 fixes are very minor; so they can be rapidly put into the plugins.

One final note -- Please see the method to update the webpack at the bottom to have webpack rewrite tns-core-modules to @nativescript/core this is still highly recommended as some plugins will still be broken if you are still using the tns-core-modules redirect version.

The low level nitty gritty details - Proceed with caution.

For those who are interested in the nitty-gritty; we will walk through why #2 and #3 occur in NS 6.2. Please note this is VERY simplified -- The actual TS -> JS code is a bit more complex and a wrapped object. However, this should give you an idea of the why's...

V8 basically keeps a object map of how a object looks in memory; so if I have file "Blah" with class HiYa -- that looks like this:

export class HiYa {
function hi() { /* do something */ }
}

When it exports it has a unique signature. In NativeScript this is compiled down to ES5 code. So this will basically look like this when all said and done:

Now when I do a const HiYaRunnerMaster = require('@nativescript/core/blah'); The Blah.js file is loaded into memory; parsed and then a runnable object representation of this is passed back to HiYaRunner, lets call this HiYaRunnerMaster. So far so good.

Now for the NativeScript tns-core-module redirects / compatibility layer.. This is the exact code that you see in tns-core-modules/* in 6.2... It basically redirects to the @nativescript/core version of the file. Seems simple, and unless you are paying close attention you might not even see why this actually is a problem.

So when I do a const HiYaRunnerFromTNS = require('tns-core-modules/blah'); it loads the above code and runs it. . It first defines the __export function, then runs that function on what it gets from the require of @nativescript/core/blah . Seems simple enough. Lets break this down into each step to what the v8/JavaScriptCore engines do.

const tempObject = require('@nativescript/core/blah'); -- THIS object is the same/identical HiYaRunnerMasterObject as we got earlier when we ran it. Every time we do this specific require statement, we get the exact same object. Which is what we want!

__export(tempObject); This runs the export function, passing in our HiYaRunnerMasterObject which so far doesn't seem like an issue.

for (key in HiYaRunnerMasterObject) { we are looping through every property in HiYaRunnerMasterObject

if (!exports.hasOwnProperty(key) verify the exports variable doesn't have this key property already.

exports[key] = HiYaRunnerMasterObject[key]

And behind the scenes exports is passed to the HiYaRunnerFromTNS at the end.

Did anyone else see what happened in step 5? First, exports is a 100% BRAND NEW OBJECT. (our Object #2). We then COPIED all the properties/functions from Object #1 (HiYaRunnerMasterObject) onto this new Object #2 (exports). Each copy is actually a new piece of memory that point to the old object's key value. So the new exports[Key] = old.value. in simplistic terms has two separate memory slots; "Key" and Value". So exports[key] is always a new memory pointer (of key) that either points to the original object's [key]; or to its own copy of a un-boxed object. So the memory usage could be 50% of the original object to the exact same memory usage as the original object, all depending on what the values (boxed or unboxed) are. In NativeScript it should be much closer to adding the 50% additional memory, not the 100% as a worst case number as almost all values on a nativescript key are objects.

At the end, in step 6 we used the brand new object to assign to HiYaRunnerFromTNS. Whoops; so we now have TWO different objects in memory with two different sets of memory usage.

This means that if you monkey patch the HiYaRunnerFromTNS copy; you are not actually monkey patching the actual original and running version. So in several of my plugins, this caused them to break as the monkey patching basically never occurred as far as the running copy of NativeScript was concerned.

In addition their is one more potential gotcha; I'll make a simple example:

If I do Obj1.a.value = 2; then Obj2.a.value === 2 because both a's point to the exact same memory location with a "value" key in it . However, if I do Obj1.a = {value: 10} then Obj1.a then creates a brand NEW object which also has a value key; of which it has the value of 10 in it. And Obj2.a continues to point to the OLD original object with the value = 1. So even though your objects initially started pointing to the exact same value in memory. A new object assignment will replace just that objects location.

Why does this matter? When since the running instance of NativeScript is the @nativescript/core versions of the object. And your applications code will all currently require tns-core-module versions; you DO initially have two objects but they should all start out pointing to the same memory locations. Just like our example earlier (Obj1.a = Obj2.b) However, if you change a value that is NOT using a setter -- then the value you just changed won't be propagated to the running version, and you will have Obj1.a = {value: 10} and Obj2.a = {Value: 1} and you won't have a clue you just did a noop statement.

I do want to say the above potential gotcha scenario is very UNLIKELY, all code that I can think of runs through a setter; a setter function should be getting and setting the original object's value, and thus they shouldn't go out of sync. But corner cases can and do occur. So my recommendation for anyone updating to NS 6.2 is to do...

Recommendations

Long term, replace ALLtns-core-modules/ with @nativescript/core/ and all nativescript-angular/ with @nativescript/angular/everywhere in your app. No longer have ANYTHING pointing to tns-core-modules/ or nativescript-angular -- pretend those old namespaces no longer exist and were deleted.

Update to the latest @proplugins if you are using any @proplugins, as most of them have already made the transition, as this will at least save you time on that aspect.

Short term tip (and highly recommended until they have a solid fix):

Richard Smith, posted a good tip that can quickly get you working -- you can add a rule to your `webpack.config.js` file. Find the alias section and add:

This makes things a lot cleaner and over time more times should end up in the @nativescript namespace. Currently in the @nativescript namespace is:

Core Modules

Theme

Angular

Core Modules

Since they added the ns-root, ns-landscape, ns-phone, etc; in the prior version of NativeScript they have added even more css functionality in this version. ns-light and ns-dark are now added values which you can use to select specific theme color rules. They are added depending on the devices theme. Along with that change, more css optimizations, including hsla color support were added. A long awaited and very welcome fix to allow values to be reset to default when css rules are disabled was also finally done. Overall just the CSS fixes are worth the price.

Another cool change is they updated they revampled the android transition code. Should be better and more customizable. In addition Android also got ContentInset properties on the ActionBar. And iOS got selectedSegmentTintColor on the Segment bar.

Finally, the awesome community PR that was snuck into this release is Peter Staev's async read/write addition. readAsync and writeAsync allow async access to the file system.

CLI

The CLI team has fixed several outstanding bugs; things like Asset generation, several webpack issues, cocoapod fixes.

V8

I'm going to create this new v8 Section, because Android and soon iOS will both be using the same v8 engine. v8 was upgraded to v7.7 which adds:

Lazy feedback allocation - this reduces the memory load of the v8 engine, which is always good to have on mobile devices

Android

IOS

Fixed a Mashalling issue from "unsigned char *"Fixed losing some exceptions in TS from runtime

A lot of changes to the new v8 version of the iOS runtime that is still in alpha testing to eventually replace the JSCore version... This new runtime has pretty close to the same feature parity as the Android versoon. I'm sure the iOS team would LOVE you all to test out this runtime on your apps to verify they work properly -- you can do so by using tns platform add ios@alpha-v8 to tell it to use the v8 runtime.

NativeScript 6.10 has several fixes, and a couple new features to make it worth your time to upgrade. 6.1 has to be one of my favorite recent releases.

Being biased here, the best fix is the PR I did; it allows the tns command line to actually be used with our awesome https://proplugins.org site. You could easily use NPM to work around the issue; but it is always better if the standard NativeScript cli tooling also works. So, I am ecstatic to see this show up in 6.1. So now completely removing my bias; the new ios wifi deployment support (which I haven't tested); is something I have really needed for a while, so awesome job team!

Core Modules

Their are a couple changes in Core modules that are worth noting. First of all; for those who have used my awesome nativescript-platform-css plugin for years; the NativeScript team finally decided I was right! 😀 They have not only stolen, er, borrowed, the idea to put device type in the class name (ns-android & ns-ios) , but they also borrowed the same idea I did in my nativescript-orientation plugin, which is put the orientation (ns-landscape & ns-portrait) into the class also. Unfortunately, I am a bit sad they still didn't have the foresight to borrow my poor-mans-media query system; it is still way better than nothing. Nor did they decide to use the device name css system, or any of the additional classes like .notch. So if you still need media query or actual device name support or anything else the platform-css; then you can continue to use the ns-platform-css plugin. And the ns-orientation plugin still offers the ability to force rotation and/or lock the rotation to a certain direction, so neither plugin will be discontinued because of the additional functionality both plugins still offer that the team didn't borrow.

In addition another community PR was accepted to add CSS calculation support! Unfortunately do to a minor oversight, it is broken in 6.10, but I would guess it should be fully fixed in 6.11.

CLI

This team has hit several home runs this release with me. In addition to getting my PR merged which solves the npm issues. They also added awesome iOS Wifi deployment support. And added iOS 13 and Xcode 11 support. Overall the CLI release looks to be a very awesome release.

Android

Android added several cool things in 6.1 also. First and foremost; Initial Kotlin compatibility has been added. This is very preliminary; so many things may not work.

Second they upgraded the the v8 Engine to 7.6 which adds the following features and enhancements

New much faster JSON parser

Promises.allsettled

In addition to the cool features added, they have also updated it to allow the latest Android tools and latest gradle. Also, they now added gradle.properties support so you can easily define properties next to your other gradle files...

IOS

Added metadata generation from inner membersFixed issues with latest version of iOS and Xcode

To install Webpack & HMR support:npm i nativescript-dev-webpack@latest --save-devNote: you need to have nativescript-dev-webpack as a development dependency for HMR to work.

To install latest NativeScript Angular pluginnpm i nativescript-angular@latest --saveYou will then need to install the actual angular bits; which as of this post v6 is currently supported.

The addition of all the additional analytics/tracking to the CLI reminded me; you can disable it permanently; if you value your privacy by doing:tns usage-reporting disable && tns error-reporting disable

We currently have a massive number of broken plugins, hiding the few flowers in all the weeds as I discussed in the first State of Plugins post. These flowers still need nutrients and maintenance efforts to keep them alive as we outlined in the post: costs of a plugin. We went into the long tail of support, and how this burns out authors, and how little (if any) money is actually donated to an author. How have you supported any of the plugins you've used? When authors leave the community; the flowers they planted, almost always die and are replaced by even more weeds, which of course just propagates the issues… So we are currently at a point where only a few unpaid authors maintain virtually all the plugins.

We also discussed how the two plugin sites deal with all the weeds, and the side effects of both stances, and finally finished off with all the additional issues that are present in the plugin community. Overall, in summary, our community and plugins in general need some help, and we the community has to solve it...

All of these issues, is what pushed me to look for a better solution, all of this information has been percolating around my brain for a while. Several solutions have been tried by different people (including myself) and unfortunately each has failed over the last couple years.

So lets cover the issues in brief and some solutions that we have brainstormed, discovered, or found other communities implementing as solutions...

Finding the good plugins in all the bad plugins.

There is basically three ways to do this. The first I have actually tried with my PNR (https://plugins.nativescript.rocks) site. I foresaw this issue years ago, which is why I added the ability to put comments and rank plugins. Unfortunately; the community has decided that doing this is too much work (and I don’t disagree – I don’t even do it! ). So very few plugins have actually received a rank or any comments. I also tried to automatically rank plugins, but if anyone has looked at the auto-generated ranks on any of the sites – I’ll be blunt, they are also worthless. So ranking via computer or via the community seems to be a completely failed effort.

The Verified Plugin program - this initially sounds like a awesome idea on its surface. Unfortunately, if you delve into the issues it brings; lets just say that in the grand scheme of things; of what it offers verses what it takes -- this is easily the WORST thing to ever happen to the NativeScript plugin community. have a whole blog post detailing the whys, which will be released at a later point in time...

The final way is to create a curated list of good plugins that are evaluated by people, so that they can be known to be working and/or in a good state. This requires people in the community to spend some time on this and spend more time testing the demos and maintaining this curated list of working plugins and testing it on new releases. Overall this seems like the best solution; but it requires a lot of time and effort by someone(s) .

Working Plugins?

Next issue is now that you found a potential match; does it have a demo? Unfortunately a large number of plugins have bad meta-data and so they don’t even link to their git repo (even the NativeScript team has a few of these). Which means you have to google to try and find the original repo (if it even publicly exists) and then finally download and run the demo. So this step is also a pain, and can be time consuming in some cases, but assuming the author has a repo and a demo, you can try it out. If it doesn't , hopefully it has docs so you can either create the quick demo or integrate it into your app to see if it works.

And the issues keep piling on...

This brings up another issue; now that you have a demo that actually appears to run, you still have to test all the functionality for the most part upfront to verify it is fairly bug free and it will work for your purposes.

Is the author trustworthy, can I trust their code? (How many of you audit any of the plugins?)

Is the plugin and its dependencies under a good/safe license? I've personally seen several plugins that were Apache / MIT licensed; that use GPL dependencies. This means your actual program needs to be released GPL if you use this plugin.

What happens if the plugin has a bug? Does the author fix it rapidly? Is the plugin even maintained? If you have the time to debug and create a PR, will it even be looked at, let alone merged and then pushed to npm?

Does the plugin author get any donations for a cup of coffee for all their hard work? Wait, that is my issue, and the answer is "nope, almost never". .

Wow, a whole load of interesting issues. Well, now that I have outlined some of the issues, I believe, all or most of them, are solvable with one community driven program.

I want to state upfront, I do know everyone initially is not going to like this proposed solution -- We saw the problem, and we sincerely care about plugins, and the community! We want to see the best for it. As such we are currently using our own time, money, and skills to try and solve this problem in a method, that we believe, the community can and will support. So in total transparency, if you have a better idea – I sincerely welcome you to propose and build it. The more actual solutions to all these issues, means our community has more wins!

Magic?

So what magic is this you speak of? Do we really have a wand we can wave and solve all these issues??? Believe it or not; yes!

I am very proud to announce a plugin authors program to solve all of this.

The Details

The idea behind ProPlugins is that it is a curated list (solves: finding plugins) of highly maintained and top-quality plugins (knowing if a plugin will work), from top authors (trustworthy). Issues are resolved appropriately, PR’s are looked at in a timely fashion. Metadata in the plugins are correct (metadata issues) and link to the proper repos and even a link to download the most current demo. All plugins will be required to have at the minimum, a NativeScript-Core demo (the demo issue). All plugins have documentation (the doc issue). All plugins are supported by all the authors on the ProPlugins team (the maintenance issue).

Phase ONE requirements are tough enough to move things forward; however, they are not as stringent as phase two and three as we have a whole outline of how to get from here to there and then to have the very best plugins any community can possibly have.

In other words; we as the top authors in the community are replanting our flowers in a new weed free garden, and then as the caring gardeners we are, taking care of all our plugins as the ProPlugins team.

So how does the community fit in? The other part of the solution is how to let the community help solve the issue… In the past the community hasn’t really helped much with maintenance of plugins (*3), it hasn’t helped much with actually handling plugin issues or answering questions on the repos. Nor has the community helped with rating plugins. So basically the community has been mostly absent… So why is this? Each of these items takes time, and most of the community has a job they do, then spend time with their family, and finally most enjoy doing other hobbies. So they don’t have the time to help with all these things, and many times assume someone else will help, in other words there's not much incentive . This is very common in the open source world, the number of stars a project gets verses the so few people that help. NativeScript has over 17,000 stars; but has only so far 100 contributors; and the majority of that 100 are paid Progress employees. So instead of requesting the community donate their time in areas that it obviously has not been willing to help in for the last 4 years; we will change the narrative…

This is going to be a subscription program. I know what you are thinking, "arewe nuts???" Please bare with me; while I explain why we choose this route and why you will actually really want this route...

The community helps by paying a small monthly subscription to access all these maintained plugins. They don’t have to work on them, they don’t have to help with issues, or do anything they haven’t wanted to do for the last 4 years. So the community can continue as-is, but it is now going to help support itself a different way. This low monthly fee is then used to fund all the maintenance and enhancements on all the plugins in the ProPlugins program. You the community, will be supporting all the authors of the plugins, making it sustainable open source. Your subscription will help support the maintenance of the actual plugins you use. So now this becomes a totally win-win situation! The plugins you use become higher quality; which then means you spend less time searching, fixing, and testing them. Second because the costs are spread out across the entire community your monthly fee is so small, you won’t even miss it. This co-operative helps everyone (including you) in the community out. A simple low cost on your part can = High Quality for everyone. Honestly how much better can it really be?

So the better question to ask is, what is your time worth? In this case, ProPlugins will save you massive amounts of time, energy, money and frustration. Instead, it gives you what you need on a silver platter worth millions(*1) for less than the cost of a meal at a cheap fast food restaurant… Can you really afford to pass it up?

Being the plugin developers that have been in the community the longest; we hope the community will want to go in this direction; since we believe this will fix virtually all of the issues that have plagued us for the last 4 years, and gives us all an incredibly bright future. But, to emphasis how committed we are to the community, let me give you a small example: When I started planning the ProPlugin transition, I personally had planned on moving pretty much all my plugins over to the ProPlugins. However, when I ran all the numbers, I found out that my NativeScript-Permissions plugin is used in a large number of plugins as a dependency. Because we don't want to force the community to do anything, it will continue to be supported on the public npm so that everyone can continue to use it without us breaking anything (and it already fully supports AndroidX!). Our heart really is for the community!

Who is behind the ProPlugins?

Multiple of the top 10 plugin developers have come on board for the initial release. In addition several others have committed to joining in the very near future and are working through the NS 6 issues in their plugins -- but were unable to join the start of phase 1 due to the very short window that we had to work in. We were aiming to release very close to NS 6’s release; and we still ended up launching a bit later than we wanted to.

So what is the cost?

We are starting it out at $9.99 per month for the first 500 subscribers; then it moves to 12.99, and finally at 1000 subscribers it goes to 15.99. We want to reward the first subscribers, that are willing to become a major part of the solution. In addition, as long as you keep your subscription active; your rate will stay the same as a thank you for joining when you did!

So what does this awesome subscription give you:

Access to a private gitlab repo where all support, development, issues and feature request will be handled.

Open source plugins (yes all the plugins are still open source)

Access to a private npm server (You can easily do npm i --save @proplugins/nativescript-somename ---- tns plugin add will be working shortly after the NativeScript team accepts a PR to fix a bug in their code. ).

Access to timely bug fixes and/or your ability to ask for features (not guaranteed to be implemented)

Access to a curated list of plugins, which we hope to grow over time with plugins that have been abandoned by their original authors. (We have several in mind already, and one already in the list.)

Access to easy to use search, quick links from the npm web server to issues and a direct demo downloads.

Access to a boat load of plugins from top authors, some of them never released before!

Plugins that are already tested and work in NativeScript 6

Many new plugins being added daily (we were in time crunch; trying to get close to NS6’s release date. So there are quite a few plugins that didn’t make the initial cut off date; that should show up shortly as we finish testing them all under NS 6)

Some Phase 2 plans, based on subscriptions:

NS-Angular and NS-Vue demos and instructions for those flavors for all plugins. We would like the plugins to be all inclusive.

Integration and demo testing in Preview/Playground

Integration with PNR, to search and filter only ProPlugins

Screenshots for all plugins

All Dependency licensing in plugins license file.

“So where do I go for this awesome deal?" I am glad you asked; You can join the cooperative at

We hope you are as enthusiastic about where we can take these plugins and the jump in quality that we can do with the entire community participating. We have an awesome road ahead of us, with all of your help.

Sincerely all of us at the ProPlugins Team

*1) According to the Comoco scale we have over a million dollars in development costs that we have already poured into these plugins over the last 4 years. If you had to recreate every plugin in the ProPlugins Co-op, you would be out a lot of money. If you do have that type of money, we do accept donations and/or sponsors!

*2) If you are a plugin author that would like more information on how this project works, and how we plan to do compensation; please see our website.

*3) Community numbers for involvement in the top 40 plugins is actually rather poor. The numbers show such low participation on those 40, that in most cases it is actually non-existent for the rest of the plugins. This is very typical in all communities, not just NativeScript.

I had a discussion the other day with one of my buddies at nStudio. I was lamenting the fact that our communities plugins really really suck. It doesn’t matter if you use my site PNR (https://Plugins.Nativescript.Rocks) or Progress’s MarketPlace. Trying to find an actual working plugin seems like a trial almost akin to having a tooth pulled.

What is this? Its a video version!

The Video to go with the blog post!

Quantity

Mountain of Plugins

Normally a larger quantity of things is better than a smaller quantity, like I want more money than less. But a smaller quantity is considerably better in many cases, how quickly your app starts up, or how quickly you can build your app. So which is it here? That is a hard one, normally more plugins means more features you can add to your app. But our community seems to have been struck with the "Lets create a useless fork" virus. The larger quantities of Plugins is not our friend at the moment.

Normally having 1167 plugins would be considered a good thing, however, because of how many weeds we have in that 1167 plugins -- this now presents the problem of finding an actual flower in all these weeds. Both sites have search engines, so at least you don’t have to look through all 1167 plugins to find a specific plugin. So lets try a couple examples:

Let's first look at the keyword Dialog.

If we use the Market place we see there are 13 plugins that have the word dialog in them. If we use my site, PNR, we get 8 matches. Whats the difference? Well let's look at each one…

First, the Marketplace has the extra results (found primarily from bad meta-data):

Loading Indicator (doesn’t have anything to do with a dialog)

Essent Loading Indicator (ditto, and a fork of the above)

Loading Indicator SSI (ditto, and another fork)

Loading Indicator New (ditto, and another fork).

Nstudio NativeScript Dialog (a fork of NS-Dialog)

By default PNR, black lists all forks. This is in an attempt to eliminate what I consider the largest source of weeds. In almost every case I have ran into with forks they are virtually worthless and just add more noise to the results. So, looking at the above list, we have 3 of 5 plugins found on Marketplace were forks that really didn’t add anything. The final fork, is a fork I made on a plugin abandoned by its author. My fork works, so it is actually a good result, that my own site, PNR, didn't show. (*1, *2)

So, on one hand Market place did give you an extra good result; but it also gave you several extra bad results, that you have to manually filter out. This is especially bad with something like notification – PNR has 20 plugins Market shows 31. Any guesses about those extra 11 plugins?

This is an interesting issue and one that both plugins sites have opposing directions on how to deal with. So according to the Marketplace they have 1167 plugins in their database. My database only shows you 1050 of the 1379 (*5) that I currently track, (Numbers are as of July 5th). So based on 1167 vs 1050; the primary difference is because I’ve eliminated that extra 10% of the plugins because they were all forks. I want you to really think about that number, 10% of all plugins in our community are either forks with no changes or forks with minor changes. And that doesn't even count those that are side-forked (*6). So now we have multiple forks that may or may not work; mostly abandoned, and in a lot of cases these are forks from the original plugin, which usually is one of the better plugins in the community and is actually maintained…

So we have a lot of weeds in our flower garden. Which can frequently make it hard to find that lone flower in the sea of weeds. Sometimes it will stand out...

Working Status (or Quality)

The second issue, and bigger issue is the actual Working Status/Quality of the actual plugins that you do find. If all 1167 plugins were working, the first issue would not be as big of an problem . Yes, it would be annoying to filter through the sheer volume of forks; but at least we would know they worked..

Lets again take our dialog query example from above… We are pretending that we are using NS 5.4, as in NS 6.0 pretty much all of these broke and now need some fixes...

- The first plugin in the list is done by Shiva (@ nStudio) and updated only a couple weeks ago; NativeScript-CFAlertDialog, I can guess that it will work out of the box. His docs have screen shots, and sample code. All in all looks like a high quality plugin.

- The second plugin in the list is NativeScript-color-dialog, I can also guess this will work out of the box as it was done by Brad (@ nStudio) and was also updated recently. So far two for two are probably in a good state…

- The third plugin is NativeScript-Dialog; it shows the last time it was modified was 2016; odds are, just based on that alone, is it is much more likely to be broken. The weird thing is that the Marketplace says it is NS 5 compatible. Since I maintain the actual working fork of this abandoned plugin, I can tell you with absolute certainty this version of the plugin does not work in iOS on any version of NS. So 2 out of 3 working is still not bad so far.

- Next plugin is NS-EasyDialog – Its a fork of NS-CFAlertDialog and an older side-fork at that (*3)… 2 out of 4. So we are now at 50% of the plugins are believed to be good…

To speed this up, I won’t document each of the plugins, just the final numbers. So by the time we finish looking at all 8 plugins on PNR; we are at probably 62% of them in good working order. If we use the Marketplace and look at all 13 plugins found: We have probably 53% in good working order . Considerably better averages than I had expected, when I started this blog. I have frequently seen less than 20% working for some plugins. We still had to look at each one of them, and then evaluate if it met our needs, so we're spend time going through 8 (or 13) plugins. Then once we have a list of those that meet our needs we need to actually download and try the demo, to actually verify it will work (assuming they have a demo). Which is where we would have typically figured out that only half of these actually worked…

In addition we might also need to search for “alert” and “toast”. It really is depending on what you are needing to show on the screen. Searching with “Alert | Dialog | Toast” (*4) the total number of plugins found is 15 plugins on PNR, and approximately 28 on Marketplace via 3 separate queries. So we might actually need to look at 28 different plugins to find (hopefully) the one working plugin we need.

Now, just looking at one simple keyword dialog, we quickly estimated the quality of working vs non-working is somewhere around 62%. But the truth is, I didn’t actually download any of these plugins or actually try the demos, I just “assumed” they worked because several indicators were present that made me be able to make a decently good judgment call on if they are still working. As a counterpoint – In one case last week, out of about 20 plugins I actually did a check on, not a single one actually still worked in the current version (5.4) of NativeScript. The reality is that out of 53%/62% actually is still high, once we attempt to download the demos and try them their is a very good likely hood that we will have excluded a couple more.

In addition, like the example above with the NS-Dialog plugin. You don’t actually know if it works on both iOS and Android still. You could download the demo, and the plugin might behave beautifully on one platform and still be totally broken on another… So running the demo on both platforms is pretty much necessary to verify everything is still working. Hopefully a demo exists and the demo actually tests the functionality you need.

So as the community gets bigger and older, the quality of the plugins is now becoming more and more hit or miss. Even some of my own plugins I forget to put things in the docs, or when I wrote them originally I didn’t even think a demo was needed. But community wide; this issue is a growing problem. There are many plugins that just have no documentation or literally anything except a name. In addition the metadata provided to NPM which PNR and Marketplace uses to filter and display them is also broken in a large number of plugins, which then makes searching and finding more hit and miss.

Oh, and if you are using a flavor of NativeScript (like NS-Vue, NS-React, or NS-Angular) the results are considerably worse for you. Frequently the plugins haven’t even been tested in any of the additional flavors. The only way to improve the quality is for someone to actually spend the time fixing the source, readme’s, metadata, demo’s, testing and documenting how to make them work in each of the flavors, etc...

The Top 40 Open Source Plugins

Let's switch gears a bit and look at some additional real numbers. So I took what are the top 40 plugins based on NPM downloads and then ran some numbers and gathered info on all of them. First, I excluded the NS-UI-* plugins by Progress. They aren't actually open source; and their repo numbers totally screw with the averages (in a very bad way). So it makes more sense to exclude them as Progress employees are paid to maintain them and the number of open issues is crazy high...

Most open source authors are unpaid; I even have a recent blog article about this outlining the costs of an actual plugin. Which, if you are unaware or you think that authors get paid for them; that article will give you some clarity of what is facing an open source developer and how much of their time and money they put into a plugin. If you haven't read it, please stop and do so now!

Secondly, the top 40 open source plugins get about 28,000 total downloads per week. These 40 plugins are written by only 12 authors. About 1/4 of the 28,000 (~ 7000 downloads a week) are from 9 of the plugins that I wrote. So, I can give you a pretty good idea about how much support I personally see on my repos for the percentage of usage that those plugins get.

in 4 years, on my 9 Plugins, I have had 6 excellent PRs out of the 44 accepted PRs from the total of 70 PR's that came from the community (The reason 26 weren't accepted is either they were duplicates, they didn't add anything, or changes were already in place, but not pushed to the repo yet). I personally will accept as many PR's as possible, no matter how poor quality they are, because I really want to encourage more. A large percentage of the 44 accepted were actually from several of these same top authors (or people at Progress). Where in that same 4 years, I did 340 commits for a total of 139 releases, all for free. As you can see the scale is pretty heavily unbalanced to the author doing the majority of the work.

Total PR's for 4 years in my 9 top plugins

Remember, these 9 plugins are part of the top 40 most used plugins. So how much real community involvement is when their is a whopping total of only 11 PRs a year for all 9 plugins. Yes, you read that right, basically the total of 1.2 PRs, per plugin, per year! Of that 11 PRs per year; 10 of the PR's are small trivial PR's, and 1 is a decent PR.

Total PR's for all 9 top plugins in 4 years

Now if we look community wide at the top 40 plugins in the same 4 years; they have had over 3700 issues; of which 783 are still open. This means that on average these 12 authors that own those 40 plugins, have to deal with 77 issues a year each. Frequently these issues will require testing to see if the author can duplicate the issue. If they can, then finding the issue and fixing it... It actually is a testament to how much these authors care about the community , that they still have close to an 80% closure rate.

This is not sustainable; almost 4000 issues in just the top 40 plugins, all handled by basically 12 people whom I would venture most (if not all) of them are not paid to do any of it. Now to put this in even more outrageous numbers; I myself actually have 25 open source plugins! Not just those top 9; that we have been discussing above. So the additional 16 plugins, which are not used as much, still also have issues, and fixes that have had to be done. The other 11 authors; also have additional plugins. In fact the top 5 authors in the community have almost 200 open source plugins that they wrote and support. If we get that poor of community support for even the top 40 plugins, how much support do you expect is expended on the rest of even less used plugins in the community?

To say the least; these numbers are very depressing at how few people are actually holding up the plugins in the community...

Breaking Changes

Now depending on how long you have been in the community; you may not realize that basically each major release of NativeScript has broken a part of the plugins. This means that NS 2 -> NS 3 required fixes (some not so trivial). NS 3 -> NS 4, NS 4 -> NS 5, and now NS 5 -> NS 6. Each of these releases had breaking changes; unfortunately this time is no different and there are a couple different breaking changes in the new NS 6 update. This is one of the major reasons the plugins in the community are in such disarray. Many plugin authors have come and gone over the years. Those plugins may have been top notch when they were released; but no one picked them up when that author left. So you still find many plugins from NS 1, 2 and 3, that sound awesome, but don't work because the original author left and no one from the community stepped in to maintain it. I have 25 plugins that I need to verify work in NS 6, trace down any issues and commit fixes to them, all for free. That is a lot of time and energy...

Community Involvement

I have discussed with Progress about money for the plugins issue; and they have told me in no uncertain terms that there is no money for plugins. The answer did not surprise me, as based on why NativeScript exists this is not an area that they believe will help its core purposes. So it is not an area they are willing to fund. I didn't want to assume it, and there was no harm done in asking.

So this obviously then becomes 100% the communities problem. We now have over a 1,000 plugins in the community and another large chunk of them broke with the new NS 6 upgrade. Unfortunately most will probably permanently join all the other plugins, in the plugin graveyard, that died in the prior NS 2, 3, 4 and 5 updates.

Possible Solutions

Money from Progress (Nope)

Money from another large sponsor (Who??? )

Verified Plugins Program ( Creates even more issues, -- uh, Nope. )

Community stepping up, by doing a lot more work to fix existing plugins via PRs ( That would be awesome, but seems unlikely. )

???? Please make some suggestions ????

*1 – PNR has been updated since I wrote this blog article to hide the original ns-dialog, and re-enable showing the working fork nstudio-ns-dialog. But initially it was opposite, and I’m willing to be totally fair and say my site had some bad results.

*2 – If you have created a fork of another project that you are maintaining because of major feature changes and/or the original author abandoned it – please let me know; I’ll white list it on PNR.

*3 – I have already black listed this fork now on PNR, as it is a unmaintained fork (which was not tagged as a fork because it was side-forked...

*4 - PNR actually support | and & in the main plugins search filter; However, it can ONLY use one at a time. The first one it finds, it uses for the rest of the search So if you doblah | blah2 &amp; blah3 it will treat it as blah | blah2 | blah3 -- sorry I was very lazy when I quickly wrote the parser, and it is undocumented "Feature". In future versions, I will probably beef this up to allow things like (x | b) &amp; (c | d) but at this point, it is really simple stupid and unsupported.

*5 - the extra almost 300 plugins that I track are plugins that were depreciated, or aren't actually NativeScript plugins. The original developer used a set of key words that made it show up in the tracking set that I track from NPMJS, so they had to be tagged as invalid to eliminate them from view.

*6 - Side forks, are where the person git clones the repo; but then creates a new repo with the code and it isn't "linked" to the original repo. i.e. it is a fork, but was forked "outside" of the a normal fork method. Unfortunately, I have not figured a good way to detect this, because it no longer has a link back to the original repo as a normal fork does.

It has some awesome features; but since it is a major bump this is when all the breaking changes come out to play. And we have some huge breaking changes in v6.0. The largest change is to remove the legacy build system.

Features

New Themes

Android Runtime:

AndroidX (breaking change)

Worker communication is using the original JSON method, which fixes data corruption issues with data being transferred from worker to main thread.

v8 - v7.5

Some more SBG Fixes

iOS Runtime

JavaScriptCore 12.3

Issues with Building application with newer versions of XCode resolved

Webpack

process is now no longer forced undefined.

No longer need all screens names ending with -page

All XML, CSS, SCSS, JS, TS is now included in app

Lots and Lots of bug fixes

CLI

Node < 10 is not recommended, and < 8 is unsupported

XCode < 10 is unsupported

TNS Migrate to update your app to 6.0 has been added

Lots of bug fixes and changes for full 6.0 support

Core Modules

textChange and checkedChange events now fire again in Core

Animation of Height/Width

New Tab / Bottom Nav components

Font Icon Support in Actionbar and Tabviews

Breaking Changes

Now for the fun part; as is the normal reason for a major bump in version is all the breaking changes; this version has a lot, I'll mention the top changes. If you are a plugin developer; some of these will have to be fixed before your plugin will work in 6.0.

Breaking Change: Removal of Legacy and standardize on Webpack

This is one of the largest changes in NativeScript 6. They released 5.4 which made webpack as the standard build, and made legacy the obsolete build system. This made 5.4, a release which had lots of issues. In fact a large chunk of the 5.4's I had to re-enable legacy mode because 5.4 was just too broken to actually work the new webpack only mode. I have another blog post on how to have a side-by-side to help deal with this issue; if you are one of the lucky ones that run into 6.0 issue that are because of webpack. As time progresses, and the issues are ironed out -- the webpack only build does offer a lot of benefits -- but during the transition; it could be a bit dicey...

Some Known Issues:

(Webpack) Each workers will drastically increase the size of your application (Fix already in master)

For those who have been hiding in the hills for a while; you may not have noticed that the cool news for NativeScript is that we have a new version that has been coming for a while. 6.0 was officially released today!

Well 6.0 has been release; and there are a lot of things to like in 6.0, but if 6.0 doesn't work for your app; you might still need to run 5.4 to get your work done. Unfortunately, the NativeScript team did not listen to my advice and release a 5.5 to continue testing the new webpack only builds, so we now have a 6.0 with still a lot of webpack issues and now no easy work around because legacy mode was removed in 6.0.

One of the techniques, I used while testing 6.0RC on plugins and apps and reporting the massive number of issues I ran into; is making my install side-by-side. So now I have a tns5 command which is my tns 5.4.2 install. And then tns is my 6.0 release.

The first step to run a side-by-side install is to do a npm i -g nativescript@5.4.2 to install 5.4.2 (the last 5.4 version) on your machine in the global node_modules. Now depending on the OS; this directory will be in a couple places:

The easiest way to find out where it is stored is to run the following command in your command or terminal shell: npm root -g

Under most linux installs this folder is here:- /usr/local/lib/node_modules

Under Mac OSX the folder can be in a couple places, depending on how you installed it.For example because I run nvm on my mac, my folder is located here:/Users/nathanael/.nvm/versions/node/v10.15.3/lib/node_modules

And on windows 10, it is located typically here:%USERPROFILE%\AppData\Roaming\npm\node_modules

But using the npm root -g will tell you exactly where it is on your machine.

So first navigate to this folder and find the "nativescript" folder; and then copy it in its entirety to the "nativescript5" folder. This gives you a fully working NS 5.4.2 version in a different folder that won't be overwritten when you do the npm i -g nativescript@latest which will give you the NS 6.x version.

The final piece of this puzzle is creating the tns5 command, on my mac the folder for where to put it is:~/.nvm/versions/node/v10.15.3/bin

So I created the tns5 symlink to point to ../lib/node_modules/nativescript5/bin/tns

On Linux we needed to create the symlink in /usr/local/bin; and so I created the tns5 symlink to ../lib/node_modules/nativescript5/bin/tns (the exact same relative path as mac)

Steps:

npm i -g nativescript@5.4.2

npm root -g

cd (folder listed from npm root -g command)

copy nativescript to nativescript5

npm i -g nativescript@latest

create a tns5 symlink

This should allow you to have a permanent install of v5.4.2 and then your normal update-able version .

Now most of you are not plugin developers; and as such do not understand what costs go into creating or maintaining an open source plugin. Normally I wouldn’t even think to post something like this; and I don't want this to be seen as "whoa is me". But a statement from someone at Progress; made me realize that many others are probably also be under the mistaken idea of all the costs of a plugin and so I now feel I should address this...

So here is the
summary of the statement made to me in a conversation:

“Plugins are either paid for mostly by companies, clients, or those that are free are still excellent advertising for your services. So releasing a plugin is a win/win situation.”

The funny thing is before I started doing NativeScript plugins; I am sure I thought the exact same thing. So, I can’t fault anyone for thinking this! It is very easy to think plugins and open source work is created by “mostly” companies, as it makes logical sense – all the press Microsoft, Google, Facebook and Amazon generate from their open source work. This can also be especially true, if you are doing open source work and being paid by a company for your work (like the NativeScript team, and the many teams at Google, Microsoft, etc that are producing open source work). So, I can honestly see how this is the prevalent view.

In
a nutshell there are three separate claims here we will discuss:

Plugins
are mostly paid for.

Plugins
that aren’t paid for; are good advertising

Releasing
them is a win/win situation.

Claim:
Plugins
are mostly paid for.
(TLDR: false)

First of all, being fairly in tune with the plugin community; to my knowledge the majority of all the plugins in the NativeScript community are actually done as a mix of paid and unpaid work and those that were paid, are very very rarely still supported by the company who initially funded or released it. So even if a company actually sponsored the plugin, there is no followup money to continue maintaining or enhancing it. Meaning the author is almost always again donating their time to make this plugin work and/or do maintenance on it!

Since I really don't like talking in hypotheticals; we will use my plugins as an example. 21 of my 25 open source plugins were done completely on my own dime. Meaning, no actual clients paid me for any of that work. That includes some of my most popular plugins like NativeScript-Permissions and NativeScript-Sqlite (*3).

A lot of people have assumed that the authors of these plugins are paid by a company to maintain them. I may list Master Technology or nStudio on my plugins documentation to try and advertise my services, since I do own/co-own those companies. But I do not see a dime of money from anybody (nor even from my own companies) directly for working on any of my own plugins. Pretty much all work on all my open source plugins is in on my own totally unpaid time. These were all done either to help one of my own personal projects, for the technical challenge, or to help the community. Occasionally, I might actually fix a bug or add a feature that can be directly attributed to a client needing to use the plugin, which then it might be paid for. But that is not as common as many might think. (Lets just say in the 4 years I've done this, I've only had a handful of requests.)

For a truly complete picture of at least my plugins; 4 of my 25 plugins (mainly smaller plugins), actually had some real paid parts to them. Yay! Again, not normally enough to actually pay for the entire open source development of the plugin. But enough to pay for some or several of the extra features in them to meet that clients specific needs. So yes, there can be some money in it. But in most cases, it is still not even enough to typically pay for just the time that went into creating that plugin in the first place, let alone any of the time to support it or maintain it.

In addition as one of the few developers that has actual commercial plugins, I can also speak on this side of the coin. Even the money made on my commercial plugins has not actually paid for the actual development costs of those commercial plugins. In fact there used to be another developer with a commercial plugin -- he recently left the NativeScript market. There just hasn’t been enough purchases. And finally, I do have a lot more private/unreleased plugins that were in a several of the cases mostly (or even in a some cases, fully) funded by clients. In this aspect; there could have been good money involved with some of these. (*1)

So based on my own personal experiences, and many discussions with others in the community; I would have to say there isn’t nearly as much money going around to deal with making them -- let alone any money for support, bug fixing and/or documentation. One of the most famous examples of this issue. The OpenSSL library; it underpins the entire secure parts of the internet. HTTPS is provided by OpenSSL; so browsers, servers, your phones all have OpenSSL libraries (*2) in them. The team that was maintaining this highly complex software, was only getting about $2,000 a YEAR in donations; despite many many many companies using it in their hardware and software that they sold for massive profits. This matches my experience; both my donation Paypal and my attempt at a Patreon accounts have seen so little money, that I don’t even think it is enough to even get a coffee even once a month.

This is called the long tail of support: the support side still needs to happen; but no funding occurs for all the additional work that will easily exceed the initial work on the plugin over the life of the plugin.

Some people believe that I get paid in Advertising. That makes some logical sense, and yes I do to some extent. Since I have several of the top plugins, I won't totally dismiss this as 100% false. Let us dissect this logically. I have a pretty good grasp of the reality of this -- with my 25 open source plugins in the eco-system, and being in it since day one. That seems like a potentially large amount of advertising, I could be getting. This statement actually was very true when NS was first started; each plugin released had a huge huge amount of ability to be seen. Unfortunately, their is now well over one thousand plugins. That means even with all my plugins together – I only have approximately 2.5% of the advertising market (+/- a tad depending on popularity) and that is shrinking daily. So even the advertising I can do with them; really is simply drowned out by the other 97.5% of the plugins. Having popular plugins, or long standing well known plugins does help increase that percentage; but just the sheer volume of plugins pretty much negates a plugins ability to do much advertising. Again, having a well supported and widely used plugin; helps increase this percentage a lot -- but anyone putting a plugin into the community now -- well your new plugin is just 1 in over a 1000...

With the amount of time it takes to actually create a plugin and then maintain it -- It is actually considerably cheaper for me to spend that time just doing additional contract programming; and then be a sponsor at a conference (which can be a tax write off for smaller companies) – so that my company is seen everywhere at it. A conference can now drum up considerably more business. That company is seen with only 5 or 10 other sponsors, and might even be seen on many of the videos; tweets, etc. All the way around good press, and typically gives the company the ability to talk one on one with many potential clients and hand out even more advertising and share contact information in person. Or write blog posts like this one, that are hopefully shared everywhere. (Hi, I do contract work :-D!!!) Or just be very helpful in the community so that people know why you are considered one of the top developers in the community and so you get contacted because of that. There are several ways in the NS community to stand out; and almost all of them are considerably cheaper than writing a plugin.

Unfortunately, their is one big GOTCHA people don't realize. If the plugin is broken, it actually turns into a significant liability and so it is negative advertising! Which now means that plugin now actually turns from help into a source of long term money and time drain; as I try to make sure my free “advertisement” isn’t now a liability… Nothing inspires a potential client, more than trying your "free" plugins and it crashing. Yes, that will totally inspire them to try your paid services.

Just for those who haven't been around since the beginning of NativeScript time; there have been over 5 different sets of breaking changes to plugins over just 4 years. Each time a breaking change occurred; some of the plugins had to be completely rewritten or heavily modified to make work again. Others, fortunately had much more minor changes or if you are really lucky; no changes. But any way you cut it; all the plugins you released had to be re-tested, debugged, and upgraded to the next version of the framework. So writing plugins, this isn't a write once, and it can just sit and work forever, like plugins in many of the other communities. This is why plugins from NS 1, NS 2, NS 3, NS 4 don't work in NS 5, and of course our newest breaking changes are occurring in the brand new NativeScript 6 release. So watch a lot of plugins break again...

Claim: Its Win/Win (TLDR: LOL, So very false…)

Well you can probably guess based on the first two claims at how this goes -- since those were both false. But I have probably the one of best story to show you how false this claim is. This is a 100% true story, and I am attempting to minimize it to the best of my ability because I am not trying to make the parties look bad. I think this situation really points out how terribly lopsided this "win/win" idea really is or can be. I can only speak to my story; but I have heard about another one in our community that is likewise just as "great".

So first lets take my awesome top rated NativeScript-Sqlite open source plugin, it was released for free, no strings attached, and developed by me for free, nobody paid me for any of the open source part of it(*3). According to the COMOCO scale; it is worth about $150,000 in development costs. So far, nothing wrong, this was my goal for it to be something useful in the community. And I am very happy it is a useful plugin for everyone to use. This is open source at its finest!

So
there is this small company called Kinvey, which Progress bought for
~49 million dollars a couple years ago. Kinvey is a HIPAA
compliant Database as a service; primarily focused on mobiles. They
charge very large sums of money to companies for every byte of
traffic / data stored. Product is well written, and very secure
-- so overall companies like paying the money for the piece of mind
it gives them. Still Nothing wrong here, either. Good product, and
excellent revenue stream for Progress. They support several
different mobile platforms, including NativeScript.

Does
anybody want to take a guess where I'm going with this? So
when they developed their plugin for the NativeScript platform, they
used one of those totally
awesome open source plugins. Any guesses to which one?
Ding. Ding. Ding. Yes, you
are correct – my
NativeScript-Sqlite. Again,
so
far, nothing really bad,
right...

Now I want you to really think about this. Progress pays their programmers to build NativeScript, they also pay their programmers to create and maintain the Kinvey services and plugin (so the Progress developers all get paid). Progress also paid 49 million for Kinvey, so definitely the creators of that technology got paid. Progress also now gets paid massive amounts of money for every single byte of data stored that the app uses which has this Kinvey plugin in it. (So hopefully they are making all that money back!). So far, let me be 100% clear – their is nothing is wrong with these people being paid, in fact theyall deserve to be paid for all their work. So now every single NativeScript app that uses Kinvey has my plugin in it for all the offline features...

Everybody is happy right?

Well, not so much. First, I have never even seen a single penny of revenue from Progress for this part of my awesome "win". Oh well, that is the breaks of a well designed open source plugin, right? It is being useful, its entire purpose in life. Woo Hoo, Yay! Ok, not so much -- I'll admit it is a bit annoying, they are making millions off of some of my work, and I don’t even see a single penny. And, I do realize it is only a small (but critical) part of the NativeScript side of the project, but it is more the principle that bothers me. This story is such a common story in our industry (think OpenSSL) – I am in very good company of people whose excellent hard work is totally unpaid for and/or underfunded; but the company using it makes crazy boat loads from it. So, I'll just let it be – and we can count this as a “oh well”, and life can go on...

Oh, I bet you thought I was done! Ahahahahahaha....

Let’s not stop yet, it gets even worse! So, I obviously didn't "win" on the first point (i.e. direct money). So, what in the world could be worse? Well what about that awesome advertising/recognition that is the second point we discussed above. Anyone want to take a guess? Lazy person, I bet you clicked the link. 🙂

Ok, I'll be nice and embed a picture here of the link...

Because my plugin is a declared NPM Dependency, I also don't even get any recognition either. Nor does anyone see ANY of my documentation, my name or any of my advertising for any of my services. So all these companies that pay Kinvey hundred's of thousands of dollars, who would be actually the perfect targets for me to do contract work for -- they don't even know I exist! Kinvey, has my plugin so integrated, nobody even knows it even uses my code. I am totally invisible, even though my plugin is the offline part of their NativeScript plugin. So, now we are at no money and no advertising/recognition, on something that is used to easily make millions for Kinvey.

Well, you know what; you won't believe it -- but the story continues to gets even WORSE! But we will actually stop here; my goal here isn't to make Progress and/or Kinvey look bad! My goal with this example is to actually show how much of an awesome "win/win" situation this really is for a real open source NativeScript plugin author... The plugin was 100% funded by me, is worth about $150,000 in development costs; and it is being used in apps, which was my purpose in releasing it. But I honestly can’t think of a case anyone can make where this can really be considered an actual “win/win” situation.

So in summary; these are three separate claims here:

Plugins are mostly paid for. (False)

Very few of my released plugins are even partially paid for, let alone fully paid for. And none of them have had funding for the long tail of support.

Plugins that aren’t paid for; are good advertising (False)

Advertising from the plugin is such a small percentage of the entire market; it is more cost effective to do other forms of advertising. In addition do to all the down sides of plugins long tail of support, it will very easily become a liability or negative advertising and/or a money/time sink.

Releasing them is mostly a win/win situation. (False)

Win/Win it is not (See story above). In addition to the long tail of support; in our community, we rarely see much support or PR’s for the actual issues. The costs for the long tail of support can greatly out weight any potential benefit from the first two items.

Notes

*1 – Unreleased because the long tail of support that I mentioned, it is crazy bad in all reality and as I don’t want any bad advertising. At this moment, I am unwilling to release more “free” plugins that just require more free maintenance work and support. I have a hard enough time keeping up with my existing plugins. At some point in the future; they might get released if I can figure out ways to mitigate the costs...

*2 – There are now a couple of forks of OpenSSL that are used in some products, so OpenSSL is not in everything now; it used to be. In addition, because of a nasty vulnerability in OpenSSL a couple years ago; several of the bigger internet companies figured out that they needed to do a better job and they stepped up and started funding the OpenSSL foundation. So this is to my knowledge funding is no longer an issue for the OpenSSL foundation.

*3 – There is one of the commercial add-ons for SQLite that has been partially funded by a client. But the open source side; was not funded by anyone but me.

All company names and trademarks are owned by their respective companies.

Isn’t that an interesting title – I wonder if you can guess how I plan on tying the two together! Can we all say Click Bait! Stay tuned, and we will show you how I combine both of these into one blog post...

Now many of you know
that NativeScript is 100% open source. I can take NativeScript and
build the entire stack locally on my computer and never deal with
Progress again, if I were to so choose. This is awesome from the
standpoint that I am not technically stuck (*1) if I need to fix some
issue. Many of the technology stacks in the past you could get to a
point, and then if the issue was lower in the stack you were totally
stuck. In my career I’ve run into this several times; and it
really sucks when you can’t fix the issue because it is a issue in
a lower part of the framework where you can’t get any access to it.
In this case; we have full control over everything if and when we
need it, so we are is a great position moving forward if using this
stack.

So, the question I
have seen around; and even had myself in the past was: Since
NativeScript doesn’t make any money, how can Progress possibly
continue to pay to keep it going? What is their business plan to
turn a profit, and when will it be cut off?

Seriously; common sense says; if a product doesn’t make money after a couple years; a company will discontinue it. How many projects has Google canned that is making money; but not making as much money as they wanted to continue it? So, if the product has no real way to make money long term; then why would they keep it?

Yes, it does have a
couple minor revenue streams, like paid support; but even the paid
support probably doesn’t actually fully even pay for just the
support techs that do all the awesome support for NativeScript. So
basically NativeScript does not make any money directly. On paper;
it looks like it is probably just burning money...

So why would
Progress spend so much money to continue enhancing, and maintaining
it, for a product that will never actually turn a profit??? Then
what are our risks as the community that they will pull the plug
tomorrow when they finally figure this out???

Well rest assured; I
don’t believe it will discontinued any time soon. First; I would
be totally shocked if most of NativeScript development costs are not
written off as a very nice tax liability (*2). Smart companies have
money pits in certain area for key reasons, one of the biggest is
taxes. The other interesting thing is it is not really just a
normal money pit used just for tax liability reasons.

NativeScript is the
Advertisement. NativeScript is not a product, in that sense
to Progress – it is a significant way to get you (the developer) to
use Progress services. So just like some large company might pay
millions of dollars in advertising; per year to try and reach you.
Progress is doing the same thing – but instead they are actually
targeting it specifically at developers. Virtually every dollar of
advertising is being spent on developers. Who is a large part of
their market target; well us developers! So it is an extremely well
targeted advertisement, much better than you can do with any adwords
scheme you can find!

Changing this point
of view, completely changes the entire narrative of why NativeScript
exists and its continued long term viability. It is no longer just
a money losing venture of Progress. It is an significant
advertisement to get you to use all the other Progress services.
This is a critical point to understand; as this underpins the whole
reason why NativeScript should continue to exist for the foreseeable
future.

Since NativeScript is very much like Fortnite (see told you I would work it in!). They hand out the awesome 100% free game. And which game company has been just raking in the money (like 2.4BILLION in 2018 alone) from a single free game? And if anyone follows Fortnite; you will know they are constantly improving it. However, they get you on all the “extra” attached revenue streams. Yes, you can play Fortnite 100% free and never spend a dime and even continue playing all the cool game modes that keep getting released.

You can also use
NativeScript, create awesome apps and never actually spend a dime
with Progress. Which is actually what the majority of the community
does; but all Progress needs is a very small percentage of the
NativeScript users to use its payed services and NativeScript ends up
causing a major profit for them.

As some examples; to
show how this works… Progress owns NativeScript, and say you want
someone to build you an app, who is your first stop? (Especially if
you are a large company!) You might see a nifty services page on
Progress’s site – you contact Progress. But they do not
actually do the contract work. They actually sub-contract it out to
others; and take a hefty cut for that privilege. This works well for
everyone involved. Or perhaps you are a independent developer;
Sidekick, cloud builds, attend the conferences? All revenue
streams. Larger companies; secure data storage, chatbot, ai, etc.
Progress offers many of these “addon” services; and all of
them have fully working integration's with NativeScript. So any
development by a enterprise class company has a large chance of
starting and choosing to stay with the owners of the NativeScript
stack and paying for that privilege.

In other words; Progress is brilliant – they have managed to figure out how to take the same model used for Fortnite and use it on developers. So hopefully this reassures everyone that NativeScript should have a long life ahead of it. (*3)

Well played,
Progress!

Notes:

*1 – I am not
stuck; in that I can fix my own copy of the code and deploy the app.
This does NOT mean that Progress will take your patches and fix the
master so that it is fixed in the next version(s). It just means you
can fix it in your copy…

*2 - Progress is a
multi-national company; so they have taxes in multiple countries –
different countries have different laws; but typically losses in one
business unit can be used to write off tax gains in other units. So
the “paper” loss of NativeScript offsets revenues from the other
parts of the company, and so it then lowers some of their tax burden
in probably several countries.

*3 - I am not a employee of Progress or Telerik; nor have I ever been, so this is all based on the know facts. However, this matches all the facts to a T. So, it is my strongest belief based on all public data available; that this is why NativeScript exists and will continue to exist. It also explains why Progress was willing to continue to sink million of dollars into NativeScript; and also purchased things like Kinvey for 49 million dollars.

Please note all companies names, Logos and products are owned by their respective owners and convey no endorsement of any content or other products in this post.

FAILURE: Build failed with an exception. What went wrong: Execution failed for task ':app:processDebugManifest'. Manifest merger failed : Attribute application@appComponentFactory value=(android.support.v4.app.CoreComponentFactory) from [com.android.support:support-compat:28.0.0] AndroidManifest.xml:22:18-91 is also present at [androidx.core:core:1.0.0] AndroidManifest.xml:22:18-86 value=(androidx.core.app.CoreComponentFactory). Suggestion: add 'tools:replace="android:appComponentFactory"' to element at AndroidManifest.xml:19:5-37:19 to override.

Try: Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output. Run with --scan to get full insights. Get more help at https://help.gradle.org BUILD FAILED in 30s

Wonderfully helpful error message huh? Well the issue is that Google recently changed their services to use AndroidX descended components. This change has been in the wings for a while and even NativeScript has been working towards this goal (NS 6.0 will be fully AndroidX). But in the meantime unfortunately Android.* and AndroidX.* are totally incompatible.

There are two things you might have to do to solve this so that you can continue to work...

You create (or modify if it exists) a file in your App/App_Resources/Android/before-plugin.gradle and add the following section:

This will pin your app to continue using a slightly older version of the Google services which is still based on the Android library. (IMPORTANT NOTE: when you later upgrade to NativeScript 6, you will want to delete this out; because NS 6 is Android X based; and so you will want the later versions).

2. If the above doesn't fully solve the issue; you may have to do a search in your node_modules and specifically the plugins for any plugin that actually uses google services in their gradle.include files; they might be hard coded to use a "+" as the version, and you will need to change them to be also "16.+"

--- UPDATE:

I had one of my friends, Dick Smith; showed me another solution via slack this morning; instead use the app.gradle file (also located in the same spot App/App_Resources/Android/app.gradle)

This will override it as Gradle looks for the pieces it needs; it runs this code and even thought the plugins gradle file might state it wants version X of something; it will change it to the version we want... (Please note the same warning applies; when you upgrade to NS 6.0 in a couple months, you will want to then either change these versions to the AndroidX versions or delete this section).

--- End Update.

Finally after you make both those changes; I highly recommend you do a "tns platform clean android" before you rebuild the app, so everything is clean..

Finally if all else fails and you aren't expecting to release your app for another couple months; you can actually upgrade to the test version of NS 6.x; this version is currently unstable and you might have other issues (and you will probably want to update to the latest 6's each day just to try and make sure you are on the most recent version...)