Is it just me who has a shocking price rise for JIRA 5?

Yeah, it's a massive increase. Agree about the "enterprise" options, almost worthless. I can barely remember when the last time Atlassian support actually solved one of my company's support calls.

I wouldn't mind, if they were charging per user, but actually they're charging per user per instance, and absolutely refuse to negotiate on that point. Yet jira is inherently not scalable, nor can you properly federate project admin tasks, forcing you into multiple instances.

I have worked at companies with 11 instances for both of the above reasons. Add in Balsamiq, Gliffy, Bonfire and others, and you faced with a serious bill. How is FogBugz looking these days?

Jobin Kuruvilla [Adaptavist]

Correction - Balsamiq have taken the sensible option and offer an ELA regardless of the number of instances. I wish Atlassian would go a similar direction.

Andrew Frayling

The price hike is a shock, but you're able to stay on your current pricing for unlimited users for two years and if you want to upgrade you don't jump to the $16,000 tier the upgrade price is $8,000. See http://www.atlassian.com/licensing/enterprise-faq#jiraenterpriselicensing-3 for details.

Not sure if people were aware of those prices because they're a bit buried and not easy to find if you follow the normal pricing routes through the sites.

Not much of a consolation I know as prices are still going up, but it may not be quite as big an increase as people first thought.

And I do agree it's one hell of a hike and I wouldn't be surprised to see quite a few lapsed renewals unless there are some changes.

Andrew.

Nic Brough -Adaptavist-

Proper clustering (not "split and integrate"), massive performance improvements for large installations, flexible and fast reporting for project-management, and built-in archiving are things we could sell to "Enterprise" users

Hit the nail on the head. My clients would probably be quite happy to pay the extra for any of those enterprise items, or even a step in that direction. Or in the absence of those, per user not per user per instance pricing. "Enterprise" is not even the right word for this new offering.

"then they'd seriously consider it" - but what's the alternative, not upgrading anymore? On first reading of the new pricing I'd assumed that my client would stay on vanilla non-enterprise pricing, as they don't want the extras. However looking at it it seems that that's not an option if you have more than 500 users?

Thanks for the feedback here. I'll provide a bit of background and context to the JIRA Enterprise offering and attempt to tackle the various concerns and questions raised.

Background

Scott (CEO) provided some background on his blog introducing JIRA Enterprise so I'd suggest a read over there first.

Last year at our Summit, one of our biggest take-aways was that we needed to evolve our focus on our Enterprise customers. Our products are being used in very large deployments and those needs differ from the needs of our smaller customers. As a result, Enterprise has been Scott's #1 personal focus this year and my role was changed to focus solely on the needs of Enterprise.

The feedback we have heard has fallen into a few categories:

improved training of users: a lot of time was spent in tedious front-line support tasks
a higher level of support (advanced customers, understanding configurations etc)
scalability
a mechanism for providing feedback on enterprise concerns
specific enterprise features such as auditing and archiving and analytics

JIRA Enterprise offering works to address quite a few of these needs by surrounding JIRA with services, training and support in an attempt to ensure successful usage and deployments at these higher levels.

Pricing

With this change, new user tiers were added to better reflect actual usage of JIRA (as Scott mentioned in his blog). When we first created JIRA user tiers, we were not fully aware of JIRA's broad usage and so we have better mapped those out now. It is important to note that cost changes are limited to installations of over 500 users (those up to 500 can opt into Enterprise). To make this change smoother for that subset of our customers, we included two year grandfathering where all existing customers can continue to pay at their current levels without change. With the new tiers, we believe JIRA offers great value and services for the cost at these larger (2k, 10k, and 10k+) sizes.

It was also mentioned that some customers run multiple instances of JIRA internally and might face budgeting challenges once the grandfathering expiries in two years. We're aware of this and are working on an option for large scale licensing. This is very early on so I don't have any details but we'll have an option for this situation long before grandfathering winds down.

Scale

One of the senior JIRA developers, James Winters addressed some of our work scalability in his comment above. We're working to both improve the scale of a single system and also improve how systems work together in federation. JIRA 5 has some of those improvements and you'll see more in the future.

T-Shirts

