Blog Version Of Podcast
Software licensing. This has always been an interesting topic. Some are simple, and some are overly complicated. How does JIRA, and the Atlassian landscape check out?
The Dark Side Of Licensing
I’ve supported applications in the past in which the licensing was overly complicated and, I believe, designed to nickel and dime the customer. Whenever there was a need to review the licensing and or consolidate the licenses, several people had to be involved to figure out what was what.
You had seat licenses, concurrent licenses, named licenses, state licenses, local licenses, US licenses, global licenses, or international licenses. The ONLY difference was licenses dedicated to a specific user (seat, named) and concurrent licenses (released at timeout or exit of application by user). The others were designed with made-up scenarios of users existing within the United States. Or users existing internationally. Each cost more than the other. The kicker, for most systems, is that you took all these license keys and threw them into a single license server where they are pooled together. Therefore, you would have no idea what license type was really being used.
Buying these software licenses often means that a procurement or other software purchasing, finance, team would work with the sales team for the product you were buying and haggle through contracts, upgrades, splits, you name it. Not a fun process at all. This process could take weeks as both go back and forth until they could come to an agreement on price.
The Light Side Of Licensing
Along came Atlassian. Bootstrapped for resources, they used the “shopping cart” method by allowing you to choose your license bundle type (10 users, 100 users, etc.) and then buying online with a credit card. No back and forth with contracts or haggling down the price. You paid the price that they set. For established companies, this is definitely a change from what they are used to. Even to this day, I explain that there are no sales people to butter-up for a lower price. The price is already low!
For Atlassian products, they sell licenses based off their user tiers. Below is an example of the JIRA Software for server user tier pricing. For the server installation, this is a one time price that is paid and includes 1 year of support. Through Atlassian’s Marketplace, up to 3 years can be purchased. Maintenance is typically half the cost of your purchased license tier.
What About Plugins?
Good question. If you are looking to purchase plugins for your JIRA instance, such as Portfolio or Tempo timesheets, your plugin license tier MUST match your base JIRA license tier. This means that if you have a 2,000 user license for JIRA Software, your license tier for a JIRA plugin MUST be a 2,000 user tier. Plugins must match the base license tier. If you use other Atlassian products such as Bitbucket server OR Confluence, their license tiers DO NOT need to match your JIRA license tier.
What About JIRA Applications?
In E6, I talked about JIRA Core and JIRA Software. In it, I discussed how JIRA is now a platform with applications built on-top. Those applications being JIRA Core, JIRA Software and JIRA ServiceDesk. Their licensing is handled differently in that it appears that you can have mixed licensing models per your need. You can have 2,000 JIRA Core license bundle and also have a 500 JIRA Software license bundle. This is because the license to these applications is managed via JIRA groups.
The Annoying Side Of Licensing With A Glimmer Of Hope
While Atlassian has eliminated the hassle of haggling and other annoyances with purchasing software licenses, there is one that remains for them OR rather made apparent. This is the fact that the plugin license tier MUST match the base software license tier.
Let’s use the JIRA Portfolio plugin as an example. If you have a 2,000 JIRA Software user license tier, that means you must buy the same tier for JIRA Portfolio plugin even if you will have less than 50 people using the Portfolio plugin.
This licensing model creates two issues:
- Inflexibility in Marketplace licensing
- Inability to maintain access to certain plugins and functionality.
If the Portfolio plugin doesn’t seem like a good fit, how about a plugin that simply adds post functions to workflows. How do you apply a license tier to something an end-user will never see nor interact with?
Can Vendors Sell Their Own License?
Why, yes! Yes, they can. One such vendor, that I’ve had experience with, is Balsamiq for Confluence. They provide their license via the Atlassian Marketplace and via their own website. The key difference is that if you purchase the licenses managed by the vendor themselves, you can buy a lower license tier that is closer to the actual count of users. Access for this plugin is then provided by a specific group in Confluence called “balsamiq-users”. This means that if you are not in the access group for Balsamiq, then you will never see the options to use the mockup editor.
Atlassian has made licensing their software easier, but there are still some hurdles from a consumer standpoint. With the explanation of how licensing works with JIRA Core and JIRA Software, the next question that I have received was “Do plugins work the same way now?”
There does seem to be flexibility to have plugin licenses reside in a different tier if the vendor is the seller of the license. Though, as we see, if the license is purchased from the Atlassian Marketplace, that flexibility is lost due to how license management is handled via the tool.
With the advent of JIRA Core and JIRA Software, could the foundational work be made to allow license flexibility in the plugin arena? If so, how will this affect vendors? Would those that passed on purchasing a plugin jump at the change to have a different licensing tier choice? Or would vendors suffer?
Let me know your thoughts!