CodeFutures News & Industry Commentary Blog

Tuesday, September 27, 2005

Enterprise Software Product Pricing

We've worked very hard at CodeFutures to make our product pricing transparent, open and fair, predictable and stable, justifiable, technically workable, and of course, economic.

I wonder how many vendors can claim that?

For example, you can immediately exclude any vendor that does not publish its product pricing. Not publishing product pricing immediately raises many doubts about whatever price is quoted by a software vendor.

Transparent Pricing

Software product pricing must be meaningful and understandable by customers. The pricing mechanism must be related in some way to the software is used. That's one of the reasons that, for example, an annual subscription per user works really well. You can simply determine if it is really worth that much per year for each user. CodeFutures' Premium Support, which includes all product upgrades, is essentially an annual subscription.

It may seem obvious that pricing should be readily understandable for customers. In fact, it should be so simple that customers understand your pricing in a few seconds.

For a developer tool, transparent pricing almost certainly means pricing per developer, rather than per installation. That's fairer because developers often have multiple development machines. But it's also transparent because it's clear to the end user what the license fees are - no hidden costs.

Open and Fair Pricing:

Product pricing should be published and clear. Why do software vendors hide their product prices? Do you charge widely different prices to different customer based on their ability to pay?

Fair pricing means avoiding unfair discrimination between different classes of customer and usage. For example, a lot of US software vendors charge higher prices in Europe for no particular reason other than they feel they can get away with it. Also, there's many examples of different prices for different categories of customer - with higher prices for industries such as banking.

Predictable and Stable Pricing

Customers can predict how much the FireStorm/DAO and Premium Support is going to cost - there are no hidden charges. One of the worst practices in the software industry is to offer very low entry fees but then charge increasing support fees in later years once the software is installed. There's a few software vendors in that seem to have an acquisition policy based on buying other software vendors with a large installed based of software that's difficult or inconvenient to remove, and then start to squeeze the customers by increasing the price of ongoing support. New product releases and the innovation that won the customer base in the first place is long forgotten.

Another unfair practice is to change pricing models for existing customers. The introduction of dual core processors, for example, is prompting some software vendors to suggest that they should charge more (or even twice as much) per CPU because the CPU is better architected (really! this is despite the fact that CPUs doubled in power every 18 months for the past 20 or so years). That would mean that an existing customer that migrated to a new hardware platform might be punished with higher support fees.

Justifiable Pricing

It's often difficult to see why two similar software products have vastly different prices. But it happens all the time with software: OpenOffice versus Microsoft Office, JBoss versus WebLogic, MySQL versus Oracle.

When it comes to enterprises using software, price is only one of many factors. That's why commercial products can exist beside very similar free alternatives. For an enterprise looking at an open source product 'vendor', it's necessary to understand and have faith in the business model that involves giving away the primary asset.

So how does CodeFutures justify the price of its DAO generator? We've provided a DAO benefits Web page that anyone can access that explains how the product cuts development costs.

Technically Workable Pricing

From the software vendor's point of view, the product pricing mechanism must be technically feasible and efficient to administer. This partly relates back to the requirement to make the product pricing as simple as possible.

Economic Pricing

There are several business models for selling software. The traditional model is up front license fees, with ongoing support if it’s a product used in enterprises. The product price must be able to support a reasonable return for the software vendor. If market forces, such as open source competitors, force the prices down, it might no longer be economic to sell the software. One of the best examples, perhaps, in the Java space, is what Eclipse has done the Java IDE market. You can imagine the pain felt by Borland, etc.

The IBM business and pricing model is gaining traction with independent software vendors - sell a solution - solve the customer problem - using a combination of packaged software and professional services. What is nice about this pricing model is that it does deliver results for the customer.

Subscription Pricing

The future of the software industry seems to be in subscription pricing. It should eliminate a lot of the worst sales practices in the industry that develop due to the sales incentives around large up front payments - customer pay for what they use, vendors need to keep their customers happy to keep the subscription revenue flowing. It means that the sales team is focussed on long term customer satisfaction and it means that software vendors have a steady revenue stream. Customers benefit because the focus is keeping the customer base happy rather than chasing new revenue.

PJ Murray
CodeFutures Software


Tuesday, September 20, 2005

Java Boutique: FireStorm/DAO Product Review

Java Boutique has published a FireStorm/DAO product review:

http://javaboutique.internet.com/tutorials/codefutures/

Java Boutique is a great resource for good quality articles on Java topics, so we're very happy a product review has been published.

PJ Murray
CodeFutures Software


Thursday, September 15, 2005

EJB 3.0 Persistence: A question of when rather than if

We're starting to get some questions about adding support for new EJB 3.0 Persistence specification. The response is yes, of course we're going to support the new specification. Without doubt, when the specification is approved, it will be a very big event in the Java community. The specification is expected to be finalized in the first quarter of 2006.

So the next next question is: when should the EJB 3.0 Persistence feature be added to FireStorm/DAO?

For CodeFutures, its a question of appropriate timing. Do we go ahead with implementing the current draft of the specification when it will probably change (and improve) over the next few months?

What added benefit is there in providing an early implementation of the specification?

There's already other Java product vendors building technology previews. Oracle, for example, is doing excellent work (but seems to be suggesting that developers use the technology previews of an incomplete specification in real projects?).

So the CodeFutures plan is to start implementing the specification once it is solidified. Then release a GA product based on the specification after it is approved by the JCP.

Will CodeFutures be recommending using EJB 3.0 Persistence in real projects? That remains to be determined.

The issue is that it's a new specification based on input from multiple, divergent sources where compromises must be made. It's very rare to get all the details right in the first version of a specification. In fact, it would possibly be a unique achievement.

So CodeFutures may end up recommending that customers developing important enterprise applications should wait for EJB 3.1 Persistence.

Iif you've got spare time, certainly experiment with the EJB 3.0 previews.

CodeFutures would appreciate any comments, good, bad, and ugly, you have on EJB 3.0 Persistence.

In the meantime, we're looking at Service Data Objects as the next generation for Java persistence.

PJ Murray
CodeFutures Software