A week ago today a minor skirmish broke out on Twitter between Apprenda – purveyor of PaaS software – and advocates of the open source Cloud Foundry project, originally created by VMware. The major point of contention concerned forks; specifically forks of the Cloud Foundry project. In a blog post, Apprenda CEO Sinclair Schuller made two broad assertions: first, that forks were a problem for open source generally, and second that they represented a problem for Cloud Foundry specifically. Unsurprisingly, Cloud Foundry defenders objected – vociferously – claiming FUD. Leaving aside the vendor sports angle to this issue, because it is frankly uninteresting, a deconstruction of the original claims may be useful for examining a larger question about licensing outcomes.
The first assertion is the easiest to address: we reject the notion that forking is an undesirable outcome. Forking is, to the contrary, provably beneficial to modern open source projects – at least from a developmental perspective. While it is true, as Schuller wrote, that long time open source advocate Eric Raymond argued that forking is a negative for open source projects (see “Homesteading the Noosphere“), context is important. At the time that that essay was written, the cost of forking was extraordinarily high. The advent of decentralized version control systems such as Git, however, reduced the friction associated with parallel development to negligible amounts in most cases. As Brian Aker – MySQL author and creator of the Drizzle fork – once put it,
I fully believe that the forking we saw was enabled by the move to [decentralized] bzr/launchpad. Without that move it would have been a lot harder to make that shift for most of the forks and distributions.
With the cost of forking reduced or eliminated entirely, software development is parellelized; much as bacteria evolve more quickly because they iterate in peer to peer fashion, so too can software projects innovate along multiple parallel tracks rather than a single serial development path. DVCS-enabled forking, then, is an enormous step forward for software development.
What is less clear, however, is the impact of forking on platform compatibility in an age of permissively licensed software. In his counterpoint to Schuller’s original blog post, VMware’s Patrick Chanezon pointed to this timeline of the various Linux forks, saying in part that there would be “No Linux of the Cloud without forking.” This assertion is likely correct; certainly it’s difficult to imagine Linux evolving as quickly or successfully without its decentralized – and fork-friendly – development model. As many are aware, in fact, Git – the most popular DVCS tool in use today – was originally written to manage the Linux kernel.
There is one important difference between Linux and projects like Cloud Foundry, however – the license. Linux is governed by the GPL, a protective reciprocal license that demands that modifications and changes to a given project be made available under precisely the same terms, assuming that these updates are distributed rather than maintained internally. Nor are these terms temporally limited: the GPL’s restrictions follow an asset in perpetuity. The practical import of the GPL is that public variants are throttled. The license does not require all shipped distributions of a codebase to be identical, but it does prevent one party from introducing proprietary features to differentiate it from another. Red Hat, for example, cannot ship a kernel that contains code unavailable to commercial competitors such as Amazon, Canonical, CentOS or SUSE.
Permissive licenses, however, contain no such restrictions. They are by design the antithesis of copyleft licenses such as the GPL, prohibiting very little. Permissively licensed code, for example, can typically be consumed by a third party, modified and then shipped as a proprietary product with no licensing issues whatsoever. For advocates of permissive licenses, software freedom means letting users decide for themselves how best to use the asset. For developers, permissive licensing is ideal, because of the lack of restrictions imposed. Perhaps for this reason, perhaps as a result of an inevitable recalibration of licensing distribution, recent years have seen a sustained and significant shift towards adoption of permissive licenses – largely at the expense of the GPL.
It is no surprise, then, that recent projects like Cloud Foundry (2011) and OpenStack (2010) are permissively licensed. Nor that this choice is welcomed by developers and corporate sponsors alike; it imposes less overhead on both. What is curious, however, is that discussion of the longer term implications of this shift with respect to forking are relatively rare.
It’s not that we lack history with permissively licensed projects, to be clear. While many of the higher profile open source projects like Linux or MySQL were reciprocally licensed, the Apache Software Foundation, an organization which considers permissive licenses part of its mission, was founded in 1999. Many popular programming language runtimes – PHP, Python, and Ruby, to name a few – are likewise permissively licensed. These projects and others have proved over a period of decades that permissively licensed assets can grow and thrive just as well as reciprocally licensed alternatives.
Permissively licensed platform technologies, however, are comparatively rare. The distinction is important, because platform technologies offer a different set of incentives than do component projects. Consider the case of OpenStack. As a permissively licensed asset, any consumer of the technology is legally able to produce and distribute a unique, differentiated implementation. And while the project culture and many practical incentives discourage this kind of forking, members of that community remain concerned about fragmentation – possibly because the incentives for vendors to differentiate from one another in the all important cloud market are great, or possibly because we’ve seen it before in projects like Android and its numerous vendor-specific variants. And if it’s possible to envision a world with different, competing variants of OpenStack, it’s not unreasonable to ask the question of projects like Cloud Foundry.
It’s worth mentioning, however, that from a customer perspective, forks or variants are not universally bad. While the various Android versions may represent unfortunate design decisions on the part of the vendors responsible for them, applications are in the overwhelming majority of cases compatible from device to device, assuming version equivalency.
Compatibility, ultimately, is the key to determining whether the forks which are so beneficial to development are a problem for customers. Java, for example, had multiple distinct implementations, which ensured competition and thus continued innovation to benefit customers. Compatibility, meanwhile, was tested regularly by a set of tests known as the TCK, or Technology Compatibility Kit. Without a passing grade, in fact, a given implementation could not use the name Java, and thus would not be acceptable to customers. This seems to be similar to the path Cloud Foundry, for one, is pursuing with its Cloud Foundry Core compatibility test.
While forking is then an unquestionable benefit to developers, its implications for customers – at least for projects that permit competing, non-shared implementations – are as yet unclear. Much of the success or failure of permissively licensed open source platform projects, then, will depend on how well they do or do not address compatibility questions for customers.
Disclosure: Apprenda, ActiveState (Cloud Foundry), AppFog (Cloud Foundry) and VMware (Cloud Foundry) are RedMonk customers.
