Disillusioned with confluence

[Bill_Campbell]

Confluence has a good deal of funtionality but it seems to be missing the mark , from my perspective, is approaching a price point that has me evaluating other solutions.

Plugins, while at one time, I thought was a strength for confluence now I view as a negative. I won't be purchasing any more plugins. I purchased TaskDock, who after taking my money, announcd they were bought by Cisco and no longer would be developing the product. So, I could either abandone upgrading confluence forever, or disable taskdock.

Then I got over 100 users and had to re-license confluence for 500 (which we will never approach) and that caused a cascading effect of upgrade licenses for several other plugins. Not unexpected, but when you add up what this upgrade costs, the cost benefit begins to lean towards other more full featured solutions.

One of the cornerstones of using confluence was the scaffolding plugin and the ability to develop forms from templates. Very powerful. Then, it all fell apart with the 4.0 upgrades. The forms don't render cleanly, doesn't work under IE correctly, and all in all, is just plain ugly and not user friendly. While this isn't necessarily the plugins fault (core confluence change) it also doesn't work as nearly as well as it used to. You wouldn't even recognize it from one version to the next. So, I have made the decision that I can't move forward with that plugin - which again, for me, was the strongest plugin for enhancing confluence.

Then we have the calendar plugin.. priced so far beyond its usefullness that I couldn't even contemplate it - but it would offer some functionality and convience. Should have been natively included IMO.

Sorry to rant, but I really believed I could change the way we worked in a cost effective manner. Now I feel its a costly black hole.

[Sherif Mansour · Accepted solution]

Bill,

Thanks for taking the time out to share your feedback. You raise some great points here about a few issues. Let me try and share my thoughts on some of these issues.

Firstly on TaskDock. It's unfortunate (for us) that they got acquired by Cisco and there isn't any more work going to be done on the plugin. This is out of our hands and there isn't much we can do about this. It does highlight, however a problem which you've refereed to - if the plugin becomes business critical for you guys then you need that assurance that the vendor won't go belly-up... to be honest, I'm not sure how we solve this problem. A lot of marketplace models (e.g. the Apple AppStore) would also have this issue. I've passed this feedback onto our marketplace team.

Not sure if you are aware or not, but I think the CommalaTech team worked with the TaskDock team to try and transition their functionality to Ad-Hoc Workflows. So they've tried to fill that gap in their product: https://www.adhocworkflows.com/display/WWW/Product not sure if that helps or not. In addition, in the upcoming Confluence 4.3 release, we've introduced inline tasks (tasks in Content) and a personal tasklist for users https://confluence.atlassian.com/display/DOC/Confluence+4.3-m11+EAP+Release+Notes don't know if that helps fill your business need to some degree either. Let me know your thoughts.

The second issue you raise is about our licensing model for add-ons. It's a tough one. To be honest, we've discussed and debated this internally quite significantly, and Alex has already made some good points about this above. One that should also be brought up is the inherit complexity that would arise if we de-coupled the add-on user count from the Confluence license count. If you bought an add-on for 25 users, but you own a 100 user license, what do the other 100 users see if they hit a page which uses that add-on? Do we start prompting end-users and letting them know they can't view this page because they aren't licensed to view it? It would also add quite a bit of complexity on the add-on. In saying this, it isn't something we are not considering. It would be a significant change to our licensing model and would have big implications across all our business - form support, to purchase to product engineering. So it isn't something that could happen in the short-term.

Regarding the scaffolding plugin, I'm sorry about this. With Confluence 4.0, we gave the ecosystem, partners and third-party developers around a years notice that it was coming and clearly its still impacted your team. I'm sure Customware would appreciate any specific issues raised in their project https://greenhouse.customware.net/jira/browse/SCAFF.

