Instead of just thinking about using open source software, enterprises should now be thinking about creating open source software. That’s where the business benefits really lie.
In most enterprises today, the visible sign of open source is the polarization in development shops between “open source,” by which we mean Java, PHP, Python, Ruby, etc., versus “.net.” Suffice it to say that vastly more development resources are applied to innovating in open source than Microsoft can afford to apply to .net, so this balance is only going in one direction. But in many ways, this is a sterile argument, because the constraints on when and how organizations jump across from .net to open source come down to historic choices, organizational inertia, skills availability, etc. We are assuming that in most organizations, there will be already be significant open source, and we are interested in what happens next.
To most businesspeople, open source seems a bit, well… communist. There doesn’t appear to be an obvious way to make money by giving something away, but if some fool is prepared to do that, why not take advantage of it? However, taking this attitude toward open source is a bit like going to the pub, letting your friends buy you drinks, and leaving before it’s your round. You may do it once or twice, but is it really the right thing to do, and does it convey the right impression to your friends? At some point, every enterprise is going to have to consider the possibility of contributing to open source, if only to satisfy its corporate social responsibility goals. Actually, however, there are more significant benefits, as well as potential dangers.
How do I know if I am contributing to open source?
There are a number of formal processes by which software can be put into the open source by issuing it under an open source license or by assigning the IPR to an organization that does so. These vary between licenses and among open source projects; most organizations would probably involve general counsel and take this all very seriously. But there is also a level of leakage that occurs when people contribute to bulletin boards. Those ideas and/or any bug fixes included with them get fed into the development codebase and licensed out under open source. If an organization has good developers working with cutting-edge open source technologies, they will be doing this (and the organization will be seeing the benefits from it), but the organization will also be leaking IPR. If you are going to do this, perhaps you ought to think about how you are doing it and, perhaps, how to get most benefit from it.
Why should I give my competitors my source code?
The bottom line is that competitors probably can’t get as much benefit from your source code as you think they can. Organizations invest a lot of time and money in building source code and assume that their value is embedded within it, whereas in practice most organizations are embedding a lot of value in the processes that surround the source code. Yes, without the computer system, the business wouldn’t function, but it doesn’t necessarily follow that a competitive business would gain huge commercial advantage from adopting the source code to the computer system, because its business wouldn’t function that way. This is the “land grab” aspect of open source. If you get customers, suppliers, and other business partners working with your source code, you end up with an ecosystem of companies operating their business processes in ways that interact with the way your source code works, and they are building their businesses in such a way that they naturally fit yours and not your competitor’s.
How do I contribute to open source?
The first thing to say is that if you simply re-license all your software under an open source license, say, Apache 2 or GPL3, nothing will materially change. You can still sell the software and modified versions of it under a different license, or if you are developing for internal use, you can still use it yourself and modify it in any way you see fit. The bottom line is that no one will care. Open source isn’t about the license; it’s about the community of collaborating individuals working together facilitated by the license. If you wish to reap the benefits of open source, you are going to need to have a clear set of objectives and a strategy by which to deliver those objectives.
Won’t I get hit by anti-trust laws, IPR lawsuits, etc.?
Competition and anti-trust laws, copyright and patent claims, GPL cross-contamination, Microsoft-bankrolled patent trolls, etc. were a big concern around 2005-ish, but nothing really bad happened. I particularly like the story of Cisco and its Linksys routers from 2009. Cisco was sued because in acquiring Linksys it accidentally ended up selling a product that was in breach of the GPL license. It was forced to issue source code to its firmware. Subsequently, a number of alternative firmware versions were offered by the open source community to run on its routers. As a result, the lifetime of that product has been extended far beyond what you would expect. You can still buy it, because you can flash in the alternative firmware. You do need to think about this legal stuff, but there are established ways to comply, and the risk isn’t what it seems.
Who succeeds with open source?
One might expect that open source is all about individuals and startup companies, and perhaps this was the case with Red Hat and Linux in the 1990s, but more recently the answer has been fairly consistent: the big winners are large, established companies entering a market sector or second-tier players who wish to disrupt the dominant player in a market sector. Google took on Apple and Microsoft with Android and won (certainly by volume market share). IBM took on Microsoft with the Apache Web Server and Eclipse and won both battles. Rackspace is taking on Amazon with OpenStack and, well, at least it’s stopped itself from being obliterated. Pivotal and Red Hat are having a go at Heroku and Microsoft Azure—that one has a way to run yet. The reason these larger organizations succeed big with open source is that they have the scale and the credibility to establish the nucleus for the open source community. The challenge for many such organizations is how to cut across existing business processes to deliver the value of open source—which is so alien to many business people.
Which sectors are ripe for open source?
We have probably run out of operating systems, software tools, cloud infrastructure, etc., for new open source initiatives. Sector-specific software applications are likely to be the next big area. Perhaps the best indicator is that a sector is already undergoing some form of change or significant pressure to change, because the transition can be facilitated by open source. There are two very interesting and significant sectors that, in my view, fall into this category: retail and finance. In finance, you can see the pressure to change and the value of open source in the way Bitcoin has emerged. Bitcoin is entirely an open source phenomenon. You mine it with open source software, you store it in an open source wallet, and you trade it with open source software. Under the covers, the whole technology reeks of open source. Bitcoin may not succeed until a substantive player gets behind it, and it is likely to fall foul of regulation, but something will happen. The other sector, retail, is transitioning massively at the moment, and is ripe for a big open source play. Who knows what it will be—it could be exciting.