Why are we now paying for functionality that we used to get for free in terms of the Calendar Plugin?
Asked by Harvey Moore:

The calendar plugin is an essentual part of our Confluence usage. Since it has been depreciated (and we have upgraded to Confluence 4.0) we have lost this function. Whilst I accept that it was our decision to upgrade, it wouldn't be long before Atlassian started to recommend this upgrade.

You can now get this lost functionality back by **PURCHASING** team calendars. Doesn't this go against one of Atlassians 5 values - "Dont \*\*\*\* the customer"? We feel throughly \*\*\*\*ed as you've just added $1100/year to our Atlassian bill to maintain what we already had. We're may or may not want all the lovelies that come with the new Team Calendars, but that should be our decission.


Answers:
author: Sherif Mansour
body: Harvey,  

You raise some valid points. I'd firstly like to say, this isn't a decision we took lightly. I personally spoke to many customers about this, trying to understand what problems they would like solved and in addition, looking at how we can built something that is sustainable in the long term.  

After much discussion and analysis I strongly believe that pricing this plugin is the right thing for our customers. Let me explain why:  

After conducting many interviews and speaking to a lot of customers about what problems they want solved in terms of calendaring, we feel we can solve a lot of specific problems with the combination of events, people, projects (JIRA) and content. Atlassian sees this plugin working alongside your personal meeting or events calendar. Team Calendars already has an extensive roadmap which is jam-packed with improvements and exciting things.  
It was apparent in our research that not every customer needs a team calendaring solution. It doesn't make sense to invest core roadmap time for those thousands of customers who would never use this feature. Not bundling Team Calendars with Confluence means that  
1. We don't doesn't increase the development/opportunity cost for Confluence. Especially for those customers who aren't going to use it.  
2. We can focus and build improvements on the plugin based on the plugin demand - a much more measured and fair approach for all our customers.  
3. We don't de-invest from the Confluence roadmap. Team Calendars is staffed by a different team, meaning Confluence roadmap work continues to develop with no impact to the thousands of customers.   

Hope this answers your question. At the end of the day, I'm more than confident this is the best thing for our customers.  

Sherif Mansour  

Team Calendars Product Manager

comments: author: Harvey Moore
body: Sherif,

Whilst I agree with a lot of what you have to say, and the obvious effort to guage customer requirements for a "Team" calendar solution. I feel that you still do not have a valid reason for reducing the functionality of the basic Confluence package. Confluence still costs the same to us, but does less for our money. Having had a long faught battle to justify the expense of Confluence, I'm now having to answer the question (from my fellow managers and the directors) "What next will they make a charged for item?"

I quote you "It was apparent in our research that not every customer needs a **team calendaring** solution", and I agree, but what we do want is the calendaring solution we already had - it has become an integral part of our working practice.

I understand that the team calendaring is an entirely seperate developement team (and I would organise/finance this situation in the same manner), but what happened to the people working on the original calendar plugin?

I suspect that the developement path is set in stone, so this change will not be reversed. Until now we have been very happy with the Atlassian products and service, I just hope that similar decisions do not affect our decision to entrust this part of our business to Atlassian.

Thankyou for the reply,

Harvey Moore


author: Sherif Mansour
body: Hey Harvey,

Yeah, I see your point and appreciate your concern, especially with "What next will they make a charged for item?". I can't forsee us doing this for every major feature in Confluence. The Calendar plugin was a tough one because it evovled as someones small 20% project inside Atlassian. It was never supported or really minatined. At the same time, a few customers picked it up and thought it was pretty cool - long story short this grew to become critical. The bad thing was that it was never intended to be, so much so that Team Calendars is a completely new plugin- doesn't use the old code base etc.. So I do think that we were in a bit of a weird position with the old calendar plugin. I can't forsee this happening with all our other major features.

With that in mind - we've learnt a lession in these types of things.

Thanks for being open and sharing your concerns. Much appreciated. I'm sorry you feel fustrated about this - and I do assure you this decision wasn't made lightly. We debated, discussed, spoke, stressed-over this for a long time... I did see a couple of grey haris appear on my head! :-)

I'm very happy we've reached to this position, it's the most sustainable model for everyone.


author: Jon Cotter
body: Smart customer service would be to credit them


author: Rodolfo Romero
body: Sherif,

I understand that it might have not been easy to make a decision so drastic with this important piece of Confluence functionality. What I don't understand is what will customers with many pages using the old Calendar plugin do if they don't want to upgrade to Team Calendar. We have many pages that now are useless because of this.

I believe, a better approach would have been to continue providing the basic functionality that was already included in the Calenda plugin for free (or included in Confluence price) and a paid version for those who wanted all the bells and whistles.

