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

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

6 answers

1 accepted

3 votes
Eric Snyder Atlassian Team Dec 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

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

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.

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

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?

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

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.

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

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

Suggest an answer

Log in or Join to answer
Community showcase
Sarah Schuster
Posted Jan 29, 2018 in Jira

What are common themes you've seen across successful & failed Jira Software implementations?

Hey everyone! My name is Sarah Schuster, and I'm a Customer Success Manager in Atlassian specializing in Jira Software Cloud. Over the next few weeks I will be posting discussion topics (8 total) to ...

2,888 views 12 18
Join discussion

Atlassian User Groups

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

Find a group

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

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you
Atlassian Team Tour

Join us on the Team Tour

We're bringing product updates and pro tips on teamwork to ten cities around the world.

Save your spot