What are the general criteria one should consider besides functional requirements while selecting a jira plugin

[Dieter]

Our experiences

• Make sure the plugin is supported across new JIRA versions. Either you have development capacity to lift an open source plugin to new JIRA versions or you plan you budget to buy and maintain a commercial plugin
• Make sure the vendor is not just a one man shop
• Check the impact on your system performance and stability. This usually depends on how deeply a plugin integrates in the system. E.g. plugins injecting Javascript on all pages sometimes cause regressions on standard functionality (observed in JEditor). Check page loading performance with plugin enabled/disabled and see if a lot more requests are sent to JIRA when the plugin is enabled.
• Please note that each new plugin requires some support overhead from JIRA administrators. It is NOT just the plugin price and yearly maintenance fee but also the ongoing support to configure the plugin for your customers, to answer questions from customers regarding the plugin and to trouble shoot in case of problems. There is no rule but the longer the feature list is the more support from your side will be required.
• Sometimes it is tempting to just install a plugin on demand of a single customer. Think well before you do that since you might end up in a plugin hell. Let users vote on plugins or start surveys. In general try to add plugins only if it is a benefit for the majority of your users. Favor one generic plugin  towards several specially crafted plugins. (e.g. For reporting purposes)

[Nic Brough -Adaptavist-]

On the second point - one of the best addons for JIRA has always been Jamie Echlin's "Script Runner". That was effectively a one-man shop for many years, and was never a cause for concern because of his dedication to maintaining it. There are other addons which see that level of support from a small vendor, so I wouldn't rule it out *just* because it's a one-man shop. It *does* mean you should think carefully before taking on a small vendor (One thing to do is get the agreement that if they do stop support, you get the source code) (Although Jamie joined Adaptavist a few months ago, so the rule no longer applies)

[Dieter]

My second point was more addressed to commercial plugins. Yet it calmed our managers now that script runner is now in the hand of a reputated company (with a genius behind ;-) We wouldn't even mind to pay for the plugin or parts of it like the JQL functions so i have enabled them now.

[Nic Brough -Adaptavist-]

Absolutely, I'd always look at the size of a vendor as part of the evaluation process. I still owe Jamie a lot of beer for the script-runner. I'm hoping to be able to spend more time with him when the current project finishes, so far, it's been the Christmas party and one afternoon when I popped into the office.

[Dieter]

Me too ... really don't know how i could manage our environment without the tons of groovy scripts. Maybe there's an opportunity to meet at the summit in San Francisco

[Nic Brough -Adaptavist-]

Robustness and stability, support, internal and by vendor, interaction, and of course, the cost.

The first two of those are quite hard to determine, especially for addons that don't have a wide usage.  Check the reviews in the plugin marketplace page, check the vendors documentation (especially the issue trackers) and look here in Answers for questions that mention the addon.  Do you get the feeling that they are well liked and don't cause people problems?

Internal support is easier - are you happy to install it and look after it when users have questions, and when you upgrade?  In the future, the functions might end up being implemented by Atlassian, or become redundant, so are you also happy to take on migration if the plugin becomes obsolete?

Vendor support is also an easy principle - are you confident in the vendor's support for the addon?  This biases the decision a little in favour of the well-established addons that Atlassian like, and the ones produced by Atlassian partners who have demonstrated longevity and on-going support.  (The only time I remember there being a big issue with vendor support was when the author of an addon fell out with Atlassian, pulled the (free) addon and made 3/4 of the user-base howl with anger because it was the most useful one ever written, and one of the three I instinctively install in every JIRA I get my paws on.  Resolved by him handing it over to a company who were happy to keep it going).  Pretty much all of the "big name" addons fall into this category now though, so I'd only be worrying about risks on the small vendors who haven't been around for long.  The main question for you is "how well is it supported by the vendor and can I rely on them in the future?"

By "interaction", I mean will the addon play nicely with the other addons in the system?  Does it overlap with other functions?

Cost is not as  simple as just the £ price.  You need to think about

• Does it really add a huge amount of value to your processes - will the users get direct benefits from it that will remediate the cost?
• All the points above - are the risks and support costs worth it?  (Just because it's free doesn't mean it won't incur your organisation costs)
• Would it be cheaper, easier, or more flexible for you to write it yourself?  I've been to places that install huge expensive plugins and only end up using 1/20th of the functions.  I've also been to places that get in expensive plugins and realise they aren't a good fit for what they do, and only a fraction of the users end up using them (in several cases, there's one plugin the management love to install and the users simply don't use because it becomes too complex)  Could you replace the function you want from a plugin with a bit of coding?
  
  

[MattS]

"one of the three I instinctively install in every JIRA I get my paws on" My essential add-ons are JIRA Toolkit JIRA Suite Utilities JIRA Misc Workflow Extensions and Script Runner Does that match your list Nic?

[Nic Brough -Adaptavist-]

Close. First, always * Toolkit * Suite Utilities * Calendar Then I look at * Charting * Script Runner I caveat the Script Runner though - because it effectively opens up the internals of JIRA, your admins need to be at least aware that they could make a mess and hence be careful (and I've done a lot of cleaning up of data damaged by well-intentioned but broken scripts) Misc Workflow Extensions is not on my list because it's paid, and I usually find the Script Runner lets us do the functions it has already. But it's ideal for the risk-averse users who don't want Script Runner, and I always mention it as an alternative to doing stuff with Script Runner (just to save the development time)

[MattS]

Oh yeah, Calendar and Charting. I always forget they're not part of JIRA, probably because they so obviously ought to be!

[Nic Brough -Adaptavist-]

The charting only adds a handful more, but they're often useful. I'm not sure why they haven't just been absorbed. I don't think I've ever found a site where the Calendar isn't useful to anyone!