Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
Community Members
Community Events
Community Groups

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]

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

Like Dave Rosenlund _Tempo_ likes this

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.


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,


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?).

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 _Tempo_  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