Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

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

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?


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.

Like # people like this

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]

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 _ALM Works_  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.

Like # people like this


Log in or Sign up to comment

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you