Finally, about the calendar plugin. I've outlined in detail here https://answers.atlassian.com/questions/13513/why-are-we-now-paying-for-functionality-that-we-used-to-get-for-free-in-terms-of-the-calendar-plugin?page=1#13610 why we are charging for the plugin. So I won't repeat that. I will, however talk about your feedback about it being included natively in the product. To be honest, this is something I was heavily involved in discussions about this - we debated and talked to a lot of customers about it. For us, for an add-on to be considered as core to the product, we'd like to think it would be used by around 50% of the customer base. It turns out that after quite a bit of research and it's even being proved by our sales for Team Calendars, that far less than 50% of Confluence customers want a Calendar and event collaboration solution for their instance. In fact, we're talking around the 10-15% mark. To me, this validates the decision we made around this in that we haven't got 80-90% of customers paying for developers to work on Team Calendars in Confluence when they aren't using it. Team Calendars is a separate funded team to the Confluence core team, ensuring that we have the right amount of investment in it.

Another point you raise is about the actual price point of Team Calendars. To be honest, I haven't heard too many complaints about this - most of the complaints I hear is the fact that customers are paying for the actual plugin. I've actually noted your feedback about the price point internally so we can keep a monitor of this and adjust it accordingly if it keeps coming up

Hope that helps clear up a few of your questions, thanks again for your feedback.

Sherif Mansour

Confluence and Team Calendars Product Manager

[Bill_Campbell]

Thank you Sherif - appreciate the detailed and thoughtful response. Any plugins that are used, become business critical in that its used and hard to remove. I do believe that plugins are more problematic in terms of going under or out of business or just no longer supporting it. To that end, we will rely soley on confluence functionality. That is my solution to the issue. Perhaps my original thread should have been named "disillusioned with confluence plugins"

Commaltech does appear to be a solid company with great plugins but the liability is there.

With regards to pricing plugins, its the total cost that concerned me and the price jump when upgrading. 100 to 500, involves a Confluence fee for a couple thousand, upgraded plugins for a couple thousand a pop- it adds up quite siginificalty where I should be considering a more robust application where I don't need the plugins (and thus lose the liability that they bring). Someone in this thread called it - change the model so a 100-500 pop doesn't hurt so much. Say 250 or even in leaps of 100. I know you thought all this and I've read numerous threads on it (You feel like you are beating a dead horse?:) I am only using 1/5 of the total licensed conflunce users. We are just over 100 and will never approach 500. The per user fee is high based on this jump. So, the price itself for the upgrade might not seem bad but when coupled with the plugins, its adds up.

The calendar plugin duplicates what I have in exchange. I would like the convenience of one stop shopping and letting someone have a calendar in confluence but its hard to cost justify when I have that functionality elsewhere. My goal is to drive adoption of confluence, so, any way I can get them there the more entrenched and usable the product becomes.

Thank you and I will give more consideration to what you what you wrote above.

[Sherif Mansour]

Thanks for the response, Bill.

Actually, you make a really good point about _unused_ licenses, vs the actual license size you have. To be honest, it didn't really pop in my mind immediatly, but it is a good point. I'll bring that up with the team, I would assume it's also been discussed before - but worth bringing up.

RE: calendar plugin... We don't want to be an alternative to Exchange, we are really focused on group calendars and calendar sharing with integration into your email clients. We are also focused a bit on project planning with JIRA integration, something which Exchange doesn't really provide... but from reading your message, I think we have to better communicate this! Thanks again for taking time out and letting us know.

Sherif

[Alejandro Conde Carrillo]

Hi Bill.

I work as a support engineer for Atlassian but please take this answer at a personal level and not as an official response from Atlassian.

Let me comment something regarding Confluence licensing. Atlassisan's aproach to licensing is to make it simple and afordable for all kinds of customer, from small startups (licenses from $10 for 10 user, with the same support than the rest of the licenses) to big coorporations. I understand that is it a bit frustrating to have to pay for some users you are not going to use (in the near furue) but I still think the Atlassian's licensing system is way better than others.

I remember years ago, working for another company, I was thinking about buying certain well known DB server. It was a really hard work to get an vaguely approximated price quote and the license had to be purchased from certain partners in my region and there were always room for a "discount" depending on how well you negotiate the deal (which I find annoying).