In our particular case, we discuss the purchase of Team Calendar but the product has many problems and we couldn't justify to pay $4,000/year more for just once single piece of Confluence functionality.


author: Davet
body: A lot of the Atlassian defence against accusations of market gouging bears a remarkable similarity to recent exhorbitant price rises from VMWare.

There is I beleive a conscious management decision to focus on the big end of town (where the big bucks are) because to the corporations a couple of extra thou a year is peanuts. Bye bye little customers :\[

What started out as a reasonably priced ($6000 P.A.), useful wiki (after a lot of free plugins were added) has now become a $20,000 P.A. pig-to-administer flying spagghetti monster with ransomware built-in. The upgrade path (and access to all those wonderful new features) is almost always blocked by out of date plugins that are prime candidates for the dreaded "pricing announcement" which of course is always promoted to be in the best interests of the customer. It is never promoted as being in the best interests of the bottom line ;\[

Whatever happened to the "

### Open Company, No Bullshit" {#toc-hId-1508164746}

comments: author: Harvey Moore
body: It's a shame that this has caused such a strong feeling, but it is indicative of a company not following its values when it comes to making money decisions.

At present, I want to set up a second instance of Confluence for our service network, as the team calendars is visible to all users and I don't want them looking at it. Unfortunately, the directors have refused the capital expenditure stating this very example -\> that would have been a 50 user instance of Confluence = no sale.

(PS love the term "ransonware," may have to plagerise that one!)


author: jimmycd
body: The license policy of atlassian leads us to the decision that we move away from confluence (and later jira also) due to the predatory plugin policy (i.e. we use lots of free plugins which change to a priced modell whoch we are forced to buy when upgrasing jira. otherwise the plugins are not working any more -\> our pages will not work). we put that many times to atlassian and just asked for the option to keep the free one with no additional functionality compatible with new jira versions. no chance. they say its up to the providers of the plugins to decide their policy..... clear.

now after the xth plugin changing the policy and increasing the PA costs drasticaly we have no choice than to move away from all atlassian solutions. bottomline the cost to change to other products is lower than keeping it (without extrapolation the developent of the cost curve from the past 10 years....).

very disappointing and apparently a clearly atlassian hazards the consequences of their license policy. btw: atlassian sales people: save your time to convince us: board decision already made....

bye bye


author: Mahbub Rahman
body: $6000 for a calendar feature? I think that is a bit excessive.

comments: author: Rodolfo Romero
body: I think it is expensive as well. Confluence as a whole costs that!


author: Beth Schaefermann
body: I interpreted Sherif's response differently: instead of increasing the Atlassian cost for everyone holistically due to a variety of normal inputs (growth in business, audience, evolution of features, etc), they decided to break out some features and charge ? la carte so that you only pay for those features you need. If they had not broken out those features, you would still have had the cost increase (everyone would have). This way, though, provides greater flexibility in choice - to pay only for what you need.

Atlassian is still very attractively priced on the market for the quality of products and services they provide, in my humble opinion.

comments: author: Harvey Moore
body: Thanks Beth,

Good point well made! And yes, it is very attractively priced.

But has my cost of Confluence gone down to reflect this?


author: Beth Schaefermann
body: To use an analogy, the price of gas (and most things) only goes up over time. The price of the application went up due to a variety of inputs I described above), but bits were broken off to allow people to choose whether they want to continue to invest in the evolution of a specific feature, or not. Continuing to invest in the evolution of a software product or piece of it is a choice based on perceived business value.

To look at it from another perspective, the new Confluence price has "gone down" for those who choose not to invest in the evolution of a specific feature. Otherwise, all would be paying the new price of a solution that contains all features.


author: Rodolfo Romero
body: That would work in a scenario where existing customers are able to continue using the same functionality for the same price. In our case, we now have many useless pages becuase the Calendar plugin is gone and we cannot justify spending other $4,000/year to buy Team Calendar, which is only a little piece of functionality compared to all the other functionality that Confluence provides.


author: Andrew
body: At first glance the Atlassian products seem reasonably priced, once you start expanding the functionality with Plugins and third party plugins (which may be already bundled with other produts) the price escalates. Ths escalation each year (one year the plugin is free the next who knows) makes budgeting and getting approval of the budget extremely difficult. No one like to keep having to go to finance with a begging bowl to get approval for more spend. I have noticed that the concept of $0 is used often as opposed to 'free'. That has put me off loading any of these plugins as it lends itself to 'ransonware' (Davet 2012).


author: Michael Rutledge
body: And another year later, same deal with the calendars, among many other plugins. This behavior of forcing users into purchase of once free functionality is swiftly becoming the norm for atlassian. At least in my experience over the 8 years of using the software.

In my opinion, they (atlassian development) should have forked calendars into two branches, one deprecated version that is no longer supported by development, but installable on future versions, and a second which continues to receive development and support.

This would have at least retained existing functionality for users without a forced purchase and allowed them to focus development effort and a sustainable business model for their product.

Just my two cents, but it seems like every time I get something going well in confluence, two major versions later I seem to be paying for it out of nowhere.

Pretty frustrating.

Apologies for the poor form of late posting. I feel the opinions I share have been clearly posted previously in the thread, but it's still an ongoing and pronounced issue with Atlassians roadmap/management direction.

comments: author: Andreas Lundstr?m
body: I don't know if this has been done already, but I just ported this plugin to work in a Confluence instance that we work on, that we updated from Confluence 3.x.x to Confluence 5.6.6.The work concisted of porting JavaScript from using prototype.js to jQuery and some xwork/velocity/dependencies hade to be updated..It works fine, no complaints (yet) (:


author: Andreas Lundstr?m
body: had\* to be


author: BJ Golding
body: Andreas - We're in a similar situation. About to upgrade and just realized our calendars have broken. Do you have a copy of the plugin available? Or are you willing to give more details on the backporting process? Any assistance you could provide would be very helpful.

Thanks!


author: Andreas Lundstr?m
body: Hi @BJ Golding, I'll have a look to see if I can retrieve it for you.. I'll get back to you in this thread if that is ok?


author: BJ Golding
body: @@Andreas Lundstr?m Sounds Great- Thanks for getting back to me! ? Looking forward to your reply.


author: Andreas Lundstr?m
body: @BJ Golding: this is what I could find (quickly), a version without the "user picker" on add/edit event, but otherwise functional for up to latest Confluence, build the plugin and posted it here: <https://github.com/alundstroem/confluence-calendar-jquery>

Can you try it out and let me know if it works for you?


author: BJ Golding
body: Hey @Andreas Lundstr?m - Tried the plugin and it works great. Thanks so much, you rock!

-BJ


author: Andreas Lundstr?m
body: Glad to hear it @BJ Golding. Do you need the user picker feature?


author: BJ Golding
body: @Andreas Lundstr?m - If it is a simple fix, then by all means, yes it would be great!

-BJ


author: Helen Heath
body: @Andreas Lundstr?m Tried to install your plugin (thank you for this!) but Confluence errors with:  

Could not find a handler capable of installing the add-on at calendar-plugin-2.7.5.1.jar. Check that the file is a valid add-on.  

Obviously it can be done, because @BJ Golding has done it, but why can't I upload it? We're on ver 5.8.15 of Confluence. Thanks!  


author: Andreas Lundstr?m
body: @Helen Heath, I'll try to check and see if I can help you out during next week


author: Helen Heath
body: @Andreas Lundstr?m Thanks, I actually managed to get it installed via UPM, it was a problem with my download. Redownloaded it and it installed just fine, thank you! However, I'd really appreciate you just letting me know how I reference it from within a page! I sort of expected it to be added to a drop-down list of things to add into a page, but it's not available from any edit menu, macro list, or anywhere else I can see to select it from? It's definitely showing in the list of user-installed add-ons, but nowhere I can reference from within a Confluence page? I'm sure it's obvious, but how to use it is currently escaping me!!


author: Andreas Lundstr?m
body: @Helen Heath, Good to hear that the installation went ok - have you tried adding a calendar (in edit mode) by the "{"-notation, or by "Insert", "Other Macros"?


author: Helen Heath
body: @Andreas Lundstr?m Yes, I tried that - it's not available in the Macros list. I've checked that it is enabled, and it is.


author: aaron wideen
body: And 2 years later it sounds like this plug-in has retained its same price and same functionalities. Aside from adding in being able to pull from google calendar (which I could do with an iframe for free). I see that confluence itself has grown exponentially in look and feel and the different functions you could do while development with the 'team calendars' has kind of fell off the grid.


author: Hendrik Nehnes
body: With the 4.x update not only Atlassian ?$?% the customer, also customware that delivers the reporting, scaffolding, ... plugins. Now you have to pay for that plugins, before they were free and they does not seem to have to good support as atlassian does. When I look back at the last years the atlassian eco system continously increases the costs and it will be hard to explain that to the management - have a look on the new jira licensing. Until now with 4.x we had unlimited users. With 5.x we need to buy a 2000 enterprise license. The upgrade costs a much as a renewal for 4.x and we get less as we do not have unlimited users anymore. Im am very disappointed that atlassian goes this was and I think we will not continue this path in some years and move to other products that have similar functions and a fair pricing without caching the customer with a cheap start and an expensive ending.


author: Beth Schaefermann
body: I saw this calendar plug-in this morn and thought of this thread. Maybe it's an alternative to look into: <https://plugins.atlassian.com/plugin/details/293>

comments: author: Rodolfo Romero
body: This Calendar plugin is for Jira only.


author: Ariela Stern
body: I understand asking customers to pay extra for "tricked out" calendars, but not even having a basic option is a feature sorely lacking for the cloud version.


author: Trish Ind [MMAL]
body: How do you copy a calander format into confluence with out paying for it?


author: Darren Pegg
body: Luckily we have Jira, and I hope to create a workflow that allows actions to be added by creating an issue htough exluding it from reporting.. Although I have a feeling I'll hit a bick wall!


author: Richard Wilkinson
body: What are the symptoms of this lack of support? Our calendar controls have just stopped working with the following error:

Error formatting macro: calendar: com.thoughtworks.xstream.alias.CannotResolveClassException: com.atlassian.confluence.extra.calendar.model.CalendarGroup : Unable to load class \[ com.atlassian.confluence.extra.calendar.model.CalendarGroup \] from PluginClassLoader

We upgraded from v3.2 to v3.5 a few months ago, but the calendar control didn't stop working when we upgraded - apparently it happened last week. Is it trying to refer to a control on an Atlassian server that no longer exists, or is this error unrelated?  


author: Gary Weaver
body: I'm sure that there are infinite possibilities when doing scheduling integration with Jira and Confluence. In the future, maybe you could add a vacation request to your calendar, and it would automatically figure out how resources would have to be re-allocated on Jira tasks, the differences in Gantt and burndown charts would be created, new estimated dates would appear and your manager could deny that vacation because it would mean that the team could not hit a deadline.

BUT, even with those possibilities, Confluence, Jira, etc. is not the place to manage calendar/scheduling/event information. Even scheduling Jira tasks, etc. should just hook into an external scheduling system, imo. Like I've said before, if anyone can do it, Atlassian can; if they want to run the calendaring services rather than just interact with them, that is their decision. But, if they do it, I think they should either (1) purchase an existing company like they did for Crowd, etc. that has a nice calendar server (and this probably isn't an option- just throwing it out there) or (2) just integrate with existing calendars via CalDAV and leave calendar support free in Confluence, Jira, etc. as part of the product that relies on connection with an external server (or servers).

