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).
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;
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.