Feb 162013

Michael Kay announced recently at XML Prague that Saxonica is going to open-source Saxon CE, the XSLT2 processor that runs in every modern browser. At the same conference, we (le-tex) announced that we will open-source our IDML/OOXML conversion pipelines (documentation/examples will follow).

Previously Saxon-CE was licensed on a per-site basis, but probably didn’t find many licensees yet. One reason is that mainstream Web development takes place in Javascript and that most of that stack – the browsers’ JS engines, debuggers, libraries such as jQuery, etc. – is free. When I had to outweigh the complications of Saxon CE licensing and the lack of acceptance of this maverick XSLT2 technology, even in my own organization, against the mainstram-ness of a jQuery extension, I opted for the latter.

But the idea of having XSLT2 in the browser as readily available and deployable as any jQuery extension certainly appeals to me. So I was very happy about Michael’s decision to open-source Saxon CE.

He said although he hadn’t the faintest idea how to make money off of it, it’s important to its success that Saxon CE has 1 million rather than a couple dozen users.

We find ourselves in a similar situation: After years of fumbling with ad-hoc converters and Makefile orchestrations, we’ve developed a robust conversion infrastructure from/to OOXML and IDML and other XML formats, such as the central Hub format that uses CSSa, as presented in Prague. These converters are based on the XML stack, namely on XSLT2 and XProc. Nowadays, even in publishing, XML technologies compete with other approaches (HTML5/Python, HTML5/JSON/JS, …). So in order to maintain and demonstrate the stack’s validity, it should matter to us that we create mindshare, i.e., that both customers and competitors approve of that technology stack and use it, too.

Saxon CE and our tools have in common that the money has already been spent on developing them.

Conventional thinking knows two principal ways of monetizing these tools: either selling (licensing) them or not disclosing them and therefore being able to offer one’s services more cost-efficiently than the competitors.

What conventional wisdom overlooks is that adopters of a technology or a tool don’t merely buy the tool for what it does. They buy into an ecosystem. They don’t want to be left alone with their tool vendor. Even when they buy a tool that a single vendor controls, such as SAP or Microsoft, there’s some assurance that the tool will continue to be supported at more or less the same terms.

To buy a proprietary tool that only three developers in the world maintain, and where these three developers are working for a single small company, is risky. The company may cease to exist, key developers may leave, the product may become out of focus if the user base is too small or if it doesn’t generate substantial revenues, etc.

So a way forward may be to open-source the product and broaden its user base. But how will the product generate the revenues to sustain its development if it is open source?

Another concern, maybe less for Saxonica than for my fellow managing directors, the shareholders of le-tex: If we open the tool that has helped us maintain a competitive edge over our competitors, why should we sacrifice that competitive edge in giving the competitors the tool for free?

I’ll try to address the second concern first. First there’s a natural inertia and a not-invented-here attitude that keeps competitors from adopting our tool. Maybe their toolchains are so different from ours that our tool doesn’t add much value for them. Or they have similar proprietary tools for internal use. There will be many reasons for competitors not to adopt our tool. While this probable non-adoption may refute the argument that competitors will get the better of us, for free, it amounts to admitting that the tool won’t be broadly adopted. The tool being open source may then somehow appease the customer who is unwilling to buy proprietary software that only one single shop controls. But at least among customers in publishing, it isn’t the proprietary nature of tools that stifles adoption, it’s rather their lack of proven acceptance in the marketplace, their niche or even esoteric nature.

So hoping for non-adoption among competitors obviously doesn’t solve the adoption issue. The tool has to become mainstream, and this can only be achieved by pulling customers and competitors into that methodology. To spread the news about the superiority of our proprietary tool is beyond our marketing and sales capacity, and it’s increasingly hard to introduce high-priced infrastructure products in markets where databases, operatings systems, development tools etc. are free. Apart from that, our tool builds on a stack of open-source tools such as Saxon HE and XML Calabash, and the tool or its methodology aren’t exactly rocket science. To the contrary, they epitomize the way that we think that everybody should use the basic tools to convert the standard XML-based input formats to XML-based output formats. They are to us, so to say, the categorial imperative of data conversion, and of course it’s non-sensical to treat such a universally valid guideline as proprietary intellectual property.

