Deployability as differentiation
There are still plenty of those businesses around, many doing well. But the trend my previous article explored has steadily subsided as complex enterprise infrastructure has become easier and easier to obtain and deploy. The existence of substantial, mission-ready open source software has left fewer and fewer niches for software companies to differentiate on software alone. In an interesting, baseball-themed post, RedMonk analyst Stephen O'Grady says:
The technology industry is a lot like major league baseball circa 2000: it shares widely held, but fundamentally incorrect, ideas about valuation. Vendors and buyers alike, for example, behave as if software were a competitive advantage, when this is only rarely the case.
The result has been the rise of deployability as differentiation. Companies differentiate by the way they assemble the common open source components everyone uses and on the service they are consequently able to offer. For example, while theoretically anyone could build a cloud-based continuous integration service using Jenkins and a stack of open source software underneath it, CloudBees has been able to successfully trade on the know-how involved in deploying and scaling such a service.
In a world where the software itself is nondifferentiating, it becomes smarter and smarter for vendors to exploit a much-mentioned attribute of open source software: community. The rising trend of the moment is typified by projects from Eclipse to LibreOffice. Although they follow a path that was paved over a decade ago by the Apache Software Foundation, these projects combine the unblinking transparency that Apache brings with a focus on a particular software set, allowing more focused engagement with both developers and corporations. As Mike Milinkovic of Eclipse once said, "The Eclipse community is working on a single technology platform, so every Eclipse project can interoperate with the others at some level."
Interestingly, neither of the two projects I've named use the Apache License for their code. Eclipse uses the Eclipse Public License and LibreOffice uses LGPLv3 -- both weak copyleft licenses. Using a weak copyleft license has been optimal because, while it offers the freedom to use the software in combination with other software in any way that is interesting, the project itself remains a code base with an explicit requirement to work in-community and contribute. While for the most part that requirement needs no enforcement, its absence allows well-resourced and politically adept corporations to "game" open source, using both dominant contribution and behind-the-scenes agreements to ensure that the public project is effectively under their control. That sort of high-stakes politics is not desirable.
Peering into the future
While the newest open source projects such as OpenStack and OpenShift have chosen to use the Apache License, a non-copyleft or "permissive" open source license with good patent protections, I believe in time we will see the licensing trend for new open source projects targeted at commercial collaboration swing back to the center, away from either the GPL or Apache extremities. Until recently, none of the mainstream "center ground" open source licenses has been optimal. These are the Mozilla Public License (MPL -- and its many "vanity name" variants), the Eclipse license, the CDDL (used widely by projects influenced by Sun Microsystems), and of course, the LGPL.
Recently, a new approach has emerged. After a decade of use, the Mozilla Foundation recently updated the MPL to a new version, MPLv2. It delivers the same high degree of patent safety we've come to expect, is a file-based weak-copyleft license that avoids causing license relationship issues in combination with other software, and has been well-drafted to be readable and relatively short. Most important, it is explicitly compatible with the GPL, allowing MPLv2 projects to play nicely both with Apache- and GPL-licensed software. It occupies a sweet spot: permissive enough for corporations, copyleft enough for communities, and well-written to boot.
I believe we will see future collaborations use the new version 2 of the Mozilla Public License more and more. We may even see some projects already using weak-copyleft licenses migrate to it -- indeed, the Document Foundation, home to LibreOffice, has been discussing the possibility of such a move for LibreOffice. As the timeline for commercial open source licensing progresses, I believe a trend back toward the center will arise, either to the MPLv2 itself or to an even better successor. That's a positive and unifying direction, and I sincerely hope it happens.
This article, "What's next after GPL and Apache?," was originally published at InfoWorld.com. Read more of the Open Sources blog and follow the latest developments in open source at InfoWorld.com. For the latest business technology news, follow InfoWorld.com on Twitter.