nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Why is not possible to to have different licenses for Jira and its plugins?

Iván Párraga2

Mi scenario is the following. Our Company purchased a 100 users license for Jira to control all the flow of the company (not software development but all the processes since a project is sold till it is closed). All the tasks on the Company for internal and external processes rely on Jira. It is our main tracking and reporting tool and we're very happy about it. In fact, as we're growing, it is very likely that we will buy the next license in the next months.

At the same time, we develop our own software. All the services that we offer are built upon our propietary software. In development we're very used to use a bug-tracker. In fact we've been using Trac for bug / stroy tracking for serveral years now.

Although the company size is about 100 people (and growing), the development team is about the 10%, and for the moment this percentage will remain stable.

We've yet not migrated our Trac projects to the Jira instance. My main problem, and my doubt, is the following. The development team may require plugins (GreenHopper, Bonfire, etc.) that will only be used by this team but there is no option to buy a 10 users license when the Jira instance has a 100 (or 500) one. As responsible of the Development department I cannot justify the budget for such big license when those plugins will be used just by 10 people.

So, this is my question, why is not possible to install a 10 users license for a given plugin on a Jira instance with different license? Is it a technical challenge? A business requirement? I'm quite sure that many companies have similar scenarios (in fact I've discussed about that with another Jira users).

What would be your suggestion for handle with this? What I think we're going to do is to setup another Jira instance just for Development but this is a pity as is introduces operative overhead and makes integration with other Jira projects os reports a little more challenging.

Thanks

Accepted answers

Eric S

Hi Ivan,

We appreciate your concern and issue with our licensing scheme. We have heard similar feedback in the past, and we have spent a lot of time considering how we license our products.

Firstly - the benefits. Tying JIRA and GreenHopper users together makes collaborative features such as sharing GreenHopper Boards much easier, as all JIRA users have access to GreenHopper without the need for further permissions configuration.

It is also a simpler licensing scheme to explain, as all our plugins, and the thousands of plugins in our marketplace all follow the same licensing scheme. It is easier for you as a customer to predict costs, as everything is based off the JIRA user count.

Most of our customers prefer the matching model, as they want all their users to benefit from the additional functionality that plugins provide. If we decoupled the users from JIRA, we would potentially increase the "per-user" price, which would adversely affect those customers that do want the tiers matching.

There have been many discussions around this topic, most notably on GHS-1623 and GHS-1374. As you can see on both of these feature requests, our product team has marked these as Won't Fix.

Thanks for taking the time to read through our explanation. I hope to welcome you as a GreenHopper customer.

Cheers,

Eric Snyder

sales@atlassian.com

All comments

Nic Brough -Adaptavist-

It's a technical challenge - there are (or were) a couple of plugins that support differing licenses. Obviously, they require Jira to have the same or more users, but they implement a "user must be in group and group must be of maximum size" rule. I don't know if they're still around though, or if anyone does them.

Some plugins are probably too complex for this to be worth it though - Greenhopper is so tightly integrated, it would be really hard to do it. Things that simply add a block of functionality would be a lot easier.

Iván Párraga2

Yeah, I was guessing that it would be a technical challenge related to the strong coupling between the different components. I suppose the way to go is that Jira provides an abstraction about that that could be used by the plugin developers...

It would be very interesting to know if this feature is on Jira's (or plugins) roadmap...

Eric S

Hi Ivan,

We appreciate your concern and issue with our licensing scheme. We have heard similar feedback in the past, and we have spent a lot of time considering how we license our products.

There have been many discussions around this topic, most notably on GHS-1623 and GHS-1374. As you can see on both of these feature requests, our product team has marked these as Won't Fix.

Thanks for taking the time to read through our explanation. I hope to welcome you as a GreenHopper customer.

Cheers,

Eric Snyder

sales@atlassian.com

Iván Párraga2

Eric,

I appreciate your answer. I understand your reasons but I cannot completely agree :-)

It's not obvious that a given plugin (as for example GreenHopper, but not only) can benefit all the users. In our case it's clear this way; the development team (the one to use GreenHopper) is just 10% of users, but I can think of other plugins as, for example, BonFire where this is more obvious.

I don't exactly understand why some users may prefer the matching model but I guess, as you say, that you've studied this in detail.

Cheers,

Iván

Kinto Soft

The problem is that you use ONE JIRA for TWO things (business processes and development). An alternative is deploying two instances: one for business (which it will grow) and another one smaller for development. That would solve the licensing problem. But... are the business processes tied to the development processes in some way?

Iván Párraga2

Yes, that's the point. In fact, this is the solution that we will adopt: two instances for two different things. But, as you say, it's a pity as there is some coupling:

some users belong to the two environments,
some business incidents are scaled to development teams and evolve to bugs,
some time tracking reporting should be integrated.

But well, as I'm not going to be able to get budget for the 100 / 500 license I will have to workarround these problems via import / export of information.

Cheers

Iván

Gregory Suddert

My userbase is multi-tiered and the "one world" licensing scheme is hampering us many ways:

- Not all users should even SEE greenhopper

- Not all users need Tempo (but I can control that, just have to pay for users I can't use)

- One-license-pool-fits-all has put a wet towel on adoption of JIRA for some sub-groups of users that have never even tried it

The overall effect is a combination of some users looking at alternatives and also firing up a flock of small JIRA's and avoiding this "one giant JIRA with lots of plugins to rule them all" effect.

Gregory Suddert

Said another way:

The total dollars available to me as the admin are limited, and, in the current scheme, Atlassian will get almost all of it.
We've stopped buying plugins, and now, are engineering some of them out with python scripts.
We are segregating dev and biz users and will fire up another instance

Girish Jagdale

Same issue with my client. I'll look for a developing own plug-in for them if possible :-)

Thorsten Preisegger

Atlassian's licensing scheme is simple. It means you have to pay more than you need for your plugins unless you complicate things by creating several instances of Jira.

I am currently evaluating Jira. The licensing scheme is the only argument why I am hesitating to enter the Jira world.

Dear Atlassian: Please seriously reconsider your licensing scheme. I am sure you would have more and happier customers if you changed it.

Thank you.

unknown

Cannot agree more.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-software

capture-for-jira

app

licence