Quality software is hard to write and easy to copy. That combination doesn’t seem to sit well with some people. They focus on the low recurring costs and conclude that the software is overpriced. I’ve even known people in the software industry to be similarly deluded from time to time.

Value Pricing says that customer cost should be proportional to customer value. A rational customer should be willing to pay X in order to receive a value greater than X. Microsoft Office Professional Edition 2003 is $421.99 at Amazon. If it saves you more than $421.99 in document preparation time or document exchange aggravation, then it is a prudent purchase.

The pricing problem lies in determining how much value a customer actually accrues from any given software package. If the pricing model is too simple, then you will be undercharging customers. And if it gets too complex; then no one will understand it and many will think that you’re trying to somehow trick them.

The conventional pricing solution is to license per user. It is easy to understand. And it matches what is usually the first order value effect - value proportional to the number of people using it.

If that isn’t good enough, then the next step is to introduce different classes of users. Power users get more value than normal users who get more value than occasional users. This handles the primary objection to user pricing - I’m not going to pay X for someone who uses the software twice a month.

Sometimes you cannot differentiate users by capability. In this case, you license by some alternate measure. For example, it is common for databases to be licensed by processor. Or you might license web site related software by the site, with pricing tiers based upon the size of the site.

Bear in mind that value pricing is just a start. It defines the upper bound of what you can charge. Your final pricing model should also reflect competitive factors and revenue optimization.

Just for the record:

1. I believe that if PayPerPost is successful, then the blogosphere will be diminished.
2. I believe that PayPerPost and its investors should be ashamed of themselves.
3. And unfortunately, I believe that the Genie is out of the Bottle - that there is money to be made and someone is going to do it.

I often think that the most durable legacy of the dot-com years is the belief that an idea, a web site, and a host of eyeballs can make you rich. I am constantly amazed by the ways people actually think they can make money - and how much money they actually make.

The downside of all this inventiveness is that any idea can and will be commercialized. Case in point, PayPerPost. Peter Wright would have us believe that [PayPerPost is] a marketplace - we put advertisers in touch with bloggers. And that their hands are clean - any deception in the process lies in the hands of the individual bloggers.

Jason Calcanis love[s] the transparency, authenticity, honesty, and passion found on blogs … [and feels] the need to defend it from the forces of evil, a.k.a. PayPerPost.

I’d like to feel some outrage. But I just can’t muster any up. As much as I hate to say it, it just seems like the next step in the commercialization of weblogs.

1. Take the First Step is barely commercial, it only advocates the brand of me.
2. Smalltalk Tidbits, Industry Rants is somewhat commercial, it advocates James Robertson with a strong splash of Cincom Smalltalk.
3. Engadget HD is primarily commercial. The authors may be writing about a topic they love, but the site only exists to make money.
4. PayPerPost is all about commerce. It acknowledges the success of Weblogs, Inc. and finds attempts a business model with more leverage.

PayPerPost may create an environment in which weblog malfeasance can flourish. But I’m a wee bit sceptical that there are enough unethical and successful bloggers for it to be a real issue.

9 October: The Genie is out of the Bottle

I was recently testing a Web Service that expected a unique key be passed with each invocation. I could have used the date/time or I could have persisted a counter in a database. Instead, I used the optional ant propertyfile task to persist a counter in a property file.

Here is a simple ant build file demonstrating how to increment a counter in a Java properties file. The propertyfile file attribute specifies the name of the property file and each nested entry element specifies how the value of a property file key should be modified. In this case, the value of the key “count” is treated as an int and the value 1 is added upon each invocation.

1
2
3
4
5
6
7

<project default="run">
  <target name="run">
    <propertyfile file="test.properties">
      <entry key="count" type="int" operation="+" value="1" />
    </propertyfile>
  </target>
</project>

Here is the build file in operation.

1

1 $ cat test.properties
count=100
2 $ ant run
Buildfile: build.xml

run:
[propertyfile] Updating property file: /Projects/Learn/Ant/propertyfile/test.properties

BUILD SUCCESSFUL
Total time: 0 seconds
3 $ cat test.properties 
#Sun Oct 01 14:11:06 EDT 2006
count=101

The propertyfile entry element also allows us to specify a default value.

1
2
3
4
5
6
7

<project default="run">
  <target name="run">
    <propertyfile file="test.properties">
      <entry key="count" default="10" type="int" operation="+" value="1" />
    </propertyfile>
  </target>
</project>

1

1 $ rm test.properties
2 $ ant run
Buildfile: build.xml

run:
[propertyfile] Creating new property file: /Projects/Learn/Ant/propertyfile/test.properties

BUILD SUCCESSFUL
Total time: 0 seconds
3 $ cat test.properties 
#Sun Oct 01 14:30:18 EDT 2006
count=11
4 $ ant run
Buildfile: build.xml

run:
[propertyfile] Updating property file: /Projects/Learn/Ant/propertyfile/test.properties

BUILD SUCCESSFUL
Total time: 0 seconds
5 $ cat test.properties 
#Sun Oct 01 14:37:12 EDT 2006
count=12

And finally, another test to show that any keys not explicitly specified are left alone.

1

1 $ cat test.properties 
#Sun Oct 01 14:37:12 EDT 2006
count=12
more=another value
andmore=yet another value
2 $ ant run
Buildfile: build.xml

run:
[propertyfile] Updating property file: /Projects/Learn/Ant/propertyfile/test.properties

BUILD SUCCESSFUL
Total time: 0 seconds
3 $ cat test.properties 
#Sun Oct 01 14:47:09 EDT 2006
andmore=yet another value
more=another value
count=13

18 Apr: More on the Ant PropertyFile task - eliminating the thousands separator with the pattern attribute.

Disclaimer: I don’t claim to be an expert on ant. Please send comments and corrections.

Fancy that - 749,749 page reads.

The good Jake was 15 of 30 for 256 yards in yesterday’s 17-7 victory over the New England Patriots. He had two touchdown passes to Javon Walker and most importantly no turnovers. This was a good win for the Broncos - the Patriots aren’t the same team that won 3 Super Bowls in a 4 year span, but they’re still in the NFL’s upper echelon.

In spite of their poor showing against the Rams and the Chiefs to start the season, the Broncos find themselves at 2-1. The defense finally gave up its first TD of the season with just over nine minutes left in the fourth quarter. The offense is starting to jell. And Shanahan has the bye week to make it all stick.

I’ll take it.

This week’s pm-clinic topic is thick vs. thin specs. The verdict seems to be that the spec should be as thick as is necessary but no thicker. Or depending upon your point of view, as thin as adequately describes the project.

Of course, it is important to remember that the specification is only the beginning. It only describes what the project is meant to be. It is up to the development team to bring the specification to life and determine what it will be.

Some projects only require a competent development team. And for this sort of project, a good specification means that you’re more than halfway home.

Other projects require more - competence will only deliver a project that satisfies the specification. It will get the job done, but it will be missing that extra something that makes software great.

This sort of project requires more from both the specification and the development team. The specification needs to establish and illuminate a unifying theme and the development team needs to reinforce that theme in every design decision it makes.