eWEEK content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
I love Oracles licensing policies. I truly do, because it provides me with income as a independent analyst.
Companies hire me to help them come up with strategies to take best advantage of Oracles seemingly convoluted licensing rules.
Now, Im not bragging here, but more often than not, I find millions in possible savings; the problem is that the customers learn the one truth they often dont want to hear.
Whatever situation they find themselves in with Oracle is typically their own fault.
Yes, folks, as much as we would all like to blame Oracle or any vendor really, its usually our own decisions, our own poor asset management process that costs our organization the really big dollars.
The big news last week was that Oracle supposedly caved in to market pressure concerning multicore processors.
The disconnect is that Oracle still believes in the concept that the power of the processor somehow impacts the value an organization receives from its database software.
Many users still remember when Oracle introduced the concept of power units.
With power units, Oracle calculated the number of processors multiplied by the speed of the processor (MHz) to come up with a pricing unit they called a power unit.
Furthermore, they calculated that a RISC processor should have a 50 percent upcharge over an Intel based processor.
Oracle was not exactly out on a limb here, because capacity-based pricing had been accepted practice for years.
The problem with power units, of course, is that each generation processor is faster, meaning customers had to keep buying additional power units from Oracle as they migrated to newer hardware, even if the actual number of processors stayed the same.
Needless to say, customers were not happy then, and Oracle had to abandon that model within a short time.
The 75 percent solution (each core equals 75 percent of a processor) is similar.
Consider the case today where you have licensed Oracle on a four-processor, dual-core server.
Under the old model, you would have to pay $40K multiplied by eight (eight cores) for a total of $320k.
Under the new model, you would pay $240K, a 25 percent discount.
Now lets say you migrate to a two-processor (five-core) server in two years.
Even though you have reduced the number of processors, you would have to pay Oracle $80k for the two additional cores, thereby eliminating any discount you received initially. Addition by subtraction, some might say.
Next Page: Problematic models.
Problematic Models
The problem, my friends, is not Oracle, but its software licensing models in general.
The only model people really like is open source, because its free to distribute, with nothing to count.
Even then, there are those who are suspicious that you get what you pay for.
Dont get me wrong; software vendors make the rules, and like a casino, they always write them in the houses favor.
The chief weapon is license complexity. For example, Oracle, like most commercial vendors, offers several editions of its database software.
The enterprise edition is the most expensive; standard editions on average are 69 percent cheaper per processor than the enterprise edition.
If that is true, why do you suppose most companies only license the enterprise edition?
Ill tell you why: because they dont want to fuss with having to manage the licenses themselves.
They dont want to worry about how many processors a server has before they allow the software to be installed.
They dont want to worry about someone using an option that is forbidden under the license agreement for the standard edition.
They dont want to gather requirements as to the specific features the applications, developers, or DBAs might want that are only available in the enterprise edition.
So they license only enterprise edition software.
They negotiate what they believe to be a superb deal and then forget about it for the next three years until its time to revisit the maintenance agreement.
The reality is that software license models all have weaknesses.
In my opinion, the concept of a license itself has past its useful lifespan.
Think about it. We “buy” a license, and then we pay an annual subscription to receive maintenance to fix problems in the code we already paid for.
We also fund new development for features we may never use.
Imagine if the automobile industry used the same model.
On a $31K vehicle, you would pay a $6,820 annual maintenance fee on that new car.
Even if that covered your gas, oil change, tire wear and washes, it would still make your car twice as expensive to drive as it is today.
The margins for the car companies would be over 200 percent. They could use that money to develop new cars that you may never want or be able to afford. Why would anyone but the vendor be interested in such a model?
The answer isnt a different licensing model, either.
Some say processor licenses are too expensive and hard to manage.
From my experience, the opposite is true. Consider that processor licenses allow for unlimited users.
This is a good thing because users are hard to keep track of, especially when a user may be a device, a batch program or a consultant.
I think processors are much easier to count. Secondly, user licenses dont have any restrictions as to the number of servers you install the software on.
Some may think this is a good thing, but in my experience it is a very, very bad thing.
Consider the case of a company that has 46,000 employees and signs an enterprise agreement with Oracle that includes a very significant discount on a per-user basis to purchase a license for every employee in the company.
Every year the company and Oracle will true up based on the employee count in the companys 10k filing (no refunds allowed).
The company feels it got a great deal, and everyone can now use Oracle as if it were essentially free to use anywhere they like! Nothing to count. Could it get any easier to manage than that?
The problem is that three years later, people did exactly what you would expect: They installed Oracle on over 500 servers.
The costs to manage all these servers if you just consider DBA and SysAdmin salaries (not fully loaded) was estimated to be over $10 million dollars annually—more than five times what they were paying Oracle in annual maintenance fees.
All of a sudden, your perception of the problem (reduce annual maintenance spend to Oracle) changes radically, does it not?
The idea of determining the value that database software delivers to an organization is an interesting problem, however.
Essentially, a database stores and retrieves information. What if vendors metered the I/Os on each database and charged you based on that?
What if they offered plans like wireless phone companies, wherein you could buy blocks of I/Os per month for a fee? Unlikely they would offer free nights and weekends, however.
How about a plan wherein you pay a fixed amount based on company revenue for the first year and then use the monitor logs of the actual I/O to set your rates for the next year?
My own recommendation is that we keep it very simple.
Sell one edition, charge a low per-server (regardless of size or type) fee to buy the software. Thats it.
Then vendors would sell support plans similar to MySQLs MySQL Network offering, where organizations can pick and choose from a menu of support levels that might range from access to a trouble ticket FAQ list to actual remote DBA support.
After all, its the service that a vendor provides after the sale that delivers the true value.
The beauty of this plan is that its easily customizable for the end user, and support fees are very high-margin items for vendors (85 percent margin for Oracle).
This plan also enables wider adoption of the relational database market, which is good for the entire market.
Perhaps then the relationship between vendor and customer will finally reach a point that both sides feel is fair and equitable.
Charles Garry is an independent industry analyst based in Simsbury, Conn. He is a former vice president with META Groups Technology Research Services. He can be reached at cegarry@yahoo.com.