Personally, I preffer the straight forward model of Atlassian. It is true that the gap between 100 and 500 user is big, but it helps to keep licensing simple. In any case Atlassian is a very open company and any feedback is always welcome (specially when it is reasoned as your comment is). You can always rise a request for 250 users licenses and it will be studiated by the sales department (https://jira.atlassian.com, create a new issue under the Sales project).

Regarding plugins and compatibility with new Confluence releases, that is a problem which affects all kinds of software like OS, browsers,... As many plugins are developed by third parties, Atlassian has no control on their prices or release process.

I hope the new features help to regain you as a Confluence advocate. Thanks for your feedback

Best regards,

Alex.

P.S.: To Adolfo, regarding teh comment: "All Plugins should be offered in a Free version and (optionally) in a Paid version." There are lots of companies investing their resources and time (and money) developing and supporting those plugins. Do you really think is fair and sustainable to give all that work away for free? I really believe and love open source software but I am sure that, under a "free plugins" model many of the most popular Confluence plugins would have never been developed.

[Radu Dumitriu]

ok, I cannot vote you twice.

[James Weatherell]

owncloud...?

[Radu Dumitriu]

Confluence had a lot of negative posts. I don't think it's such a bad situation as you describe it.

As a plugin developer, I cannot comment on the quality of plugin X. Hell, I made mistakes myself (and I'm pretty good); I'm sure Confluence 4 put a lot of burden on the all Confluence developers. But an upgrade should be tested before and this is your responsibility; I think that by working more closely with the developers from the aforementioned plugin one would only benefit - that stays at the core of any good software IMHO.

Although I dislike the practice of "give something free then after some time ask for a price" I think users should be placed in developer shoes from time to time; I'm sure those making that decision on Calendars plugin had not a light heart doing it. We have 3 free plugins and only to maintain them means a lot of work, believe me. We all want free stuff, but let's ask anyone creating free stuff how much s/he received from donations. I don't think anybody is driving his 911 Carrera GTS right now (or are you, Jamie ?).

Now, I don't want to be an a****e. I just believe that we always should strive for win-win situations; the key is cooperation and not perpetual whining :)

[Bill_Campbell]

Thanks Radu - appreciate you taking the time to respond. You are right about testing upgrades, and we do. The issue is that the plugin doesn't work as it once did, nor is it likely to ever. It now works in a manner completely foreign than the way it used to. Not the plugin manfuctures fault per say, as they have to work within the confines of confluence. Not confluences fault for enhancing their product.

We need the new features in the latest version of confluence - it makes it so much more usuable.

So, the point being, the commercial plugins have been burning me lately to the extent I won't use them corporite wide. For a small work group it would be fine as you can deal with the fall out. We will stay within the confluence code base and avoid plugins (which as I initially indicated, I had believed was one of the more powerful features of confluence.)

I'm hoping for some feedback that my bring me out of my confluence funk!! I was its prmary advocate.

[JamieA]

Not sure if that "Jamie" is this one, but personally the sum total of donations I have received since 2007 is $15, minus paypal's 10%. Not quite enough for the 911. I am feeling disillusioned for a bunch of reasons, but the money aspect is not one I don't think.

[Radu Dumitriu]

@Jamie Echlin

Man, sorry for reffering you in the post, but I really feel your pain.

[eveets]

I've used both confluence and JIRA for a while now and the licensing is one of the worst I've seen in a buisness product.

There's the issue of having 101 user and paying for 500 which is quite ridiculous if you think about it for a second but this has been discussed plenty here. 

Also, I've used Confluence and JIRA with clients to let their project managers follow the progress with our tools. On the current pricing model, this means that we have to pay for those user even if they have mostly read access. Even then, sometimes, a client will come and say he/she is using JIRA as well on their end, so this means that a user is paid for twice in different instances. In an era where everything is connected and even Atlassian has an Atlassian ID that is universal, this is a bit stupid.

The add-ons are a good idea but using add-ons is so risky that we prefer not to. Add-ons can go belly-up as discussed previously but, the price hike it entails when you upgrade your license makes using more than a couple just not worth it. And what's the point of add-ons if you can't really use them.  

• I'd gladly pay for add-ons if they had a fixed price (not depending on license size) and if Atlassian would guarantee they will support it for at least a year even if they go belly-up. 
• I would prefer (by far) to pay a per user fee like every other software out there (harvest, google apps etc.) and would love to see a decreasing price per user when you hit certain marks.
  
  

Just my 2 cents...

[ATG NOC]

I have to agree with Steeve here. We are becoming affected much the same way. We have reached our license cap and we have recently hired a new staff member. To give this one extra person access, it would cost us many thousands of dollars to upgrade all the licenses. It is not justifiable.

So we were forced to turn to the constant juggling of disabling access to a slightly dormant user so somebody else can use the system for a few hours and then switch back. Is is maddening, to say the least. The only way I see around this is to create shared user accounts which bring with it all sorts of problems not related to finances. We're not sure if using such shared accounts go against license terms, but something has to give.

Seeing this discussion has been ongoing (here and in other areas) for over 7 years now, I think it is safe to say there will be not be a satisfactory conclusion soon enough for it to matter. I hope this does not mean we are forced "out of Atlassian" and pushed into looking for an alternative software vendor because I have enjoyed using Atlassian products for over a decade now.

The "Everything-as-a-Service" model does not work well in the real world when you reach a certain threshold where "one more user" starts to equal many thousands of dollars. You can't afford to not pay up yearly or risk having your instance compromised. You also can't afford to not pay up and lose access to plugins where some of your data is stored and you would lose access to it.

It starts to feel like being held hostage. Nobody appreciates feeling such vendor lock in today's day and age because that practice should have been abandoned a long time ago. Software vendors tend to like this model because it guarantees them recurring revenue. It also works to alienate your customers and eventually, when critical mass it reached, they are forced to look elsewhere. Loyalty should matter to you, too.

I am not saying organizations and individual teams do not deserve to get paid for their hard work and providing sometimes thankless technical support for their products.  Quite the opposite, but keep it fair.

Why should it matter to the developer if I have 25 or 26 people working in my team, or 101 instead of 100? Why do they even need to know the size of our organization? The software is the same. It does not cost the developer more effort to create the software just because there are more people in our building today vs. last week.

What about seasonal staffing? I may have reached my license cap today but I will not anymore in a few months. Can I even upgrade and then downgrade to a lower tier license for part of the year as staffing fluctuates? Now it's becoming a question of "many thousands of dollars for an additional user who needs access for a few weeks".

[Carl Myers]

Devs need to be paid for their work, but discontinuing a product and leaving your customers hanging is skeezy and morally reprehensible, IMO. if they don't want to develop it anymore, then it must not be worth anything to them, then they should release the soruce code so someone else can.

I fight aggressively within my company to only use plugins whicha re open-source, or whose license allows us access to the source. If they ever stop selling the plugin, then, we can fork it and use it internally, and update it for new versions ourselves, preventing lock-in. Consumers of software, in general, need to be more aware of the importance of open-source and source-available licenses (atlassian also offers source access to large commercial customers, for example).

Like any other failure mode, without taking proper precautions to ensure the software you depend upon is robust in the case of company-failure, you can't be suprised when a company fails to deliver and it breaks your dependency.

[Bill_Campbell]

Thanks Carl - good points. I just don't have dev resources or expertise to bring it in house. I do appreciate the free plugins and have no expectation they will work or continue to work. Some of the stuff Bob Swift (think that is his name) did with SQL connectivity is really cool valuable stuff But I won't use it anywhere in a critical path. I expected better support from the commercial plugins and just don't see it. (TASKDOCK is the company that burned me when they were bought by Cisco. Email basically said "Bought by Cisco, Goodbye").

[Adolfo Casari]

All Plugins should be offered in a Free version and (optionally) in a Paid version.

[Joe Clark]

Hi, I've added the "team-calendar" and "scaffolding" tags to this question so that hopefully people who are involved in those plugins can provide some perspective on your concerns.