Software Pricing
-
Software Pricing
Is the best way to change software licensing a move to memory-based pricing?. It's certainly an interesting idea and given all the virtualization and other solutions that can confuse the issue, this starts to potentially make sense.
Especially for us database people that really need memory on some systems and could run with less on others. I know that my 1GB servers that power small apps certainly don't make SQL Server the same value as the heavily used ones with > 4GB.
And just think about the possibilities of getting more installations for smaller systems if the entry cost is lower.
Memory pricing certainly makes some sense for virtual machines, where we'd pay for the allocation of memory to a particular server. This does get more complicated when you change your allocations, especially if we get to the point where we can do this dynamically in Windows.
I think Windows and SQL Server have a fairly straightforward licensing scheme. There have been a few cases where it doesn't make sense, but in the majority of places I've worked, it's been easy to figure out. This is probably more an issue for the *nix software vendors with their complicated CPU pricing schemes.
Still it's an interesting idea and I wonder if we'll see more of this type of creative licensing in the future.
Steve Jones
-
God help us... a licensing fee structure that requires a scientific calculator to compute!
Tim Mitchell, Microsoft Data Platform MVP
Data Warehouse and ETL Consultant
TimMitchell.net | @Tim_Mitchell | Tyleris.com
ETL Best Practices -
If I understood the edtiorial correctly, then this is a BAD idea. I have 4 instances on my SQL server, and I adjust memory between them (rarely) based on variances in demand. A licensing scenario based on memory allocation would mean that I would need to overestimate my licensing requirements to meet my customers' needs - and overcharge them in the process, probably losing business. A 4xCPU (x64) is expensive enough without adding to the equation variable licensing based on memory allocation.
My big beef with MS licensing for MSSQL is that they bundle "free" systems with the main product, but you have to pay full price all over again to deploy these systems to different servers - e.g., Reporting Services, which IMO NEVER belongs on my database server (and MS agrees - see the various security whitepapers), but since I paid full price for MSSQL EE, I really would LIKE to have the data driven subscription service for RS. Put it on another box and *voila* instant price gouging.
I've argued this point with MS directly, and there are solutions - buy MSSQL Standard and deploy RS with that license, then deploy RS with DDSubs on the MSSQL box for outbound use only. But this still robs precious memory from my SQL Server, and that nags at me.
I wish there was an easier model - maybe a discount on licensing the secondary products if a POP was provided for the primary. MS licensing - in general - is nasty and confusing. That said, it's better than many of its non-Open Source competitors.
-
I agree about the RS bit. Also how many apps out there already consume way more memory than they really need to. I could see some companies deciding that they would change coding practices to make thier apps consume even more so they coudl charge more for them...
-
Maybe you'd overestimate, but if you licensed by the GB, which I could see. Not sure it would be worth it to track smaller numbers, you could estimate how many GB each and pay that. If you needed to change that, and I'm assuming one would go up and one down, then no payment change. Plus if you needed to separate to different physical servers, no charge either.
Also, your RS issue would go away since you'd be paying on the GB, you could move it to another server. Not sure how they'd license the separate products, and maybe they'd be separate products, but it could work.
I'm not saying that I want them to do it, but it is an interesting idea. It could work out.
-
Primarily for the exponential notation capacity to represent the costs
...
-- FORTRAN manual for Xerox Computers --
Viewing 6 posts - 1 through 5 (of 5 total)
You must be logged in to reply to this topic. Login to reply