The Old Joel on Software Forum: Part 4 (of 5) - Pricing server-side libraries?

Pricing server-side libraries?

I'm hoping that the JOS community will lead me out of my current quagmire: trying to fairly but effectively put a pricing model on a new product we're rolling out soon.

The product is a typically server-side library that would be used by in-house developers and consulting shops as a utility component in their own applications. We're playing in that fertile ground where prices range between $1K and $2.5K (mostly to stay below thresholds of purchasing bureaucracy at larger companies).

The trick is deciding on a licensing metric. Here are the ones I can think of off the top of my head:

- by number of users: not really feasible, this is just a library, not a service
- by number of CPU's: meaningless in a world where a single-processor SPARC can smoke a dual P4.
- per application
- according to team size (i.e. $1K for less than 5 developers, $1.5K for less than 20, $2.5K for less than 50, etc): that seems like a nightmare, especially as teams change size, sometimes rapidly.
- per server (akin to your mention of per-domain): *really* tough, especially in the case of hosting companies and ASPs

We're not trying to come up with a standard metric for use with customers who want to redistribute the library as part of their own product -- such OEMs would need to come to a special distribution arrangement with us separately.

So, give me your thoughts. Let me know what you think of the above metrics, and if you have others, feel free to share.

Oooga-Booga
Friday, May 7, 2004

The few libraries I have purchased have all been priced based on developer licenses with only paying the delta when then team size grows. In addition they have no distrubution fees. This model works great for low cost (< $5000) libraries.

Friday, May 7, 2004

+1 on per-developer licenses. This has the advantage that it's dirt simple for the customer to figure out what their licensing requrement is. It may take a while to figure out how many machines they need, and the number changes all the time. But it's really easy to do a headcount.

Just make sure it's really "per developer" and not "per developer machine". Nothing annoys me (or is broken) more than a license that lets me install the library on only one computer. I have four different computers at my desk right now!

Chris Tavares
Friday, May 7, 2004

Another ++ on per-developer. We develop and sell development tools, and customers are always very pleased when they find out that we license per-developer, not per-machine. They almost always make a comment like "finally, someone with logical licensing."

Of course, on the downside, you have to trust the customer to be giving you an honest headcount. Since it's not really plausible to do any technological check that your user is the one who is licensed, there is an element of the honor system to this kind of scheme.

--

Also, depending on the type of library you're creating, you might license by usage. Some server software limits itself to 5 concurrent connections or 15 current connections or 100, etc.... Perhaps this form of licensing would suit you and your customers.

Ultimately, I would ask the customers. Talk to the people to whom you intend to sell this and see what they think. They will tell what they will pay for and how they will pay for it, and you don't have to guess any more.

JT
Friday, May 7, 2004

Well, it's not a particularly large sample, but 3/3 for per-developer licensing is a start of a strong endorsement. My main question would be, at what level do we require licenses? Everyone on a particular team? Only those developers that write code that call the library? All developers in a department, or the whole company?

I suppose that's where the honor system takes over, but depending on what scale we license at, a single license would need to be either in the low $100's (if a whole dev team needs to be licensed, regardless of who touches the library's interface), or in the $1.5K area (if only those who interact with the library need to be licensed). I would think the latter is preferable, as it positions the product properly.

This makes me wonder if split development/deployment licenses are worthwhile. (i.e. $x per developer, $x*5 to deploy)

Oooga-Booga
Friday, May 7, 2004

Charge only those developers who will be using the library, not those who happen to have it included on a machine because they checked out the code base. I don't like your 5*for deployment idea, why else are they going to buy it if not for deployment? Just price it where it needs to be knowing that most people will only buy once license.

Friday, May 7, 2004

I think the per-developer model works well here.

Also, I wouldn't worry too much about the honour system aspects. As you will be dealing with serious businesses (>$1,000 a pop), you should be safe from unscrupulous people who say they'll use it and not pay.

That's not to say you won't have a few cases where they pay for one copy and use it for two developers, but you should be able to live with that.

In my experience of working for various UK clients (some of which are globabl companies), they are concerned to get the licensing right and will actually be pro-active in paying you.

Steve Jones (UK)
Saturday, May 8, 2004

As an ISV or OEM, we didn't mind development (e.g. per-developer) licenses, but we avoided any run-time (e.g. per user) licenses.

Christopher Wells
Saturday, May 8, 2004