I do have to mention that the included T-Shirts are a humorous throwback to our original JIRA Enterprise product from years ago where T-shirts were included (and popular I might add) and a standard of our culture. We're aware they are not an "enterprise" feature in and of itself.

Training & Certification

Atlassian University training will be offered on the latest versions. The largest UX changes were in 4.0 so once you are able to upgrade to 4.x or 5 it will be less different to your users even if you are not able to upgrade frequently. The Certification program is a new offering for us and the SF based training will be where it begins but definitely not where it ends. Based upon need and popularity we will expand and improve this. Certifications are an important long term initiative for us.

Enterprise Evolution

We made this change because we believe our customers will be better served by the new offering, whether a result of today's offerings or in the future. Both the JIRA Enterprise offering and our overall Enterprise focus will evolve and improve over time. I know that the change in costs coming in a few years for some of our customers is an adjustment, and we plan to convince you it's one worth making with continuous improvement to our product and the JIRA Enterprise offering.

Sometimes these sort of discussions are also effective in person so I'm happy to exchange emails or have a phone call with anyone with continued concerns or questions that are not answered here. Just shoot me off an email (josh at atlassian.com).

Thanks for posting. Personally I feel that you should let bigger users opt-out until they feel that the add-ons are worth the money, rather than just left smaller users opt-in. The two performance issues James mentioned are really not big-ticket items, and also everyone gets the benefit, not just the customers paying the extra 50%. Letting people choose to pay for these extras would be a great advertisement for the company. As it is, and I'm sorry to say this, but it appears to me like you are just charging your bigger customers more because you can.

> We're aware of this and are working on an option for large scale licensing

Now this is something that my clients would be happy to pay extra for.

MatthewC

It would have been a lot easier to explain the price hike if Atlassian had actually done the Enterprise work before charging for it. The first question any client will ask is what am I getting for the extra money? If there was a Jira 5 Enterprise version that already had clustering & archiving then it would be a no-brainer.

Can you imagine the answer I would get if I turned round to my client and said, "I am demanding a 50% pay rise because I *may* do something really cool in the next couple of years".... there's the door, thank you.

I'd certainly agree with Jamie in that you're charging the bigger customers more because the pain of moving away would be seen to be too much. Feels a bit like racketeering....

Good will -1

Hugh Prior

Hi Thomas,

Thanks for bringing that to my attention. You are right. I certainly think that we will reconsider whether to pay the annual maintenance charge at all, and simply buy a new licence each time. The JIRA instance I am currently responsible for we bought the licence for in 2007 and I am not aware that we have have used any of the maintenance features in that time (we have not upgraded I am pretty sure), so it looks like we have thus paid 4 years (2008, 2009, 2010, 2011) maintenance fee for nothing. I will certainly look at whether it makes more sense for us to simply buy the new licence each time since it is a perpetual licence.

regards

@Jamie - thanks for the continued feedback. If you have some clients interested in a large scale licensing option they can email me and we'll get their name on a list to contact once we get closer.

@Matthew - our existing clients have the option to remain exactly as they are without change in their price for two years. We have already made some product (and service) improvements specific to enterprise deployments and there will be more between now and then. Thanks for the feedback.

@brusselsshrek - I'm hoping you've been able to upgrade JIRA in those four years... trust me: JIRA now is an immensely better product than it was four years ago. In all seriously we're very interested to make sure that you are able to upgrade easier in order to make use of the maintenance program. The 4.4 has some pretty serious upgrade improvements in it to make it easier.

I think the core message from users is that there is a demand for "Proper clustering (not "split and integrate"), massive performance improvements for large installations, flexible and fast reporting for project-management, and built-in archiving are things we could sell to "Enterprise" users."

I would raise my hand as a highly interested member of that market who is willing to pay for having those needs met. In fact, I am currently searching for partners/ custom solutions to resolve these issues ASAP.

The value I see in supporting JIRA through this "evolution" is:

