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.
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.
Team Calendars Product Manager
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,
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.
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.
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 "
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!)
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.
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.
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.
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).
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.
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.
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.
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.
@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?
@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-22.214.171.124.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!
@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!!
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.
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.
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.
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.
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?
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....
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