What will happen if competitors (= partners), customers and other entities (the not-yet-customers) start using our tools?

Indian partners might use the tools for their English-speaking customers. If they have special requirements, the customers are likely to ask us, the tool’s initiator, to extend the tool with a certain functionality. This has worked for companies such as 37 Signals who are in a position to pick the customers that they provide with Rails-related services. And they can charge a premium for these services because they are the initiator.

The English-speaking publisher market has been virtually inaccessible to us because there’s a plethora of (mostly) Indian vendors who are able to offer commodity services at a lower price, at least for English-language publications. But also in our domestic market, it’s probably true what our partner/competitor Manuel Montero Pineda told me after our open-source announcement: If his company uses our tools and a customer requests a modification, given their developers’ high degree of utilization, they won’t spend weeks or months to investigate the internals of the software and modify it. They’ll rather ask us to do the job, yielding revenues from a customer that we didn’t “own”, and doing so without any sales effort on our part.

I’m confident (although I cannot prove) that these additional effects will outweigh detrimental effects where competitors will be able to snatch away a customer because, thanks to the tools that we developed, they are able to charge less (because they don’t have the development costs) for the same services, using our tools.

But what’s the revenue model then? Only in rare cases can you argue that you had the development costs anyway, for creating internal-use tools, or that you also get some payback from others who extend the tool that you initially have open-sourced.

I see the following sources of revenue:

  • Customers paying for new features;
  • Customers paying a premium for services around the tool (because you are the 37 Signals in your space);
  • Hosted solutions that are built on the tool and that subsidize its development;
  • Support and consultancy;
  • Voluntary contributions by customers. We have already requested and received these, but it has proven difficult to explain why a pilot customer has to pay for a feature when subsequent customers get it for free. This sense of unfairness is similar to what my colleagues feel about funding development and then let our competitors use the tool. In markets such as Norway, this model of funding open-source development is much more accepted than in Germany, because the customers are well aware of the fact that they also profit to a large degree from developments that someone else has subsidized. It’s all a matter of education, I guess (or is it a matter of abundant petrodollars, coupled with Scandinavian common sense?): Do you want to use BaseX without licensing fees and maybe pay $ 7,000 for a certain feature that you need, or do you want to spend $ XX,000 upfront for MarkLogic that already has this and other features? It’s important to tell people that sponsoring open-source development is in their mid- to long-term financial and strategic interest;
  • Maintenance fees, compatibility assurance: We have successfully sold our newly open-sourced toolchain to a German publisher because we promised to open-source it (otherwise they would have selected a solution from another vendor). Apart from man&material fees for further developing the tools and for configuring them, we offered an upgrade/compatibility assurance that is comparable with the 18 or so percent annual maintenance fee that commercial software vendors charge. This assurance covers that we keep a copy of the customer’s customization in our continuous integration infrastructure, and we define and continuously improve test sets taken from the customer’s documents. Whenever we change our basic tools, we will know if something will break if we deploy an update at the customer’s site. And we’ll make sure that nothing breaks or otherwise find a solution what to change in the basic tool or in the customer’s installation so that they can use the most recent versions of our basic tools. Of course this is a service that you can charge for. Of course providing this service costs you something. But you can organize these tests alongside your other CI tests in an efficient manner so that there will be profits to subsidize further development. On the other hand, the customer would have to spend much more if their own people were responsible for integrating our patches to their infrastructure. Simply because we would create these patches without checking for compatibility with their installation, and because they don’t have a sophisticated CI infrastructure. I think that this kind of assurance service may also be provided by Saxonica for Saxon CE: offer the infrastructure for customers and system integrators to upload their applications and run Selenium-like test on them, and run these tests automatically against Saxon CE release candidates.
  • Offering training and certification: We develop tools but we are primarily a provider of integration, conversion, typesetting, hosted solution, and support services. Saxonica, on the other hand, primarily develop tools. Apart from charging for implementing certain features or receiving direct subsidies, they cannot subsidize development by other services. But they can train integrators and certify them and their solutions. This won’t cover all development costs and incurs additional costs, but it may provide some compensation;
  • Contributions by organizations with a vested interest in the tool. For Saxon CE, this could be an organization such as Mozilla Foundation, although this seems unlikely, given their current focus on Javascript, DOM, CSS and other non-XSLT technologies. It could be NIH for a Saxon-CE-based, Web XML editor that allows editing JATS. It could be a consortium of publishers who need a configurable HTML5 editor with different kinds of XML output. We are currently plotting a deal with some German publishers. Part of that deal would be a contribution to the development of the open-source Saxon CE product (for example, what they’d save in comparison to the hitherto existing per-site licensing fees).

