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.
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.
Thanks for taking the time to read through our explanation. I hope to welcome you as a GreenHopper customer.
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.
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:
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.
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.
Said another way:
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.
This approach requires you to have the JIRA administrative rights. The main aim of this article is to help you achieve an organized, easy-to-maintain workflows in your JIRA instance thereby, reducin...
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!
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