The work we are doing on Saxon-CE (XSLT 2.0 on the browser) received a very encouraging reception at XML Prague. Our half-day tutorial/workshop was very well attended, and there was a lot of useful feedback, and new ideas which we are hoping to incorporate. Discussions in the corridors of the conference also demonstrated a lot of interest. If you're not familiar with the current status, it's now on beta release, and we've been doing a lot of work that can be summed up as taking it from the prototype we showed last year to an industrial-strength product with stable interfaces, a range of development and debugging and instrumentation tools, responsive performance, and full cross-browser compatibility.
There are a few technical things we need to do before the product is finished. Providing a Javascript API is one; another is to provide control over management of the browser URL bar and history, so that users can save bookmarks and use the back button in the way that they expect; and we need to enable asynchronous fetching of XML documents from the server to create AJAX-style applications (since the J stands for Javascript, perhaps we should call it AXAX).
We're also starting to plan the commercial side of shipping a product. That includes pricing, the logistics of licensing and selling, and some basic marketing. We're not going to give the product away: there are too many good software products that have stalled because the value delivered to users wasn't flowing back to the developers to invest in the product. At the same time, giving software away free, within limits, is by far the best way of establishing a presence in the market.
Let me share my current thinking on pricing. I'm interested in feedback, so let me know what you think: these are just current ideas, so it might turn out quite different.
Firstly, the software will be licensed by domain (the name of the web domain on which it is deployed). We've already got that mechanism in place in the beta. We're hoping it's simple, clear, and hassle-free. We're not charging per developer, because that would be complicated and because the cost isn't directly related to the value; and we're not charging per end-user or per access, because that would be madness. Perhaps for people who want to deploy on multiple domains - the IBMs of this world - we will offer some kind of discount for domains after the first.
Secondly, we'll classify users into two groups: small and large. (Not "commercial" and "non-commercial" - that leaves far too many questions of definition). A small user is an individual or company or organization with revenue less than $x per annum (let's say $1m for the sake of argument), and a big user is anyone else. The entity whose revenue matters is the legal owner of the domain for which the license is held, which is nice because we can look that up; in many cases we can also check the revenue from public information, so there's not too much room for cheating.
Finally, we'll give you a choice of getting a one-year license or a permanent license. A one-year license will switch off at the end of the year. We hope that's a painful enough prospect that people who are taking the software seriously will choose to pay for a permanent license, while leaving a low-cost option for those who aren't quite sure yet how much commitment they want to make.
So that gives four prices, looking something like this (in GBP):
| Price | 12-month | Permanent |
|---|---|---|
| Small organization | free | 500 |
| Large organization | 500 | 2500 |
How do we tell if we have got this right? The prices look high by some standards, low by others. I think the test whether the price is in the right ballpark is that it is (a) less than the value users are getting from the software, and (b) greater than the money we are spending on developing it. On those criteria, it looks good to me, but I welcome your views!