Great plugin but worst licensing model ever

The NGFB licensing model certainly isn’t the best – yet. ?? I am planning on making changes. For example, at the moment, a license purchase provides unlimited support and updates. At some point, I have to switch over to a yearly subscription model. Also, licenses are nontransferable. I’m looking at options to allow transferring the license from one site to another.

My background is in large financial, airline, and telecom environments, where there would be a dev, qa, staging, and prod structure in place. The current license model offers a free dev license for every license purchased. If you have a domain.com production site, for example, you get a free dev.domain.com license as well. It’s expected that dev.domain.com is a public facing site available from the internet, which needs it’s own license.

If you’re developing locally, then you manage your own hostnames and IPs for your local sites (ie. 127.0.0.1), so using whatever hostnames you want (and therefore whatever license you want) is not a problem. You can keep re-using the same hostname, or even use the production hostname / domain – it doesn’t matter much. The licensing system for NGFB only cares about the WordPress Site Address (URL) you’re using – the IP is irrelevant.

NGFB is licensed per WordPress site — the more sites you install it on, the more licenses you need. If you’re using the Pro version on 30 sites, for example, it makes sense that you would need to purchase 30 (or more) licenses. I think the issue that you may be raising is that some developers use WordPress Site Addresses as a disposable value, where-as for licensing purposes, NGFB considers each registered WordPress Site Address as a licensed site.

Aside from implementing yearly subscriptions for updates and support, I could also expire registered WordPress Site Address values after 30-90 days, which would make licenses transferable after NGFB had been removed from a site for 30-90 days (or the site had been shutdown for 30-90 days, etc.).

I think you mentioned pushing data from dev to prod, including any authentication errors. I have to admit, pushing content from dev to prod is not something I’ve seen often (usually it’s the other way around, in order to use prod data for development and testing purposes). If you push a dev database to prod, including all settings etc., then you should probably expect the same behavior in prod as you were seeing in dev (including any authentication errors). If you then update the WordPress Site Address to one that is properly licensed, you can click the “Check for Pro Updates” button to have NGFB authenticate and clear any licensing errors from dev.

js.

I was talking about pulling data from prod to dev – sorry, I thought that was clear when writing “importing production data” (importing into development) … the other way around would be madness on a running site ??

The problem is exactly the Site Address Binding. When a developer pulls production data into his development environment and forgets to disable NGFB, sometimes the Binding gets updated and suddenly the development environment is bound to the license, enforced by your central license server. Professional site development with NGFB can be very annoying this way (talking about n developers, local environments, regular production-to-development db-imports, and so on). With plugins like WPML, Gravity Forms and such its easy going and uncomplicated (because they have a wildcard developer license fee).

The next problem are plugin updates. With the current license model you are _enforced_ to most of the time do NGFB plugin updates in the production environment. Because enabling and updating NGFB in dev-env will most likely result in incorrect Site Adress binding. Now think of Git, dockerised environments, continuous deployment, and so on … you DON’T do anything in production with the code/plugins in a modern development environment with a modern continuous delivery pipeline running! NGFB licensing just breaks that!

Forcing a customer/company/professional service firm to use dev.mydomain.com as address for a staging system (or even a local one) is less than suboptimal.

Since about 1-2 years now we have been pushing all customers wo want a great social media integration into their wordpress sites to buy a NFGB Pro license – but you can be sure, if the “developer experience” (aka the licensing model right now) won’t get better, we’ll switch as soon as a serious alternative comes around (and there are some promising candidates). Please have a look at Gravity Forms or WPML and learn from them!

Thanks for all the feedback — reviewing the licensing model has been on my ToDo list, so your timing is excellent. ??

I don’t see a problem with updating the plugin on one environment and pushing it to another. The NGFB Pro Update Manager checks for updates and uses the local Site Address for authentication / registration. It either passes or fails depending on the number of licenses available (it may already be registered, or can be registered, or fails because not enough licenses are available). If authentication passes on your dev / staging / qa server, you can update the plugin. If you push the new plugin to prod, and prod is also able to authenticate, then it’s all good.

The free dev.mydomain.com license can be used or not — as a general rule, all WP Site Addresses require a license. I don’t think this is unreasonable since every site using the Pro version may require support, and the cost of licensing covers that support (along with updates). License bundles, like 100 licenses for example, offer a significant discount since it’s assumed that there won’t be 100 users to support, but only a handful.

I’m thinking of doing away with the free dev.mydomain.com license, and instead offer free dev licenses for any WP Site Address URL which does not resolve to an IP. This would in effect offer free licenses to anyone developing on a local environment which is not reachable from the internet. Any public WP Site Address would still need to be licensed. This assumes that developers working locally don’t need support (since support requires access to the front-end).

js.