Problematic Models

 
 
By Charles Garry  |  Posted 2005-07-25 Email Print this article Print
 
 
 
 
 
 
 


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. Click here to read more insight about Oracles multicore licensing policy from columnist John Pallatto. 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. Check out eWEEK.coms for the latest database news, reviews and analysis.


 
 
 
 
 
 
 
 
 
 
 

Submit a Comment

Loading Comments...
 
Manage your Newsletters: Login   Register My Newsletters























 
 
 
 
 
 
 
 
 
 
 
Thanks for your registration, follow us on our social networks to keep up-to-date
Rocket Fuel