Tag Archives: Plugins

NativeScript Plugins and the costs...

A NativeScript Logo in Puzzle Form
NativeScript Plugins

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.

Claim: Plugins that aren’t paid for, are good advertising (TLDR: mostly false)

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 they all 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.

NativeScript AndroidX support and Plugins

The next major version of NativeScript (version 6) will be switching from the android.support packages to the new androidx namespace. This will be a hard break; as you can only use the support api's or androidx api's; but not both. This is something Google has been implementing for a while; and NativeScript is getting on board to eliminate later issues and give us great support. The awesome developers at Progress have already created a fork of NativeScript; which you can install to test which uses androidx instead of using the support libraries.

Since one of my plugins is affected by the changes; I took a look into what was required to support both the current versions of NativeScript and the new upcoming version of NativeScript.

For any of you who have plugins; this code is what I basically devised.

let androidSupport=null;
if (android.support && android.support.v4) {
  androidSupport = android.support.v4;
} else if (global.androidx && global.androidx.core) {
  androidSupport = global.androidx.core;
}

Then you can use androidSupport to access the namespace, and it pretty much works the same as what you would access using android.support.v4 or the new androidx.core replacement. Because we used feature detection; this allows us to support both namespaces in the same code base.

So if you have JavaScript or TypeScript code that uses android.support.* then you can use this technique to make your plugin forwards compatible with the next major version of NativeScript while retaining support for the prior versions.

Here is a list of classses that are being moved from android support to androidx: https://developer.android.com/jetpack/androidx/migrate

Plugins.nativescript.rocks upgraded

