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

Iván Párraga December 20, 2012

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

7 answers

1 accepted

3 votes
Answer accepted
Eric S
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
December 20, 2012

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

Iván Párraga December 26, 2012

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

0 votes
Thorsten Preisegger July 17, 2018

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.

Deleted user January 8, 2019

Cannot agree more.

0 votes
Girish Jagdale June 25, 2017

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

0 votes
Gregory Sudderth
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
April 21, 2013

Said another way:

  1. The total dollars available to me as the admin are limited, and, in the current scheme, Atlassian will get almost all of it.
  2. We've stopped buying plugins, and now, are engineering some of them out with python scripts.
  3. We are segregating dev and biz users and will fire up another instance
0 votes
Gregory Sudderth
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
January 1, 2013

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.

G.

0 votes
Kinto Soft
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
December 26, 2012

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árraga December 26, 2012

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

0 votes
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
December 20, 2012

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árraga December 20, 2012

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

Suggest an answer

Log in or Sign up to answer