(1) JIRA, IMHO, is passing out of the early-adopter (geek-only) audience, and into early majority. They are still a small company that has to serve an audience that is increasing exponentially. In order to scale to meet the demand themselves, they likely, naturally, have to increase their prices to manage their audience and support capability. I'm only working on assumptions, but i would guess they're challenged to keep up with demand. Their popularity and growing user-base is a very big value and attractor, because of community support and a widening population with experience using the tools. As such, over time, I can spend less time training users, and I trust these tools to evolve.*

*That said, i don't currently plan to buy into the Enterprise solution, because we just bought licenses and maintenance that cover us for some time. If I had to do so, I would likely be grouchy, but still pony-up, due to...

(2) The next comparable (enterprise) product in quality and features is significantly higher in price and also still does not deliver to scale. Again, it's just my opinion, but I like the products Atlassian has to offer, and just as much, I like the culture of the company. I want to give them my resources, not only because the products serve my basic needs, but also because I like the people and their approach. I need them to succeed in this so that my teams and business can be successful.

Now, I would like to add a few things to Jaimie's beautiful wish-list with my own prioritization:

Clustering (Does anyone know what happened to Scarlet (http://www.sourcesense.com/en/events/scarlet.html)? It sounds like they might have had a workable approach at one time. I can't get them to respond to my queries)
Performance improvements
User Management Enhancements (specifically to map and sync project membership to a group that has repo access) https://answers.atlassian.com/questions/18118/how-can-i-limit-access-of-a-repo-in-fisheye-to-it-s-corresponding-project-membership-without-manually-creating-and-updating-a-group-for-the-sole-purpose-of-managing-permissions
Reporting enhancements
Archiving
Enterprise community repositories for
- Automated test cases (for Atlassian products)
- Workflows
- Project templates for import
- Dashboards
Significant improvements in Atlassian University; orientation support https://answers.atlassian.com/questions/31320/how-can-i-send-a-series-of-orientation-emails-over-time-to-new-users

Just to sum, I, personally, don't feel that Atlassian is trying to rip anyone off. I feel like they are trying to scale and support the need as expressed. I am, though, giving them the benefit of the doubt.

Radu Dumitriu

Scarlet is dead (Rhett is not to be blamed for that)

Do you know if it actually worked? Because we may try to reproduce what we think they did...

ScottF

Beth,

Thanks for your clear and thoughful post. Most of what is on your list is on our radar (which is good for both of us!).

In terms of clustering, performance improvements and archiving - are they all aimed at increase in performance for you? If so - can you articulate the size of the instance you currently have, and are estimated to have? Assuming we could wave a magic wand and fix performance, would you still want clustering, archiving etc?

Your idea about Enterprise community repositories is intruiguing. Would we be able to continue this conversation via email? Email enterprise@atlassian.com if you have a moment.

Scott

It did work at the time, but this was back in the 3.13 days.

While the primary goal of clustering is to improve performance; there are some additional benefits:

(1) Assumed reduction of network latency tax for globally distributed teams

(2) Provide customization opportunities for really large accounts without the increased overhead/ noise in Administration in a single instance. Customized instances get hairy really fast. Our adopted customization policy is to provide a few standard options for the instance, and to approve custom requests for issue-types, workflows, etc. on an extremely rare exception basis with strong rationale for ROI. Ideally, Project Admins could create workflows, issue-types, and fields at the Project-scope level without exposure to Sys Admin, but JIRA doesn't work that way. Thus, the lock-down in customization at the system level.

As for size for 2012, I am looking at:

At least 5 geos (London, Delhi, Miami, Singapore, Sydney)
2550 - 5000 active projects in JIRA
2550 - 5000 SVN repos
4,000 - 6,000 users
4,335,000 - 8,500,000 issues

Ideally, users and data would be managed without boundary.

We are using most JIRA products, but Bamboo introduction will likely come in 2013, due to the infra investment. We are using Jive instead of Confluence and are working with AppFusions to evolve their connector this year. We hope to upgrade to JIRA 5 in Q2 and are currently running JIRA 4.4.4 on Macs. I know. I know. But we already had the infra in place, and there was not strong enough rationale for the additional investment in Atlassian-supported hardware.

I'll shoot you an email about the community.

AM12

Beth, you wrote

> JIRA, IMHO, is passing out of the early-adopter (geek-only) audience, and into early majority.[...]
> [...] have to increase their prices to manage their audience and support capability.

I'm just wondering if it's the right step to assume that running >500 user leads to need of services included in "JIRA Enterprise" and the planned "JIRA Enterprise" features.

Especially in environments with a lot of "jira-users" (read-only or sometimes just writing comments) and minor "jira-developers" (assignable jira users). In my case, the new pricing spoiled my planned Atlassian software budget completely.

If you take a look to the "Enterprise software" market, vendors ususally split pricing for features, users and services.

I'm not suggesting this for JIRA (especially not switching back to the beginning of Atlassian with different JIRA editions and feature set), but at least to offer:

different service levels for JIRA "non-Enterpise" customers and "Enterprise" customers (e.g. 8h x 5 vs. 24h x 7), instead of connecting it the total amount of "configured" user
or thinking about offering an additional license model: concurrent vs. configured users (I don't think that all configured users are always online in JIRA)
and probably JIRA editions with different non-functional (compared to features usable by users) enhancements like geo-clustering or distributed system, assuming that customers with >500 configured JIRA users != need all this upcoming new "Enterprise" features

And please be aware of the Atlassian "ecosystem" (Plugins). Most of the vendors took over the 50% renewal pricing policy of Atlassian, this will lead also to a massive cost increase for "Enterprise" customers in need of commercial JIRA Plugins.

As you mentioned, audience changed and I'm pretty sure that some business and mission-critical JIRA systems running out there.

But becoming more "Enterprise" like and reaching this level of investments will lead to new contacts in the purchasing departsments ;-) which will start to compare the licensing and service model to other "Enterprise" vendors.

So my hope is that the "Enterprise" team at Atlassian are still open to question their new Enterprise pricing model descisions and have the courage to adjust in case of new insights.

Jobin Kuruvilla [Adaptavist]

I'm not with Atlassian, but since you addressed your response to me, I am happy to reply with my thoughts. First, it's interesting that your purchasing department would make product comparisons and selections for you, but whoever does that will come across a wide variety of vendors and products that meet different feature/ scenario needs and hit different price points. Ultimately, the product you decide to invest in is your choice, but changing products, especially for larger organizations comes with hefty change management costs and a longer timeline for doing so; this should be a factor in making your case for budget to whatever governance board makes the decision.

The "approach" I said that I liked includes both how Atlassian is heavily focused on building community and how they have taken an ala cart approach to the build of the products, meaning that they have not built some monolithic monster that slowly dies over time due to the build-up of technical debt. If something needs to be ripped and replaced, they can rip pieces of it. Both of these things give me confidence that the product suite will persist, evolve, and succeed, and this is very important when making long-term tooling decisions.

As for the "Enterprise model" they have selected, I suspect that, too, will evolve over time as they gain a better understanding of the needs and can shape it accordingly; however, and I could be unique in this, but I like that Atlassian tries to keep it simple and fair with an open price structure that isn't specially negotiated from buyer to buyer.

Aside: It very much reminds me of the approach Saturn took to selling their cars. The price you saw on the sticker is the price - everyone - paid. Saturn, too, was very early in recognizing the value of community in building a great brand and product. If you can't tell, that's another company I dearly loved, and am saddened that they were eaten up by larger influences.

J Thomas4

I hope the JIRA Enterprise standalone Windows installation will come ready packaged with an x64 compatible Tomcat! If you don't need more than 1GB memory for JIRA then you're not really an enterprise user...

They now have one. No more replacing tomcat service files

J Thomas4

I'd also question defining an 'Enterprise' customer purely on the number of users - surely the number of issues, workflows and custom fields is a more accurate measure of complexity?

For instance we have nearly 500 active users but only 66k issues and nearly 200 of those users haven't logged into JIRA in the last month. 'Enterprise'?

J Thomas4

Yay, a faint light at the end of the tunnel for when we finally upgrade to 5.0... Unfortunately I need one for 4.4.5

Jobin Kuruvilla [Adaptavist]

You can manually replace the tomcat 64 bit files (only tomcat6 and tomcat6w files). Just make sure you use the same version as that of the one that comes with JIRA. Works fine.