Behind the scenes PNR (http://plugins.nativescript.rocks) has been upgraded to support several cool new features.

At this moment the largest difference is the backend data storage system has been completely changed; and now has a lot of new data available to it.    This system should allow us to do some more pretty cool things in the future...

By using this new data; I also have a bit more accurate plugin list,    In addition the new system has the ability to track both NativeScript 2.x plugins and separately 3.x.  So on the page you can now see a select list that allows you to change "All" (All plugins), "2.x" plugins that should be only 2.x compatible; and then finally only 3.x compatible.  In addition I took the time to actually drop a physical search bar in the title area; as my virtual search bar seemed to confuse a lot of people.

Play around with it, let me know if you run into any issues.

NativeScript 3.0 Sneak Peek and what it entails for Plugin developers.

For those who are not aware, v3.0 of NativeScript is the next major version that will be released.  It has been being worked on for several months now as it has parts of it have been completely rewritten to enhance speed of the framework in a number of areas.    Some parts of it have undergone radical changes in design, and as such will require changes to plugins to make them compatible.

Unfortunately these changes are a breaking change and will mess up the plugins for a while...

Some pre-release information has trickled out and as such the plugin developers needs to be made aware of these changes, so we can start getting a jump on these changes...

The biggest issue is any plugins that deals with any properties, or stylers has been completely changed.   These plugins will HAVE to be changed to support 3.0.   This means your plugin will no longer be NS <= 2.5 compatible, these are BREAKING changes.

 

Plugin Sites and the Package.json

As an aside if your plugin doesn't have any breaking changes and can continue to work fine in all versions of NS; then I am asking you to add a new flag to your package.json file to flag that this plugin is 3.0 compatible but doesn't require 3.0.

Your package JSON NativeScript section should look like this:

"nativescript": {
   "platforms": {
      "android": "2.3.0",
      "ios": "2.3.0"
    },
    "plugin": {
       "nan": "false",
       "core3": "true",
       "pan": "true",
       "wrapper": "ios",
       "category": "visual"
    }
 },

The additional "plugin" structure is being introduced  to try and capture the data that has been missing from the plugin infrastructure.  At this moment each item is totally optional.   However, this will allow the plugin sites to categories and filter the plugins based on criteria's that are important to subsets of the users using the plugin sites.  Please see: http://fluentreports.com/blog/?p=489 for more details on the new "plugin" structure proposal.

 

Back to the breaking Changes

The first resource is that some of the NativeScript team produced a video last week https://youtu.be/bwO3cYPb4zQ which will give a decent overview of the changes.

The developers working on the 3.0 project gave a run down of the changes and how they benefit us and/or what changes we need to be concerned about.

The second resource, which I find to be a bit more valuable is this document that is in the source repo.  https://github.com/nativescript/nativescript/blob/master/Modules30Changes.md

They used this document in the above video; but since they only covered an overview and this documents has all the nitty-gritty details.

For this to be a smooth transition I really strongly encourage you on the "core3" attribute be used if you are not just bumping your platforms to 3.0.0.      I will be automatically filtering out plugins that I believe are only 2.0 for 2.0 mode and 3.0 for 3.0 mode.  So  having things tagged correctly will help the end users have a much more painless transition.

 

NativeScript: Plugins - Let Fix the Data!

Some of you might not be aware but I wrote the plugins.nativescript.rocks.   I also helped write the plugins.nativescript.org site (if something doesn't work on plugins.nativescript.org; please blame my cohorts in crime, Nathan Walker and George Edwards.   I had NOTHING to do with any bugs!  😛  )

Well, with the new upcoming changes in 3.0 and some data that we have been unable to determine I have decided to request that the plugin authors add a little bit more metadata to the package.json file that comes with the plugin.

So lets look at the existing "nativescript" key.

"nativescript": {
   "platforms": {
      "android": "2.3.0",
      "ios": "2.3.0"
    }
 },

This tells nativescript which version of NativeScript runttimes are supported.   This allows the TNS command line to throw and error/warning if you are not using the proper versions.   This is useful information as this tells us what platforms are supported.   However, this fails when people (like me) write dummy wrappers to support the plugin not crashing on the other platform.     On the plugins site it will say this plugin supports both Android and iOS, but in all reality the plugin only really supports iOS, and actually doesn't really do anything on Android.    I would like to have the plugins site actually reflect this reality rather than you downloading a plugin you thing works on Android and it turns out it doesn't.

In addition since Angular was introduced to the eco-system, there are a large number of plugins that actually do NOT work with NAN (NativeScript Angular) code.   And even some that don't work with PAN (Plain Awesome NativeScript) code.  In addition in the future we might get other frameworks supported like VueJS (VAN?), etc.

So I would like to start capturing the data so that we can do these additional cool things.   And so I am proposing the following additional OPTIONAL meta data to be added.

"nativescript": {
   "platforms": {
      "android": "2.3.0",
      "ios": "2.3.0"
    },
    "plugin": {
       "nan": "false",
       "pan": "true",
       "core3": "true",
       "wrapper": "ios",
       "category": "visual"
    }
 },

nan = NativeScript ANgular will be assumed to be false, unless Angular is detected in the Keywords/name/description.
pan = Plain Awesome NativeScript Will be assumed to be true.
core3 = Supports NS Core Modules 3. Will be assumed FALSE if platforms.ios/.android < 3
Will be assumed TRUE if platforms.ios/andorid >= 3.
wrapper = Using a dummy wrapper Will default to false, use "ios" or "android" to signify platform which is using a wrapper.
category This is the category to put the plugin in.   Valid categories currently are: "Interface", "Processing", "Templates", "Developer", "Utilities"

I am up for other category suggestions.   But at this point these are the primary categories that I use on plugins.nativescript.rocks.

Please note each key is optional; however, your plugin will get extra points for having an category key.  And you will LOSE points if we detect a plugin is using a wrapper and you haven't tagged it, as this is a issue the plugin users really hate seeing faulty data about the plugins support.

I would recommend plugin authors start adding this to any releases of there plugins so that we can capture the data.  This will become critical with the 3.0 release as a large chunk of plugins are not going to be compatible between NS 2 & NS 3.

NativeScript: Patreon Posts & Plugins

For those who are unaware; I've started doing paid content; see my post on "Why Patreon" to see the reasons.   I'm going to attempt to keep this post updated with plugins and posts that are available to those who are my patreon supporters.

Posts:

 

Plugins:

 

NativeScript: Android plugins and Windows path size issues

If your on Linux or OSX you can skip this post; it only applies to us pathetic people that prefer Windows (like me ). I do have Linux and OSX, so maybe I'm not that pathetic; but since I do prefer Windows, maybe I am.

If you don't want to read the reason this occurs but all you want is the fix; then scroll down to the fix!

Well if you see this error: Command [Some Path]\gradlew.bat failed with exit code 1 then you more than likely ran into this error if you see a lot of messages above it with "No Delegate Set" and errors.

Well to understand the issue you need to understand that this is a issue between Windows, Gradle and how NativeScript (A fix might show up by v1.8 of NativeScript) currently does Android plugins. Windows, if it supported larger path sizes; this wouldn't be an issue (which is why it works on Mac/Linux). NativeScript if it handled plugins differently might not run into this issue either. But at the current place we are at; it does so here is the crux of the issue.

1. Windows only supports 255 character path sizes (if they are not UNC or Unicode path's)

2. NativeScript scans all your plugins; any that have a platforms/android folder; it will use the include.gradle file found in that folder.  If there is NOT a include.gradle file; it will create one for you using the plugin name as the information.

3. Gradle combines all the productFlavors (which are inside the include.gradle files) into one long string.

Ok, lets look at a sample include.gradle file (this is also what is also generated for you, if it doesn't exist)

android {
    productFlavors {
        "nativescript-websockets" {
            dimension "nativescript-websockets"
        }
    }
}

So lets pretend your code exists at: C:\nativescript\AwesomeProject\, so there is (32) characters. Now add platforms\android\ (18). Next add build\intermediates\res\merged\ (31) as this is where Gradle does its resource merging. So lets say you are using the Telerik NativeScript UI plugin; and lets grab one of the image names \debug\drawable-xxhdpi\someimage.png which is of course adds another 49 characters. So this means we are using 130 characters already; leaving us with 122 characters left to play with.

So if you have a plugin installed like nativescript-websockets you get 23 characters used just for a single plugin. I bet you can see where this is going. Add on the cool nativescript-telerik-ui plugin and you have another 23 characters used. Add just a couple more plugins, and yes -- you are now well over 255 character limit!

Guess what happens???    Well if you are following the story so far; you get a nice error that gradle quit with error 1.

The Fix:

Now for the good news; here is how you can continue developing!

  1. Go to your app folder and do a tns platform remove android to safely recover, you need to kill your existing android platforms folder.
  2. Go into you node_modules folder, and then you need to repeat this next set of steps for EACH of the plugins you have installed.
    • Enter that plugins platforms\android folder and edit the include.gradle -- if that folder doesn't exist then you are done and can skip this plugin.  If the folder exists but the include.gradle file doesn't exist you can choose to ignore it or create your own.  DO NOT create a platforms\android folder, if it doesn't exist. Only create a include.gradle if the plugin already has a platforms\android folder and it doesn't have a include.gradle.
    • Edit the include.gradle and make the name shorter; this is the formula that I used.   Replace nativescript with "ns", eliminate any dashes, and then use the first letter for each word in the plugin.   So "nativescript-cardview" becomes "nscv",and "nativescript-telerik-ui" becomes "nstu". So the include.gradle changes from above (nativescript-websockets) to:
      android {
          productFlavors {
              "nsws" {
                  dimension "nsws"
              }
          }
      }

      Pretty simple huh?   By shorting the name, you go from 23 character per plugin to 4 characters per plugin.   So you can now easily fit 5 plugins in the same space it used to take for 1 plugin.  Please make sure the total letters are unique -- don't have two plugins with the same name (i.e. "nsws" for nativescript-websockets and nativescript-webserver)  as the same name, make them distinct.  Having duplicate names will probably break Gradle.
  3. Do a nativescript platform add android to re-install the platform after you are all done, and then you should be good to go.

Please note this potential side effect: I have confirmation below that if you are using a plugin that requires additional permissions; this work around will unfortunately not merge the info from the plugins AndroidManifest.xml file.   With all the plugins I had, I never saw this issue; but depending on what you are doing this is something you may run into.   You have two choices to deal with this:

  1. Don't rename that specific plugin inside the include.gradle file.  This way the AndroidManifest.xml file will get merged properly.   You an afford a couple plugins to still have large names.
  2. Copy the information that you need (like permissions) from the plugins AndroidManifest and manually merge it into your master manifest located at App/App_Resources/Android/AndroidManifest.xml

The bug report so you can track this is Android/369 and based on the conversation with the NativeScript devs this should hopefully be fixed in v1.8 (but no promises).