To sum up: I think there is more opportunity in open-sourcing tools such as Saxon CE or our conversion toolchain than it is in keeping them closed. It is important to create mindshare both with respect to the technological merits of these approaches and with respect to funding models beyond conventional licensing.

  5 Responses to “Open-Sourcing for Impact and Profit”

  1. Please, don’t perpetuate the confusion between open-source and free (as in free beer).
    An open-source product can be sold, just as any closed-source product.
    In this article, Saxon-CE and your product are released as free (as free beer) AND as open-source (which license?). But the main thing for their acceptance is the “free” part.

    But like you, I think it’s a great news for Saxon CE 🙂

  2. I’ve clarified the licence and invocation examples for idml2xml, others will follow.
    It’s a simplified BSD license.

    When you say, the main acceptance factor is the “free” part, which meaning of free do you have in mind here? I think “free as in free” in the GNU sense, since you linked to that post. On the other hand, you previously mentioned free as in free beer.

    My point is: a key factor to acceptance for most of our customers is not so much that it’s free as in beer but that the longevity and support of the product is guaranteed. If you’re a small vendor (and despite our headcount of 150, we’re a small vendor with ~8 XSLT developers, 2 of whom developed the IDML tools), customers buying or using the software will feel better if there’s another company around that is able to deliver support. And other companies embracing the software are an indication that it is not a too arcane or esoteric approach.

    Open-sourcing these tools simply facilitates all the licensing fuss that people would otherwise have, and it would keep individuals from just being able to try out the software without the need to ask someone for permission or budget.

    Of course we can think of dual licensing. But if it is just another license for the same product, some customers have a hard time understanding what they’re paying the extra fees for. We don’t have differentiating features in the tool that would justify a paid-for variant, as with Alfresco Community Edition vs. regular or Saxon HE vs. PE/EE. So the most simple approach I think is to make it open source and ask users for contributions to the advancement of the tool, be that financial or code-wise.

    Offering an update compatibility assurance is an option that even the critical CFO (“why should we pay an extra voluntary amount for this product when everybody else can have a free ride”) will understand.

  3. Ah, sorry, the “free part” was referring to “free as in free beer”.

  4. You made a nice editor that uses saxon-ce. Perhaps you can update it to use the FOSS version saxon-ce 1.1 so that the license message goes away.


    • Jos, Thanks for your kind words.

      The editor was only a prototype. I’ll create a new version until September. It will be open source, too. I might update Saxon CE for the prototype in the meantime, but I can’t commit to a specific date for that. But of course you can grab the source code from http://publishinggeekly.com/wp-content/uploads/2011/06/sxedit/ in the meantime and try to make it work on another host. If you try it locally, you should use your browser’s option to bypass cross-site-scripting barriers (-allow-file-access-from-files in Chrome). And for licensing reasons, I’d probably use Hallo editor instead of Aloha for the HTML/contenteditable part.

 Leave a Reply

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>