I've been thinking for a while about some repackaging for Saxon, and I've now got to the point where I'm working out the fine detail and creating appropriate build files.
The main idea is that instead of two products, Saxon-B and Saxon-SA, there will in future be three: Home Edition (HE), Professional Edition (PE), and Enterprise Edition (EE).
At the top end, EE is just a rebranding of SA, to reflect the fact that the commercial Saxon product is now differentiated by a lot more than schema awareness. For example, many people are using it for the streaming capabilities. The -SA suffix causes confusion because people imagine that you have to use a schema to use Saxon-SA.
The introduction of the Professional Edition (PE) is an attempt to tackle the problem that an awful lot of people are currently getting a free ride, using Saxon for mission-critical production work and contributing nothing in return. There's a lot to be said for open source and free software, but unless there is some way of getting revenue to fund investment from the people who get value from it, investment in the technology starts to suffer, as does support. The revenue from Saxon-SA users has cross-subsidised the whole operation quite successfully until now, but the product is getting ever bigger and more complex and it's not clear that the current business model scales to meet the growing requirements of the user community. So the aim is to produce a very low-cost (but not zero-cost) version of the product that will be attractive to the bulk of commercial users.
Of course the main reason people are reluctant to spend money is that the free version is good enough to meet their needs, and this means we need to make HE a bit less attractive to this community than Saxon-B is currently (but without alienating the open source community who provide so much value, collectively, by creating public awareness). This is a delicate tightrope to walk. For some time now I've been making new features available only in Saxon-SA; increasingly "minor" features will show up first in PE. The main carrot that I'm hoping will tempt people to take PE, however, will be convenience. For example, some of the optional features of the product will be available to HE users only in the form of source code, whereas they will be fully packaged in Saxon-PE. I'm also thinking that bug fixes might be available to HE users only in source form, while PE and EE users will get them packaged as a maintenance release.
Another benefit of the repackaging is that it "cleans up" the open source product. Because of the long history, there are components such as the SQL module where it is not always possible to trace all the contributors (and certainly, where there are no formal signed handovers from those contributors clearing the code for use). This has caused problems for some integrators wanting to integrate the source into their own offerings. Many of these contributions are in non-core modules which can be isolated so that those who care about these things get a "cleaner" source distribution, in terms of having known and traceable provenance. (Using this kind of code in a commercial product is far less of a problem, because Saxonica in effect indemnifies the end user.)
There are lots of risks associated with this strategy - one of them being that users will simply stick with Saxon 9.1. Well, actually, that's not really a risk - it's not a problem to Saxonica if they do, and the fact that they can do so will deflect some of the inevitable grumbling. Over time, I think we should be able to get to the position where those who have a good reason for not spending any money can get most of what they need without doing so, but those who are deriving real commercial benefits from the software contribute something to its ongoing development, and if we can get to that position then I think everyone will be better off.
|
|
||||||||
Repackaging Saxon
Comments
Re: Repackaging Saxon
by
Dave Pawson
on Wed 06 May 2009 15:29 BST | Profile | Permanent Link
When will you post the prices Mike?
Will they be payable annually (my big gripe with SA) as before or ... something else? Re: Re: Repackaging Saxon
I'll announce the prices when I've decided them. Depends a bit how the exchange rate moves over the next few weeks.
What would you prefer to the annual pricing model? I could switch to a more conventional "Pay for major releases not for minor releases" model - though it's awkward to change the model because of the need to honour existing license keys. Re: Re: Re: Repackaging Saxon
by
JamesC
on Wed 06 May 2009 16:08 BST | Profile | Permanent Link
I suppose it depends on the conditions and frequencies of those major releases. Do they happen about annually?
I like the major/minor model... similar to oXygen. I'd also be tempted to suggest that you offer free (on registration) Professional Edition licenses to certified academic institutions. This being a loss leader, as they train those who go work in companies which then buy the enterprise edition. Either that, or the use they make of it is so minor that they could easily replace it with something else and it benefits Saxon to be used in more places than not. -JamesC Re: Re: Re: Re: Repackaging Saxon
Thanks for the comments. Major releases have been getting less frequent - currently 8-10 months on recent form.
I take the point that we should have a firm policy on academic licenses. We've tended to make concessions on a fairly ad-hoc basis: we give discounts for teaching and for XML-related research, but not for university admin or publishing, and for research we like to know what kind of funding the project has - if there are defence mega-bucks behind it, we feel we deserve our share. Re: Re: Re: Re: Re: Repackaging Saxon
by
JamesC
on Wed 06 May 2009 21:16 BST | Profile | Permanent Link
I suppose that makes sense. I was thinking about it with a TEI hat on, and academic use of it in that context (member-supported consortium, no defence mega-bucks here! Sadly!) It might also allow certain organizations a discount as member benefit upon negotiation thereof? (e.g. TEI Members get a 20% discount on academic licenses for oXygen.) Yeah, there should be a clear cut academic policy, but I take the point that admin/publishing at a university is a complete different budget from teaching, XML-related research, or similar projects. (Frankly most projects I've advised would do fine with the Home Edition I think.)
Currently SA is bundled with certain versions of oXygen isn't it? Will they get the Professional Edition or the Enterprise Edition? Or will that bundle stop? See, I'm confused already. ;-) Nothing new I guess. -JamesC Re: Re: Re: Re: Re: Re: Repackaging Saxon
Anyone who has a license to use or redistribute Saxon-SA will typically find that the small print gives them the same rights for any successor product: Renaming the product does not affect anyone's rights. From that point of view, Saxon-EE will be just like another release of Saxon-SA.
Re: Repackaging Saxon
by
Andrzej
on Wed 06 May 2009 16:43 BST | Profile | Permanent Link
Why not consider online donations to support the free version? Post a link and blog entry and see if you get a sufficient response rate/$s to fund the free version?
Might be worth a try as it would be easier, faster and might sidestep the risks attached with a more stratified (dare I say, Microsoft-style) approach to Saxon. You post such a donation link and I'll be one of the first to contribute to the cause! Re: Re: Repackaging Saxon
There's been a donation link on http://saxon.sf.net/ for many years, and only two donations have been received. And I don't emphasise it more because I don't think I'm running a charity. The idea of "choose your own price, but it can't be zero" has some attractions, however - software has very different value to different people.
Re: Re: Re: Repackaging Saxon
by
Andrzej
on Wed 06 May 2009 18:08 BST | Profile | Permanent Link
I went to the page you suggested but was not able to find a donations link anywhere there. Same for the blog page and the saxonica.com page.
Maybe that is why you are not receiving any donations? There's no link and if there is, it's not prominent enough (at least I couldn't find it)! Re: Re: Re: Re: Repackaging Saxon
by
Christopher Sahnwaldt
on Wed 06 May 2009 20:43 BST | Profile | Permanent Link
The first link on http://saxon.sourceforge.net leads to the project page for Saxon http://sourceforge.net/projects/saxon which has a 'Donate' link in the top left corner.
Re: Re: Re: Re: Re: Repackaging Saxon
by
Andrzej
on Wed 06 May 2009 20:58 BST | Profile | Permanent Link
No wonder I couldn't find it. And thus not surprising that there hasn't been any appreciable quantity of donations!
If it was a bit more prominently shown for the free version, it might have more effect. Re: Repackaging Saxon
I suspect that providing packaging only for $$ (or pounds or euros) won't actually work, because someone else will step in and provide that packaging for free, as the licensing permits.
Re: Re: Repackaging Saxon
This will be interesting to see. I'm relying partly on the idea that there's a fair degree of trust, and expectation of support, associated with Saxonica's reputation, and that the people who are risking their business on the product might be hesitant to rely on third parties, who won't necessarily be prompt in issuing maintenance releases etc; at the same time, such third parties may serve the needs of the hobbyists who are the real market for the open source version.
Re: Repackaging Saxon
The decision to ask to pay for Saxon in some way corresponds with sun's blogs entries regarding free software (see http://blogs.sun.com/jonathan/date/20090302).
They, however, argue for a free software. I know that: saxon is really great software; and one cannot compare sun and saxoninca; and I'm not very profound in business side of development; Nevertheless I'd like to point to the idea that sun suggests: to get profit from services around software; In your case I can think of your great books, which among other things are based on saxon existence, and payable support. Re: Re: Repackaging Saxon
Thanks for the comment. I can't comment on Sun's business model (which presumably might now change!), but I haven't been able to make a model based on paid services plus free software work for me. It's hard enough to get the services business; when you do get it, it's hard to get enough revenue from it to fund the time spent on developing and supporting the software. Personally, I think the culture of free software has gone too far, and it is now leading to a lack of investment in new software, as witness Intel's withdrawal from the market for generic XML processing software.
Re: Re: Re: Repackaging Saxon
by
Cowtowncoder
on Thu 07 May 2009 18:01 BST | Profile | Permanent Link
First of all: I really hope this works out for Saxonica -- I am well aware of challenges, but hope they can be resolved.
Such change(s) might make it easier to sell Saxon; I hope I can convince people I work with to fork out cash (so far have been unsuccesful). Wrt Intel exitting: I would have mixed feelings if it was due to free components (since I might be guilty to some small degree :) ), but I suspect much of it has to do with both xml processing tools becoming commodity, and tendency of commercial vendors to basically lie regarding performance boost one would get. Actually, same goes for many free software authors -- not Michael btw, never seen a false claim here, which is noteworthy and lends a lot to credibility of Saxon in my opinion. There are way too many snake oil salesmen, and too many sheep to fleece. From what I have seen, Intel has not been shy at making outrageous claims. But maybe it is understandable given prevalence of this practice within industry; and lack of freely available objective performance test results. You can't really test Intel's products in this field, even if you want to. And this tendency to exaggerate benefits is problematic because it (a) raises expectations to unreasonable levels (no, not parser will give you 10x speed increase over comparable best-of-breed alternatives) and (b) risks future of one's own sales, when product doesn't deliver up to claims. Re: Repackaging Saxon
by
dret
on Fri 08 May 2009 18:49 BST | Profile | Permanent Link
i think the basic problem of the current licensing scheme is that it it built around the assumption that advanced XSLT users will use schemas and need schema-awareness. XSD's very limited success (and its increased complication with the upcoming version 1.1), however, mean that even very sophisticated and professional users do not need SA capabilities; they are simply not using XSD. so the most important challenge to come up with a sustainable model for saxon licensing is to build it around real-world uses, and these probably have little or nothing to do with schema-awareness.
Re: Re: Repackaging Saxon
Thanks for the comment. This is partly a matter of perception; the commercial version of Saxon actually has a lot more to offer than schema-awareness, and there's a section of the user community that doesn't realise this: hence the renaming. I disagree with you that people aren't using XSD; large numbers of enterprise users are using it. However, I do agree that persuading them of the benefits of making their stylesheets and queries schema-aware has not been easy. There are real benefits in doing it, which increase with the complexity of the application, but there's also an upfront cost.
Re: Re: Re: Repackaging Saxon
i think i am well-aware of the better features of SA and i did not want to say that they do not matter. they absolutely do. but the more fundamental problem is that even though XSD has some uptake because a lot of tools spit out XSDs, in many cases these XSDs are not really treated as application data models, and thus they actually make little sense as a programming type system for XSLT.
i think if it were possible (which it is not, i think) to investigate (a) how many users are using XML without or with XSD, and more importantly, (b) of those XSD users, which of those generate XSDs from other models and never look at it again, and who actually models and treats XSD as the application data model (and thus wants good support in the programming language), this last category of "real XSD users" is actually quite small. don't get me wrong, i think it is a very good idea to have XML models for what you're doing; but it is very hard to get people to start thinking in XML-centric ways rather than whatever their programming environment gives them as the main abstraction. and then there is this whole snake pit of how to actually design "good XSD", if you're commited to do it. there is little literature and little support for that, and more importantly, the real important questions of extensibility and versioning and mostly left to the XSD designer. and they're easy to get wrong. if XSD and XSLT had good and built-in language features for dealing with extensibility and versioning, this could actually be the killer argument for why people want XSLT-SA and are willing to pay for it, there would be immediate and visible benefits in terms of robustness and product lifetime. Re: Re: Re: Re: Repackaging Saxon
If you haven't tried writing schema-aware XSLT or XQuery code, then I urge you to try it. You don't have to know anything about XSD, you just have to be working with documents for which an XSD exists. You'll find the experience of getting your errors diagnosed at compile-time, instead of messing about with xsl:message debugging, an absolute revelation.
Re: Repackaging Saxon
by
Emmanuel
on Tue 12 May 2009 10:21 BST | Profile | Permanent Link
Why not match the licence also to a performance cap? Not the size of the db or the number of CPUs but keeping the most optimized code for the paying customers?
Re: Re: Repackaging Saxon
Thanks for the comment. Yes, performance is a good differentiator (it matches user expectations) - and there are already many optimization features available in Saxon-SA that don't appear in Saxon-B. But of course one wants to do this without artificially "slugging" the performance of the free product - remember it's open source so users could easily remove any artificial limits.
Re: Re: Re: Repackaging Saxon
I would say performance, risk and productivity as best differentiators?
I was not thinking exactly about "slugging". If "the product is getting ever bigger and more complex" because of a business requirement, then shouldn't this complexity remain in the paying version and pay for itself? If the additional complexity does not pay for itself, then wouldn't your new pricing scheme equates to asking the lower end users to subsidize it? Maybe it's a question of marketing a higher price for the Enterprise Edition and leaving Saxon-B pretty basic, unless you expect price stickiness. Re: Re: Re: Re: Repackaging Saxon
by
Cowtowncoder
on Wed 13 May 2009 20:35 BST | Profile | Permanent Link
One potential drawback is that it's sometimes hard to have "performance enhancements" as modular add-ons; and thus some code may be basically forked between free and enterprise versions. So it is possible that trying to apply some improvements only in enterprise version can cause sort of artificial complexity (or maintenance costs).
But that is probably the price to pay for being able to have different-enough versions -- in a funny way, it means enterprise version users may end up paying more for the privilege of having the privilege. Re: Repackaging Saxon
by
Adrian
on Mon 18 May 2009 06:32 BST | Profile | Permanent Link
One problem with charging is not the size of the fee, but the complexity in working out the license, who pays and how much. Right now as a developer in a medium sized software house (several hundred people) I'm free to download and use open source packages without any consultation.
This is no longer the case once there is a pay license. Even if it's only a cent per 100 installs, not only do I have to try and understand the license, I have to get a lot of other people to do the same (many of them who won't even know what XSLT is). Even if I decided to fight the cost approval fight, and even if I won it, I don't know how we'd work out the numbers, there's absolutely no way anyone could predict how many machines it gets installed on even within the company during a dev/testing cycle. So open source generally wins out, even it's it's inferior, buggy and slow. Even if they have to spend *more* money in the end writing their own code, the company will tend do it, because the costs are easier to predict and track, and the costing infrastructure is set up to handle this approach. This isn't a criticism of the proposal, just an (unhelpful) observation that simplicity is a big reason that open source works, as well as zero cost. >There are lots of risks associated with this strategy - one of them being that users will simply stick with Saxon 9.1. Well, actually, that's not really a risk - it's not a problem to Saxonica if they do I think that's a loss. A large user base which sticks close to latest releases is a good way to validate the product. Re: Re: Repackaging Saxon
+1 on this comment. I think it gets to the core of corporate software policies. At my 'day job' its extremely difficult to get approval for using licensed software ... *if it is based on cpu/servers/uses*. Even if it were "free" getting the legal and administration by-in of taking on the responsibility to track, manage, account for and remit licensing information is almost impossible. It has to be sold up to the Director level as a "must have" with incredible amounts of red tape.
On the other hand, I find it fairly easy to get the sign-off/approval for "developer" licensed software. Even for fairly expensive software. I can usually get approval for $500 or $1000 per-dev-seat licenses for a handful of developers with only direct management approval. This is because the accounting is simple. Even if they require "maintance" the accounting is what matters. We can "count the developers" who use something and then Mgt can put this on their buget and it slides in easily. But if I ask for a "server license" for something that has to be calculated based on # of systems its installed on, or god-forbid the # of "cores" or "processors" ... thats almost impossible. Who knows what system's the QA team is going to install this on ... and if its CPU-locked then we have to involve IT to license the computer-of-the-day. then what does "cores" or "processors" mean on VMWare systems (I hate them but IT insists on them). Its just hell and in practice almost impossible to get licensed software on these systems. So in conclusion, I think you'd be much more successful in your new licensing/product scheme if you can have the "Professional" version something that is easy to account for at a person level, not a distribution level. Make it a 'per developer' or "per site" license, maybe even based on the size of the corp if needed, but make it easy to account for. If a company has to figure out how many processors something is going to run on "in production" or figure out ways of re-using licenses for QA/DEV or for failover machines its extremely hard to justify and get through. Make it a fix fee per developer or organization and I think you'll find a lot more revenue. Re: Re: Re: Repackaging Saxon
You're spot on that in many organisations, the cost of buying software can vastly exceed the amount of money actually being spent. It's useful to have some feedback on how those costs arise. Unfortunately I don't think it's really possible to split Saxon's functionality into "development" and "runtime", which makes it difficult to move to a pricing model where you pay for development and runtime is free. But I am planning to introduce a "shrink-wrapped" site license.
Re: Repackaging Saxon
by
Adrian
on Mon 18 May 2009 06:38 BST | Profile | Permanent Link
How about splitting the license for XQuery/XSLT support at the top end?
|
Search
Recent Comments
Recent Articles
Month Archive
|
|||||||