Towards A Real Business Model For Open-Source Software

Last week in a FreeBSD status report we talked about the Chromium web-browser support on FreeBSD improving through a new subscription program whereby most of the FreeBSD patches are being kept closed-source for some length of time before being committed back upstream as open-source and reaching the hands of the non-subscribers. This caused some to question the work, but the developer behind this FreeBSD-Chromium subscription program, Sprewell, has written an editorial that we are now publishing. This details his beliefs concerning the future of open-source software business models.

Open source software has grown to occupy a real niche over the last two decades, but it still hasn't been able to compete with closed-source software in most areas. I lay out the benefits of both software licensing models, then suggest a new development and business model: closed-source modules mixed into a mostly open source codebase. I believe this is the future of software development, securing most of the benefits of both models and creating new benefits from the marriage, while allowing open competition between both ways of developing software.

Let's start with the acknowledged benefits of open source. Most source code was originally open source, as hardware was very expensive and source was often shared freely. To this day, such openness allows patches and bugfixes to come from anyone and anywhere, although the time needed to get to know a new codebase before patching it cannot be discounted. Ideally this access would lead to a lot more open source innovation, as anyone is free to pick up the source and come up with new ways of doing things, but such entrepreneurship is often squelched by the fatal flaw of open source: there's just not much money in it. The only marginally successful open source business model is consulting/support, which has done well for some but brings in a small fraction of closed source revenues. The main reason is that consulting doesn't scale while selling software products does, as Joel Spolsky has noted. However, you can't sell open source software products because anyone is free to copy all your source and create a competitor: this is why desktop linux has failed to this day and why it will never succeed.

Further, much software today is infrastructure, information infrastructure that powers most aspects of our lives. Another great benefit of open source is that it allows the creation of a shared information infrastructure that anyone can contribute to. Rather than reinventing the wheel with a dozen closed-source SSL libraries, we can all contribute to a couple open source implementations that can be reused widely. Many software libraries, like zlib compression or the TCP/IP stack, are written once as open source and integrated widely, particularly when they are BSD-licensed. However, this sharing still comes up against the aforementioned funding problem, which cramps open source developers' ability to spend much time on development.

Closed source on the other hand is a highly successful business model, making the founders of successful closed-source software companies some of the richest men in the world. This geyser of money allows them to spend billions on their products, sheer scale that no open source project can match, and on research and development, however questionably that may be spent. Their software is used daily by billions of people; open source software usage is a rounding error by comparison, even once you include web-oriented software like Apache or linux that users touch remotely. I propose that the best model is one where both open and closed source are intermingled, so we can benefit from both the open access of open source and the funding from closed source. I have thought about how best to mix the two for some time and this is what I've come up with.

Start with a codebase that is open source, under a permissive license such as the BSD license or the CDDL. Anyone can write closed-source patches on such a codebase and sell the resulting software, as these permissive licenses allow such modification and redistribution. These hybrid source software vendors will contract with their customers that all the source used in a particular build will be provided to the customer under the same license as the rest of the codebase, BSD or CDDL, but only after a time limit for the vendor to recoup their investment. This time limit may vary for different industries and applications, but given how fast software evolves, a range of 1-5 years is likely to cover most software out there. Fast evolving software like web browsers might have a 18-month time limit, while slow-moving markets like medical applications might have a 5-year time limit. Note that only the closed-source patches for a previous build are released after a 5-year time limit, any new source written during those intervening 5 years will not have to be released until 5 years after it has also been included in a build. The idea of time-limited hybrid source is that 50-80% of the source will always be open, while the closed-source patches fund further development for a limited time, before being opened themselves.

Innovation can now come from anywhere and be paid for. Someone might read the source for a web browser and come up with a great new compression scheme to lessen network traffic. This outsider would then code up his method, contact the hybrid-source vendor and license his source to them, to be sold as a closed-source patch on the software. Of course, his patch will also be open sourced after 18 months. Such innovation from the edge will be much easier to do when most of the source for commercial products is open, allowing anyone on the internet to peer into a codebase and come up with better ways of implementing features, spurred by the knowledge that you can actually get paid for it. This mixed model also allows for an open playing field for open and closed source to compete within a single application or platform, as anyone can try to clone the closed sections of a mixed codebase and open source their patches. As a result, both open and closed source proponents can share common code while competing within a single application, rather than creating completely separate open and closed source versions, as often happens today.

If a hybrid-source vendor becomes too heavy-handed or unresponsive with their software- as happens from time to time with all software, open or closed- the traditional open source response of forking will still be available. You can simply take all the open source code and fork, but you will then have to clone all the closed-source components that customers want. This provides the optimal forking model, where forking is always an option but is constrained by some limits, as opposed to the constant forking we see with linux distributions today. A long conversation has been going on over decades about how best to create and fund software, which can essentially be seen as an ongoing negotiation between software programmers and users. Pure closed source gives programmers far too much control over what is after all a shared investment, while pure open source doesn't give programmers much incentive to slave away on the software. I propose that this time-limited hybrid framework is the best way to resolve this long negotiation, by appropriately mixing the two currently dominant licensing models. Even better, it can be tailored for various software markets: we may find that bug trackers tend to be mostly open source while word processors tend to be more closed. Rather than slotting all software into the binary distinction of pure open or pure closed source, we can have much more variation and the many benefits that fall out of such a mating.

You can read more about time-limited hybrid licensing here.

Do you agree with Sprewell's view of the best model whereby open and closed-source software is intermingled? Share your thoughts in our forums.