NativeScript - State of the Plugins

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!

Quantity

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 5^th). 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.

 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.

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

1. Money from Progress (Nope)
2. Money from another large sponsor (Who??? )
3. Verified Plugins Program ( Creates even more issues, -- uh, Nope. )
4. Community stepping up, by doing a lot more work to fix existing plugins via PRs ( That would be awesome, but seems unlikely. )
5. ???? 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 & 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) & (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.