Tag Archives: open source

Nine software pricing models evaluated

Pricing software has always been an interesting exercise. The marginal cost to copy and provide software is virtually zero. However, the cost to develop it—and the value of the intellectual property that goes into its creation—is far greater. These two tensions have created a range of models that vendors use to price software. This post evaluates several of these, highlighting ideal (and non-ideal) markets for each.

1. Open Source (or “Software should be free.”) There are many proponents of this – based both on economic philosophy as well as the concept of social production. However, free software does not work – at least for anything that is important to the enterprise. It creates no economic incentives for someone to support you (through documentation, bug fixing, advice, etc.) I do not see this becoming a winning model (unless we fundamentally change our world economy to something from the UFP or Animal Farm).

2. Price per CPU, server, CPU cycle, etc. This model creates interesting incentives: the less scalable your software is, the more CPUs your customers need, the more they pay. As such, it only works in a few places. For utility applications (e.g., web servers, database servers) it is fine, as it encourages vendors to compete to provide the best performing utility. For enterprise applications it is terrible, as it rewards poor performing software.

3. Pricing per unit time. I know—this is from the Main Frame Age. However, it is coming back in some cloud computing circles. Just like pricing per CPU it only makes sense for utility applications. It does not for enterprise applications.

4. Pricing per end user. This model makes sense in the consumer market, as each person who uses the software pays for it. However, it is less suitable in the enterprise market. Many enterprises employ multiple people to work, from different roles, on the same process. As a result, this model requires them to pay more to perform the function they need (ultimately making the software less valuable to them).

5. Pricing based on type of use, i.e., pricing someone who is a service provider different than an end user. I have seen this model used on occasion in the utility space, where I pay more if I using my database to build services I sell to others vs. services I use myself. Whenever, a vendor presents me with this model, I immediately look elsewhere. If you want me to buy and use your product, let me do so. If you want to treat me as a value-added reseller, incentivise me (instead of penalising me).

6. “New car style” pricing. Yes, I made this term up. It is a term I use for software provides who use very complicate pricing (pricing where the sales representative has to use a web portal or spread sheet to figure out my price). This is as bad of an experience as buying a new car (and very hard to scale from sales force perspective). Keep it simple: it will make it easier for your customers to see your value.

7. Pricing based on value created. This is also an interesting model, where the vendor prices based on how much value it provides. Economically, this provides the potentially for the most economic efficiency. However, value can be very hard to measure – especially between two or more parties. Structurally, this looks more like a value chain partnership than a simple sale. However, a software provider occasionally makes this work; when they do, I applaud it.

8. Utility pricing, i.e., pricing based on consumption. This sounds like SaaS (software-as-a-service) but it is not, it is pricing based on unit of consumption. This is ideal in situations where customers can provide a value on each transaction (i.e., it is great for PayPal but terrible for Microsoft Word). It is similar to pricing on value, but prices on the process input (rather than the output) something that can be much clearer to measure.

9. Pricing as a tax. This model is not used much. It is basically pricing unlimited usage of software as a percentage of the enterprise’s revenue, operating budget or some other metric (e.g., headcount, payroll). The big challenge of this is picking the time interval for measurement and billing. However, it can make the value of your software much clearer for C-level decision-making.

You will notice I did not discuss the concept of on-premise vs. SaaS vs. hosting. I did this on purpose. These are delivery mechanisms, not pricing mechanisms. It is important to separate the two, as it allows customers to evaluate your software based on its value (i.e., price) and most effective means of delivery.

Authors Note: I am sure a missed many models. I encourage you to comment; not only on the above, but on items I may have missed. Thank you.

What I took away from the inaugural Open Government & Innovations (OGI) conference

In case you missed it…

Not only did President Obama create enormous momentum via the use of Social Media on his campaign; his third memorandum (i.e., Executive Order) called explicitly for the creation of greater transparency and openness in the execution of government. This catalyzed a whole series of actions driving the adoption of “all things 2.0,” most explicitly the appointment of the Federal Government’s first Chief Information, Technology and Performance Officers and creation of the Open Government Initiative

OGI was a celebration of… OGI

The Open Government & Innovations conference was a celebration that embraced the Open Government Initiative (think of it as Comic-Con or Rock Concert for Government 2.0 (Gov 2.0). This is not meant to be cynical. Eighteen months ago, few could imagine this conference having so much attention. Ten years ago, it would be unthinkable. Just check out #OGI on Twitter if you don’t believe me.

My new takeaways from OGI

All of the key players were there (a great job by 1105 Media), saying all the things we see in their conferences and presentations on Gov 2.0. I don’t need to re-blog this. You can check out the Agenda at http://www.opengovinnovations.com for more.

However a few items jumped out as new (at least to me). Here they are:

1. Effective openness in transparency is much easier than effective openness in collaboration

I am eager to see the use of Gov 2.0 practices (not just technology) to help solve the large problems that face our government today. This will not just require simple mash-up of technology by understanding of how to use Gov 2.0 to drive openness in natural modes of collaboration between government and its citizenry—without (what Dan Doney of ODNI called) “moving from the ‘Wisdom of Crowds’ to the ‘Madness of Mobs.’” Dan Munz of NAPA summed this up brilliantly, explaining that it is still the responsibility of government to government and that you cannot delegate leadership if you want to achieve effective open collaboration.

2. Some are equating Open Software with Free Software

Open software standards, APIs and even code bases drive innovation in ways any one group cannot imagine (look at Linux and the iTunes App Store). However, those very examples of Open Software have valid business models. Red Hat adds their own “secret sauce” of code and support to make Linux enterprise-ready – and charges for this. iTunes charges a bounty on paid content (and a larger cost – of consumers and its network partner – to enable its devices). Creating – and maintaining – enterprise-effective software comes at a cost. Like all content (e.g., art, music) it requires compensation to sustain. We will get what we pay for – especially when regulations do not allow the use of advertising to support (free) software services when used for official business.

3. Clouds can offer greater security… But who hosts them is key

For the first time, I heard many people describe how cloud computer can be more secure than on-premises computing (economies of scale security investment and laws of large numbers for reliability easily demonstrate why). However, I was also reminded by a very savvy agency CIO that it will be very hard to use external (i.e., open Internet) clouds for high priority and mission critical service areas AND remain regulatory compliant. It will be interesting how this affect the use of free, externally hosted Web 2.0 services to tackle mission-critical problems (let alone classified ones)

These were my takeaways not because they were the key messages (or even the loudest ones). They were my takeaways because they added subtle differences that are key to effective execution of openness and transparency. This execution (reinforced so often throughout OGI) is the responsibility of ALL of us (Government, Government Partners and Citizens).