The other day I storified a bunch of tweets by Alan Cooper on the strategic role of software in business.
Here’s the first half of it. You should go and read the rest.
All business activities that used to be strategic are now hygienic. Today, all that is strategic is software. Activities that make money aren’t strategic. Activities that affect a company’s ability to make money in the future are strategic. Where is the leverage? That’s what is “strategic.” Only software provides significant leverage in business today. If your office lacks electricity or wifi, nobody shows up and nothing gets done. But neither electricity nor wifi are strategic. (Alan Cooper – https://storify.com/fakebaldur/software-and-strategy)
There are several ways the strategic role of software plays out in the book publishing industry but the first one that comes to mind ties in with a point made by Joel Spolsky in an old blog post, “smart companies try to commoditize their products’ complements”:
Demand for a product increases when the prices of its complements decrease. For example, if flights to Miami become cheaper, demand for hotel rooms in Miami goes up – because more people are flying to Miami and need a room. When computers become cheaper, more people buy them, and they all need operating systems, so demand for operating systems goes up, which means the price of operating systems can go up.
And…
Once again: demand for a product increases when the price of its complements decreases. In general, a company’s strategic interest is going to be to get the price of their complements as low as possible. The lowest theoretically sustainable price would be the “commodity price” – the price that arises when you have a bunch of competitors offering indistinguishable goods. So:
Smart companies try to commoditize their products' complements.
If you can do this, demand for your product will increase and you will be able to charge more and make more.
It’s easy to see how this plays out in ebooks. Ebook reading apps are a complement to ebook retail so it’s in the interests of both retailers and publishers that they become a commodity.
If ebook reading apps are free, people will read and buy more ebooks.
If ebook reading apps come in many varieties, each offering features that address your specific ebook reading needs, you will read and buy more ebooks. (See also The Extra Chunky Internet on why variety in apps is a good thing.)
If the rendering engines for ebooks were free for everybody to use, whatever it is, we’d see ebook support rolled out everywhere, which would make people read and buy more ebooks.
Things like:
-
Decent previews for ebook files in Dropbox or email apps.
-
A high fidelity preview of what your ebook will look like as you fiddle with the ePub export settings in Scrivener or Ulysses III.
-
ePub support in comics reading apps that otherwise almost universally only support CBZ/CBR and PDF files because supporting the insanely complex ePub FXL format is just too much work for a small business.
…would promote and increase the reading (and purchase) of ebooks.
It would be logical for ebook retailers (both the ePub crowd and Amazon) to turn ebook rendering into a commodity. That means an ebook rendering library that anybody can use, anywhere, for whatever reason, for free. Put a price on the use, and it ceases to be a commodity and it stops being a strategic advantage to ebook retailers and publishers. Put conditions on the use, and, again, it ceases to be a strategic advantage to ebook retailers and publishers.
I had high hopes that Readium SDK could perform this role for us, but its licensing conditions are an explicit attempt to decommodify open source code.
The base contribution required to qualify for the Alternative License for Readium SDK is $30,000 USD (of which up to $25,000 may be waived by prior agreement if the licensee contributes at least 3 person-months of mutually-agreed useful development to a Readium Foundation project). Maintenance is currently $3,000 USD per year. First-year maintenance is required and is invoiced with the initial license fee. Maintenance is billed annually on the anniversary of the initial invoice.
I’ve repeatedly in the past expressed my disappointment in this decision but this time I’d like to emphasise that I also think it harms ebook retailers and publishers.
Putting conditions on the license harms attempts to turn ebook rendering and reading support into a commodity but it also harms participation in the open source project itself:
Proprietary relicensing, of both varieties, tends to suffer from several problems.
First, it discourages the normal dynamics of open source projects, because any code contributors from outside the company are now effectively contributing to two distinct entities: the free version of the code and the proprietary version. While the contributor will be comfortable helping the free version, since that’s the norm in open source projects, she may feel less enthusiastic about her contributions being useable in a monopolized proprietary product. That is, unlike a straight non-copyleft license by which anyone has the right to use the code as part of a proprietary work, here only one party has that right, and other participants in the project are thus being asked to contribute to an asymmetric result. This awkwardness is reflected and in some ways amplified by the fact that in a proprietary relicensing scheme, the copyright owner must collect some kind of formal agreement from each contributor (see the section called “Contributor Agreements” earlier in this chapter), in order to have the right to redistribute that contributor’s code under a proprietary license. Because such an agreement needs to give the collecting entity special, one-sided rights that a typical open source contributor agreement doesn’t include, the process of collecting agreements starkly confronts contributors with the imbalance of the situation, and some of them may decline to sign.
That’s from Producing Open Source Software by Karl Fogel which has a lot more to say about the disadvantages of proprietary relicensing schemes such as the one the Readium Foundation is using.
Both the Free Software and the Open Source movements are now decades old. We’ve seen a set of standard practices emerge organically in these communities through trial and error. Both movements have settled on a small set of standard licenses each of which is suited for a specific circumstance:
-
The GPL is for applications—command-line or GUI—on systems the user controls, i.e. platforms that let them run whatever code they like.
-
The LGPL is for libraries on platforms the user controls.
-
The Apache License is if you want your library or toolkit to be used everywhere by everyone but want some patent protection.
-
The BSD/MIT licenses are for implementing stuff that’s supposed to be universal but isn’t yet and is unlikely to be patented.
This isn’t that complicated. If you’re choosing to use the GPL (let alone the Affero GPL) with library code while at the same time offering an actually library-friendly license for a fee, you are sending a message. And it isn’t a message of warm hugs and open source solidarity but of exclusion and division based on money and resources. It is an explicit attempt to prevent the commoditisation of a feature that would benefit many more people and businesses if it were a commodity.
I’ll end with this note from Fogel’s Producing Open Source Software:
What seems to happen in practice is that companies that offer proprietarily relicensed software do not get truly active development communities with external participants. They get occasional small-scale bug fixes and cleanup patches from the outside, but end up doing most of the hard work with internal resources. Since this book is about running free software projects, I will just say that in my experience, proprietary relicensing schemes inevitably have a negative effect on the level of community engagement and the level of technical quality on the open source side.