Why are plugins priced based on total Jira users, instead of actual plugin users

[Fabregas4]

Nearly every paid Jira Cloud addon I look at adds 1k/year minimum, even if only 1 person wants it, because you're priced based on the total number of Jira users.

Take for example a QA/Test Management plugin. If you have 1 developer, 1 tester and 1 manager using it, but you're a 50-person company, all 50 users need a license for that plugin. You have to pay for 47 people who have never heard of, and will never use, this plugin.

I don't understand why plugins aren't simply priced for the specific number of users that will actually use them. When I asked a plugin developer, he said the pricing structure is set by Atlassian. Is Atlassian trying to discourage 3rd party plugin use by making them too expensive to consider?

[David Benson _draw_io_]

Generally, vendors try to work out what % of users out of all users, on average, use the app and then price according to that. A SaaS app online often starts around $10/user/month, whereas many Atlassian apps start at $2/user/month and lower.

A $2 app is saying we think about 20% of users will use it. A $0.5/user/month app is saying 5% usage, etc. (All very roughly).

It is a common request, but overall the license simplification it provides (IMHO) outweighs the cons (but sorry that you fall into a group that is disadvantaged).

You may still find services that charge you centrally as a SaaS service and then provide a free integration into Atlassian tools.

[Dave Rosenlund _Trundl_]

What he ( @David Benson _draw_io_ ), said, @Fabregas4  :)

The reason that it is this way is that Jira apps must conform to the Atlassian licensing scheme(s) to be sold on the Atlassian Marketplace. And, as David said, for the Jira admins. in this world, it would be a nightmare to manage which Jira users get to use which Jira apps. under the alternative scheme.

So, we (the app vendors) price our products accordingly. We know that not all Jira users will use our apps -- and we do our best to factor that into our pricing. That's the downside of this scheme for us: It creates the false impression that we are expecting you to pay for more users than you need.  

I agree with David. Even as an app vendor, I think the benefits of the simplification outweighs the confusion it creates. 

-dave [ALM Works]

[bo sanchez]

is there a minimum that can be charged? e.g. can you charge $0.5, $0.05 or any amount you like?

[Dave Rosenlund _Trundl_]

Hi, @bo sanchez. Welcome to the Atlassian Community 👋

No. There is no minimum. In fact, you can find significant number of free apps on he Atlassian Marketplace.

See: https://marketplace.atlassian.com/search?moreFilters=free

And, yes, the application developers who build add-on apps for Atlassian products can charge any price they'd like. However, market pressures and buying behaviors place a practical upper limit on what can be charged for a given app.

Hope this answers your question,

-dave

[Nic Brough -Adaptavist-]

It's across the scale too - we've got a an admin and migration helper app that throws out a few reports that can save you a lot of time when housekeeping or thinking of migrating a server system to somewhere.  It's $10 for 25 users.  It's $10 for 10,000 users.  It's totally aimed at your admin team, only they can run it (and you have fewer than 10, right?).

[Nic Brough -Adaptavist-]

The simple answer is "because that's the model Atlassian have chosen".

The main reason they've done this is simplicity.  Many years ago, we could actually have apps (then "plugins") which you could licence for sub-sets of your users. 

This immediately made your job as an admin more complicated because you had to match up who might use something against where it might be used and how and then somehow maintain that.

Next, the plugin framework couldn't do this by project or user or anything else for all types of plugin. 

• Sure you could say things like "only people in group X can add gadget Y to a dashboard", but then what do you do with someone viewing it?  Should they need a licence? 
• Or a report, which you might control by project.  Do you really want admins to have to deal with regular reports of "my reports stopped working after I added a new person to the project"?
• And then there's the ones that added workflow functions - should a workflow stop working (or even behave differently) because you've used a plugin workflow function that isn't valid in the project you've just associated it with because the wrong people are members of the project?  Or you've added someone who doesn't have a licence?
• And... and... and...

On the technical side:

• You can probably see how complicated all of those might be to code for.  Atlassian kept it simple and simply didn't bother investing huge amounts of time in providing a framework that could cope with all cases.  They went with "if your plugin wants to do this, you'll have to code for it yourself".  You can probably imagine that most plugin authors went "nope".
• Then there's a deeper one - permissions in Atlassian applications are a bottleneck.  Checking them at project level is already pretty slow.  Having plugins query them further constantly is going to make it even slower, and quite simply put, it does not scale.

I'm not going to ramble about the pricing considerations that vendors make myself.  @Dave Rosenlund _Trundl_  and @David Benson _draw_io_  have covered 99% of what I would like to say on the subject far more clearly than I could.

The last 1% I'd add is that a lot of app writers see the costs of writing and maintaining code to handle that sort of thing as high.   Think of it this way - you would be adding costs to allow people to reduce your income.  It's a "return on investment" that can work, reducing your income to make something a bit more widely used, but finding out where it might work in the Atlassian ecosystem is probably a mathematician's Master's thesis.

[Mark Albis]

Our organization is essentially blocked from using any Jira add-on because we have both Jira Software and Jira Service Desk projects in our instance. Our instance of Jira is integrated with SSO, and Jira currently has no support for SSO log-in for customers. Meaning, we have hundreds of "users" who are really just customers and literally only are users so they can log into our customer portal.

This means more than 99% of our "users" will never, ever use any Jira add-on, but we must pay for them anyway.

SSO login for customers has been on the Jira roadmap for a LONG time, we really need this update so we can reduce our user pool to only those who truly need to be users and can actually afford to use Jira add-ons:
https://jira.atlassian.com/browse/JSDCLOUD-630

[Nic Brough -Adaptavist-]

I'm afraid you are never going to get this, for the reasons I gave 2 years ago.  (The "only licence a few users for this app" thing, not the SSO you've linked to - I can see that being added eventually)

It is worth pointing out that JSM customers are free and do not count towards the number of licences you need for apps.  So if you've got 3 Agents, 100 business users, 250 developers, and 200,000 customers, your apps will need to be licenced at only 250 (the largest of the three Jira applications you have)

[Mark Albis]

The one thing I'm having trouble figuring out is: if a user has "site access," but has NO access to ANY Atlassian product, do they still count against the user head count for add ons?

This is how we currently have our customers configured so they can log into our customer portal.

[Nic Brough -Adaptavist-]

Yes, the access levels take a bit of getting used to.

Site access means the account can log into the overall site.  Not necessarily any of the products, just the site as a whole.  There's no charge for site access, it's all done at the product level. 

We've got an organisation that is in the middle of a migration, and they're currently running with 5,000-ish users with site access, and $20 of core product licences (4 Jira users and 5 for their Confluence, obviously paying a bit more for their apps, but all at the 10 user tier).

[Mark Albis]

I might be being thick but just to be clear: I know we're not paying for the users with no product access as part of our Atlassian subscription, but would those users be included with the count for the charges associated with a paid plug-in?

[Nic Brough -Adaptavist-]

The paid plugins charging will match the numbers of users (those with product access to) for the largest of the three applications you might have.

You can have millions of people with no product access (customers), and only 25 developers (software product users) - the cost of that is simply for 25 software users, and plugins will need to be licenced for 25 people.