This is a repost from the old Advisory Board:
Hey Guys -
REALLY need your advice on this. I want to raise or change the pricing of deadline. i know, i know.
Problem #1: Cores. Our competitors are starting to charge per core, or per worker unit. We are unlimited cores. which means that a 1000 proc farm 5 years ago was 250-500 deadline nodes. now, that could be 30 deadline nodes. Our ‘high-end’ competitors are 1.5-2x our price at at low-cores, but 15-30x our price with many cores. Clearly we have to do something…
Options: A -we cap our cores for deadline at existing pricing, and release deadline ‘pro’ with more features, unlimited cores for a higher price. EG 8 or 16 cores in a node max in ‘deadline’ - deadline pro > greater than that.
B - we go with the pixar model, and charge per worker unit. so if you have 32 cores on one machine and want 32 jobs, you need 32 licenses. one job on 32 cores = 1 license. or some variation of node and threads.
C - we raise our price across the board, knowing that cores are cheaper.
Second problem - exchange rate is killing our margin. when we started selling software, the exchange rate was 25% in our favor, and is now 5% against us - thats a 30% change. Yikes!
SO
Normally, for the exchange rate, i would do a small price hike - say 5% to cover any problems and be done with it, but this many core issue is going to be a problem for us one day!
Thoughts? discussing? feedback? anyone feel scared of the pixar tractor model?
cb
April 26, 2011 | Thinkbox Software
Having recently bought some 48 core machines, I’ll vote C. AMD is crushing prices on CPU cores, but isn’t ramping up clock rates. Intel’s new Xeons do the same. It’s the way things will continue, I suspect. Didn’t Oracle move away from per-core pricing and based it instead on actual performance? Renderman is no longer per-core either, right? Point out the high cost of per-core licencing in your marketing. If they’re really 30x more you need to point out why.
Counter-arguements? If the application Deadline launches is priced this way, so that customers are expecting costs to escalate then you would be missing out. What applications fall onto this category, and how much do your clients run them? What about VMs? Per-core pricing would be more favorable to VMs where current ‘node’ pricing can be problematic. What about ‘retiring to the farm’? Per-core pricing favors older hardware being recycled in the farm.
I suppose the concern isn’t really about more cores but about fewer nodes in a farm. If I can set up an iray machine with 8 or 16 Fermi GPUs, would I need as large of a farm.
Regarding Tractor, if they keep the current pricing, they’re basically half the cost of Deadline? Guess you’re hoping they don’t add features quickly. Right now, for us, features are more important than cost. If you implement the features we want/need we would keep up with subscription even with higher prices.
April 26, 2011 | Chad Capeland
Mental Images moved away from per core licensing on their standalone MR, didn’t they?
I don’t think you will actually get that many people sign up for Deadline Pro…there aren’t many of these power users around?
Option C (not too much!) + subscription based pricing sounds like a good plan.
All Autodesk products are subscription based and on long-term software products it can ‘guarantee’ a steady income for software developers?
Looking at the bigger picture, what about when CPU cores reach a natural peak and GPU cores take over? Then it will be minimum number of CPU cores, but loads of GPU cores on 1 machine. Would the Deadline new pricing model have to be revised again?
A CPU core licensing system should consider GPU based cores moving forward?
How about cloud based solutions? Per core/machine/GPU core? Any cloud based system would need to follow suit to match the cost effectiveness of the new Deadline licensing system?
Perhaps partnering with one or more, cloud based providers and start looking at the potential of hosting Deadline in a cloud environment and how licensing could be affected by this type of architecture?
Mike
April 27, 2011 | Mike Owen
Upon further reflection, I think I see some value in option A. If you let both exist at the same time, and only deal Deadline licenses to the little machines and Deadline Pro to the big machines. When you buy a 64 core machine, you figure the extra cost in and you hardly notice. The problem with that… granularity. Lets say the cutoff is 8. Anyone with a 12 core machine is going to be either idling 4 cores or paying for a license that supports 128 cores. It’s not as efficient as per-core licenses for anyone at the bottom of one of the tiers. So people with 2 and 12 cores will pay the same as people with 8 and 48. If I was a competitor, I’d point that out.
Crazy talk time… What happens if you accept that computing power is more complex than machines / sockets / cores / threads / MHz / GPUs / PFGAs/ Amazon EC2 credits / whatever… Could you license based on concurrent jobs? active jobs? tasks? users? What’s the unit that is the real value in rendering / automation / dispatch that isn’t as varied as the machine configs?
Analogy with Krakatoa, if it gets faster and easier to use, it will REDUCE the need for Deadline and for Krakatoa rendering licenses. It went from something that sold Deadline to something that can run without Deadline at all. So how do you encourage Krakatoa to get better while still maintaining revenue?
April 27, 2011 | Chad Capeland
Hey Guys! we made a decision.
Thanks for all the feedback, and it helped that i got a better understanding of how deadline works with concurrent jobs - so here goes
I want to raise deadline to $185 for a new license and $45 for an upgrade [from 175 and 35 respectively] - the target percentage is 25-30% of the purchase price for subscription - which is less than NUKE and other products, for example, and that gets us closer at 24%. Unless you guys think we can justify a $50 upgrade fee!!? 
- Tractor [for example] and perhaps other competitors charge per task - so if you have one task on a 32 core machine that would be slightly more than half the price for deadline at $99
- Deadline currently allows for 16 concurrent tasks on one machine - so you could render 16 separate frames on one machine. That price is the same, or $185, vs $1600 for tractor.
- Say you want 16 concurrent mental ray renders on a 32 core machine, and 16 more concurrent tasks of vray. that would cost you $3200 in tractor, and with deadline that would require 2 slaves or $350 at current pricing.
- the problem comes into play if you want 32 separate tasks on your 32 core, that aren’t the same. eg 1 instance of mental ray, 1 instance of krakatoa, 1 instance of…etc etc. then tractor is 3200, and we are 5920. of course nodes are floating in both cases, but you get the idea
in instance 4 - this is where deadline ‘unlimited’ would come into play.; at v5.x [we think] we’ll release a version of deadline which would support unlimited instances of deadline slave on a machine, so you could have 32 different jobs rendering 16 concurrent tasks on each, or 64 or 128 or whatever. we could allow you to mix and match unlimited and regular deadline i THINK…but anyway, presuming that someone actually wants 32 DIFFERENT concurrent jobs on one machine, then this would allow us to release a product that would be cheaper than tractor or the competion - say 995$ for deadline unlimited.
anyway, those are my thoughts for today. feedback? we would release 5.0 with the price bump, not announce ‘deadline unlimited’ until we do some backend stuff, and then do that for a .x release in the future.
cb
April 27, 2011 | Thinkbox Software
In all the jobs we have ever submitted to Deadline (~circa probably something like 40,000 jobs per year x 3 years?), I think we have used more than 1 x concurrent processing about 2 or 3 times for some python custom plugin jobs, kind of thing. For us, our 3D Max/Maya scene files may need something on average like 2 to 4GB of RAM to open on a slave to render. As we don’t have 64GB of RAM on our nodes, we have never set concurrent processing to 16…!! Recently, VRay likes more RAM, so a heavy scene with not much optimizing can easily suck up 8-10GB RAM, so then we always default to 1 x concurrent processing. For us, this licensing schema wouldn’t work.
In terms of running different applications on each core in Chris’s point #4; the limiting factor here is actually all the other software and not Deadline! ie: We don’t own 100 rendernode licenses of application X or whatever!
How about limiting Deadline by functionality? Take out certain functionality for the basic package, but allow it in the PRO version? “Maya Unlimited” type of thing. Hold on a second, I snookered myself! Autodesk just got rid of this system and pushed subscription instead!
April 27, 2011 | Mike Owen
You mean subscription, not upgrade, right? Nuke’s list price difference for subscription is 22%, 3ds max’s is 14%, Fusion’s is 8%. I’d increase the the initial and upgrade prices more. I would suspect that people can easily absorb $60 extra for a new DL license when buying a $6000 machine. And you see immediate ROI when that machine is fired up and starts running DL tasks. We see subscription prices lumped all together at once, so you’re being asked to spend 50x or 200x or whatever the subscription cost, and the return is intangible. Maybe other people don’t see it that way, and prefer to defer the costs until next year? I like it when the subscription is cheap, but the upgrade is high, so you feel like you HAVE to stay with subscription to avoid paying a huge fee later.
If DLUL is $995 vs DL at $185? What’s the advantage? Why would you pay $810 more per machine just to be able to run >16 concurrent different tasks? When we have a task that isn’t multithreaded (which is only a small percentage of all tasks) we just send it to the machines with fewer cores. So we’d run 4 concurrent tasks on a 4 core machine. Still fine under a normal DL license. We could do this on 5 machines using 5 DL licenses and still be cheaper than DLUL. I must me missing something.
EDIT: What Mike said while I was typing this is right. I don’t know when the DLUL would come into play for MOST customers. But I can see where some plugins or enhanced submission scripts might be valuable. Hmmm…
April 27, 2011 | Chad Capeland
Chad/Mike
regarding concurrent tasks: I KNOW. however, we are getting people with 24, 32 cores - [and coming: 40 cores] that want to be able to run n tasks at the same time. somebody out there thinks that 10 40 core machines will perform as well as 100 4 core machines…of course they aren’t calculating the network IO and ram into the equation i assume. we just had this very discussion, which is why we set the price high - i figure that we’ll be ready if/when someone WANTS >16 concurrent tasks on one machine that differe, but if you never do- then the price doesnt change.
i only want to offer it to capture that part of the market that is doing something specific, and requires massive concurrent tasks. example: these guys approached us about the cost for a 1000 node farm. Competitor was $32k, we were 7kish. reason? it was 40x 24 core machines.
What did they client go with? Competitor. Why? i still scratch my head - but anyway, they felt that they needed to license all the cores i guess. We couldnt offer that, so we lost out. Maybe they are foolish, but looking at the Pixar model - someone is expecting that you are going to have concurrent tasks…
cb
April 27, 2011 | Thinkbox Software
Mike - further to your point
-
deadline would still work in your cases. get 32 procs, and as long as you have one task rendering on that machine: you’re good. so you would never buy Deadline Unlimited.
-
there are clients with 192 gig ram machines, 24 cores. they can do a bunch of concurrent jobs - if they started 6 slaves, that would essentially cost them 6* 185…seems pricier than 995 in that case? now - not sure how many clients are like that…but again -i’m thinking about the future, and establishing a model or pricing to deal with the upcoming procs. None of this is an issue if your copy of VRAY or whatever renders on 32 procs fine and scales awesomely of course!
Chad:
Okay - so what would you suggest pricing be? currently its 175/35 and 65 to upgrade. i was contemplating 185/45 and 70. Should we bump to 195, 40 and $75? or…are you suggesting keep the subscription price constant? eg 195/35 and 70?
cb
April 27, 2011 | Thinkbox Software
We’re obviously biased. We’re not shelling out $10K to switch to DL. We save the most money by having someone new pay for development and keep subscription really low. And we don’t know what you’re up against when bidding for new clients. I’ve got no idea why someone would go with $35K over $7K. Deadline isn’t expensive, so either it’s missing a key feature they needed, or they THOUGHT that it was.
Deadline is, and probably will be after the price increase, the cheapest part of what we do. Every other software costs us more per year per user. Heck, we pay 3x more on TIMESHEET software than we do on Deadline. And I think we pay more for health insurance than we do for our software per year. So for us it is and probably always will be a feature issue, not a cost issue.
For our Magny-Cours machines, the 48-core ones, we never considered doing concurrent tasks. We are setting up VM’s so we can carve out the machines exactly how we like. I wonder what approach is more efficient. Can DL (or DLUL) manage resources that well to do better than virtual machines? Actually… Could DLUL be made to actually manage VM’s?
April 27, 2011 | Chad Capeland
funny you should mention that…
we believe it can. frankly, i believe that deadline can manage 10,000 person companies and all of the data on their computers, their instances, their applications and everything else. it’s just a question of development time…deadline cloud is on the roadmap, and a big part of that is exactly what you want to do locally.
okay - back to deadline $$ - so what you are saying is we should keep the entry cost low to suck in more users, and charge 3x the initial cost for support and upgrades once people are hooked?
here is the bottom line: the greatest percentage of revenue comes from new users. good news is, sales continue to grow for deadline: we are taking over…even in this odd marketplace. bad news: new users aren’t unlimited and i have no clue how much of the market we actually have and how many more years of growth we can sustain - thus, i have to ensure that our current users dig our product, and that we continue to evolve it FOR THEM. the better news - we have clients like you and mike that have a lot of requests, and i have a lot of outlandish ideas, and between them and Ryan’s kick-assness…we have the ability to keep doing things that make you happy.
Thing is, in order to keep making you happy - we have to charge enough for support to keep you involved without charging so much that it starts to turn you away. think of it this way: if the majority of dev revenue for deadline is from new markets and thus we keep focusing on ‘new’ clients and markets - then eventually we are going to add a bunch of features none of you key users care about.
SO. i think i have to do the opposite of other companies who are adding features for line-items that do 10% of what you need them to do, and therefore we need to keep adding dev resources into the detailed areas you guys [and other clients, hopefully] want to see. two things will hurt that - new users buying something else, and us not charging enough for support.
THUS: how much can we raise our support contract to keep guys like you happy? knowing that money is going to go directly to support and development in the product - and faster release schedules etc etc.
UPDATE: per your ‘why would someone else buy a competing product’ only thing i can think of: there are folks who still believe deadline can’t scale, despite my own experience to the contrary and the clients we have with 5x more nodes than they were buying. sheesh. its so hard to get over early problems.
cb
April 27, 2011 | Thinkbox Software
Bounties?
April 27, 2011 | Chad Capeland
yeah - slay the dragon, get a seat of Deadline!
cb
April 27, 2011 | Thinkbox Software
Where’s the setting for concurrent jobs? All I see is concurrent tasks.
May 3, 2011 | Chad Capeland
thats a -to-come- feature
currently its 16 max concurrent tasks, and we have 2 different approaches that we are working on for concurrent jobs [or more!?]
cb
May 26, 2011 | Thinkbox Software
edit remove
As we were talking about it (and looking for the concurrent jobs option in vain), we came to the conclusion that maybe it would be silly to run 16 concurrent brazil renders or even 2 krakatoa renders (with 2.0), but it might be REALLY nice to run a second job that is really low intensity, like tile assembly, or low priority, like an FFMpeg job. These second jobs could fill in the wasted cycles while the primary jobs are doing I/O or whatnot.
So for us, thinking in those terms makes more sense than thinking about the larger job counts.
May 26, 2011 | Chad Capeland
Chad - I really like the idea of being able to push multiple jobs of different “intensities” through a slave at the same time, by using potentially wasted CPU cycles. However, this would need a way to easily identify “lightweight” jobs from “heavy” jobs and 2 jobs of the same type should never meet! Of course, as I said earlier, the limiting factor would actually be for studios which only own X number of a certain piece of software, which essentially that particular piece of software isn’t licensed by host but by processor or whatever. So, in my head, I’m thinking something like Nuke render jobs generally don’t go much faster if you give it more than 1 or 2 concurrent tasks (i/o tends to be the limiting factor here) and they only use all the processing power IF they need it. So, a 2nd (or maybe even 3rd!!??) type of Deadline job could be pushed through this slave at the same time, like for example, tile assembler or any other type of job which has been “identified” as OK for “concurrent jobs”.
May 27, 2011 | Mike Owen