For now though, if I were in a position where my company depended on Confluence's calendars, I'd bite the bullet for now and pay the additional cost, and then either transition to something else (Exchange, Oracle Calendar, etc.), or hang on and bask in the glory of whatever Atlassian comes up with (and I'm being serious- that isn't sarcasm). I just hope the end solution doesn't involve Atlassian banging their head against the desk a lot because of the craziness involved with doing calendaring at an enterprise level. Farm that out or buy it, instead.

comments: author: Sherif Mansour
body: Yeah, you are right about this. I actually think its a messaging problem we currently have and are trying to work on.

Long story short - we don't see Team Calendars replacing your Outlook / Exchange calendaring system AT ALL. We don't want it to go that way. Our goal with Team Calendars is to help teams collaborate, plan and communicate team events - not perosnal meetings (this also involves JIRA projects). Where applicable, we would integrate with the end-users personal calendar (Google/Outlook/Lotus Notes.. or whatever).

Team Calendars just helps teams in that intermediatry step before it ends up in your personal calendar.


author: Harvey Moore
body: Jo-Anne,

Thanks for the suggestion, but that would mean getting skills in outside our core business set. Can't justify the expense.


author: Jo-Anne MacLeod
body: It looks like the source is available. If you want to continue to use the older one, perhaps you (or someone) wants to take over the mainentance of the plugin? Just as anyone can create a plugin and then stop supporting it, I guess that Atlassian can as well.

So you know where i am coming from, we never used the old calandar for a variaty of reasons. We do now use Team Calandars. It also has its own set of problems, but that is a diffeent post.


author: Rayone Moyer
body: We have not upgraded yet but will be doing so soon. We use calendars a lot so if you can't use your original calendars that might be a big issue for us as well.


author: JamieA
body: Fair point... I suspect that they underestimated the amount of work required to maintain the original calendars. If it happens with other functionality I could get a little miffed.

comments: author: MUTELLIB JUHAR JAALALLEE _NAMOO JAALALLEE_
body: Jamie


Tags: team-calendars-for-confluence