Nail on the head regarding either selling a lot cheap, or little at high price. They went for the latter as you mention. I manage software licenses at my employer, and have been put off the price of Tableau, and the inflexibility they have. We're a consulting house, and mostly use Qlik. We started using Tableau last year.
The problem for us is that as a consulting house, our staff turnover rate is high (as expected I suppose), and this doesn't work well with Tableau's named license model. We've run into troubles where we reassigned licenses after people either left projects using Tableau, or left our company altogether. They ended up forcing us to buy extra licenses, which I was unhappy with.
My stance since then has been to avoid buying more licenses. We're getting our team skilled up more on web-based viz, so we can reduce our dependence on desktop applications.
A recent client of mine dealt with this by buying dedicated laptops to run Tableau on, when you needed to use it you just tracked down one of them. Seems like there should be a rule of thumb around this--software licenses should not be so expensive or inflexible that it's cheaper to buy a dedicated $1000 piece of shareable hardware than to get one for each user.
Interesting approach! How practical is it though? I can export a tbwx or whatever the extension is, so that those who need the dashboards can use Tableau Reader. I'm however wondering if such model would work for us.
The one thing that I like about Tableau is that its documents are XML, which plays nice with git.
It seemed to work reasonably well since the typical user was only needing it an hour or two each week. All of those users needed some authoring ability so Reader wasn't a solution in this case.
Extracts are binary yes. If you're using a workbook without extracts embedded, you're working with an XML file. We do that most of the time. We only embed extracts when someone with a Tableau Reader license needs to use a dashboard. We normally keep those out of source control.
Would you consider building the visualisations yourself with something like R and Shiny? Self host the server, develop in-house, no more Tableau like problems.
I was working on a project where the client wanted to use Tableau and I pushed instead for Shiny, which is the way we went. Quite happy with the decision.
It mostly depends on client needs. We had one project where I was thinking of going d3.js and wrap it around an Electron app. Our investment in R is still not at the level I'd want, we're mostly a SAS house ...
Most of our clients are tier 1, so in some instances they already have heavy investment in Qlik, but some are willing to shell out cash for Tableau where it makes sense. I've seen senior management in clients complain about the price though at times.
> My stance since then has been to avoid buying more licenses. We're getting our team skilled up more on web-based viz, so we can reduce our dependence on desktop applications.
Anecdotal, but I've seen this happen several times with clients who previously used Tableau.
It's a bit ridiculous. We get global discounts, but even then we still end up concluding that it's expensive. We only have desktop and online licenses, server licenses are rooftop crazy.
My last gig paid high five figures for a server license, and after a year of trying to get it to work as wanted, we threw it out and wrote our own in-house web solution with open source tools.
The problem for us is that as a consulting house, our staff turnover rate is high (as expected I suppose), and this doesn't work well with Tableau's named license model. We've run into troubles where we reassigned licenses after people either left projects using Tableau, or left our company altogether. They ended up forcing us to buy extra licenses, which I was unhappy with.
My stance since then has been to avoid buying more licenses. We're getting our team skilled up more on web-based viz, so we can reduce our dependence on desktop applications.