<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=1907245749562386&amp;ev=PageView&amp;noscript=1">
Event_bg

The Leonardo Blog

All Posts

Why Open Source Thrives on Cooperative Competition

Copy of 2019 Blog ImagesAlthough I’ve spent the majority of my career on the consulting side of the fence I’ve also spent ten years on the client side, in senior IT roles, where I purchased a lot of software.  It was in 2006 that software sales people started offering alternatives to the traditional model of licence plus annual maintenance for proprietary software. These sales people were offering SaaS solutions and subscription-based open source software, neither of which I seriously contemplated buying. 

Given that SaaS and open source software are now an everyday part of the IT landscape - why was I entirely unwilling to consider them a dozen or so years ago? The answer is simple. In neither case did they offer the benefits they do today, and, worse, the people selling them struggled to articulate what the real benefits of their offerings actually were. For the purposes of this post I’ll leave the SaaS model aside to instead focus on open source software. i can still recall conversations about open source software in 2008 and 2009. The message from the open source evangelists was “it’s better because it’s open source!”. And I use the term “evangelists” advisedly, because for them it was a matter of faith, not fact.

“Why is it better?”, I would ask. “Because you have access to the source code!” was the inevitable response. Given the large corporate for which I worked had a grand total of zero programmers this was of little interest or value. Sure, we could look at the code, but none of us would understand it. God forbid that we would ever try and change it.

More reasonable were the arguments that other people, who would understand it, could see it, and fix bugs, or remove security vulnerabilities. This piqued my interest at the time, but further questioning showed that most products were only ever modified by the developers who had built them in the first place, i.e. there was no community built around the product, so it may just as well have been proprietary. 

The other advantage that we considered was, inevitably, price. Open source solutions were generally much cheaper than their proprietary alternatives. But all those years ago we were still wedded to the prospect that software was a capex line item -  an asset to be depreciated, with some of that depreciation occasionally clawed back by the accountants at end of financial year to help meet target earnings.

Forward to 2019 and some things have changed, others have not.

There are still companies that will never, ever, in a million years look at the source code. There are still open source products whose source code remains unlooked at - except by their own developers. And certain open source products have had such phenomenal market success that their prices now eclipse even their proprietary counterparts. But, despite these facts, open source is an undoubted success. Why?

Let’s start with IBM’s $USD 34 billion acquisition of Red Hat, unquestionably the most commercially successful open source software vendor. This is the most money IBM has ever spent on an acquisition. Clearly they see a strategic gain to be made from this investment. Industry analysts look at IBM’s lack of cloud success compared to AWS and Microsoft, and point to Red Hat’s OpenShift as the crown jewel in the Red Hat technology stack. OpenShift, they point out, will potentially allow IBM to become a dominant, if not the dominant player in the hybrid cloud space. We can use OpenShift as a metaphor for why open source is, and will increasingly become, the superior model for developing software.

OpenShift is a combination of, amongst other technologies, Docker and Kubernetes. Red Hat is the second biggest code contributor to both Docker and Kubernetes, after Docker Inc. and Google respectively. Docker and Kubernetes have the massive advantage of some of the world’s most capable, innovative, and successful technology companies collaborating in their development. The claimed advantages of bug fixes and the removal of security vulnerabilities start to ring true (and are true) then the fact the code is open source means that companies who compete with one another can still collaborate. This concept was the basis for a 1996 book called Co-opetition: A Revolution Mindset that Combines Competition and Cooperation, by Adam M. Brandenburger and Barry J. Nalebuff.

Most OpenShift customers will likely never look at the source code. Nor will most ever need to. But they can use OpenShift with the comfort of knowing that it has not just Red Hat’s expertise standing behind it, but that of Google (Kubernetes) and Docker Inc. (Docker) and many others as well.

Another good example of a successful open source project is Jenkins. It’s easy to forget that Jenkins is a fork of Hudson that occurred when the majority of the Hudson development community decided in 2011 to continue the project under a new name after Hudson became part of Oracle, in the same way that MariaDB was forked from MySQL following Oracle’s acquisition of the latter. Only with an open source codebase can software be forked, potentially protecting the user community (or development community). Certainly, this advantage was never mentioned to me back in 2007!

OpenShift is hardly the only open source product to benefit from “co-opetition”. Another prime example is the Istio service mesh framework. Istio shows that collaborators need not be software vendors, as the original developers included Lyft as well as Google and IBM. Red Hat has also joined the party as an Istio contributor, and Istio will be included in version 4.x of, you guessed it, OpenShift. 

Finally, it would be remiss to omit Netflix from this discussion. Netflix isn’t a software company per se but it is well known for being one of the earliest adopters of the microservices pattern and a vast amount of Netflix’s source code for managing and deploying microservices is freely available at https://github.com/Netflix.

So if one day I find myself back on the client side of the fence I will happily buy an OpenShift subscription and reap the benefits of the co-opetition between Google, Docker Inc., and Red Hat (and Microsoft, and Pivotal, and IBM, and AWS, and Cisco, and many others to boot). I’ll happily use Istio and Jenkins in OpenShift. I’d probably never look at the source code of any of these, but I’d be content knowing that Google, Docker Inc., Red Hat, and the rest, do that job for me.

Using Processes as Microservices to Drive Better Customer Experiences

Phil Ogilvie
Phil Ogilvie
Phil Ogilvie has more than 25 years experience in the development and execution of business and information technology strategy. As both a senior manager and consultant, Phil has worked for organisations ranging from small entrepreneurial start-ups to global multi-national companies. Phil specialises in initiating, leading and driving transformational programmes of work that help companies make significant performance improvements. Phil has deep experience throughout the business improvement lifecycle. He is equally comfortable with the upfront strategy, analysis, and solution design work as he is leading delivery programmes and projects. Phil is also equally comfortable leading business or IT initiatives, having experience in running business-only initiatives, such as process improvement projects, and in running IT-enabled initiatives, such as ERP or CRM implementations.

Related Posts

How To Replace Random Acts of Management With a Metamodel of Improvement

The simple existence of a problem is not enough reason to invest in fixing it, perhaps not now, perhaps not ever. Organizations need a systemic approach to define what good looks like, assess current performance, and make evidence-based decisions about which performance gaps to close. The Tregear Circles replace random acts of management with a metamodel for continuous process improvement. I have recently encountered several examples of the idea that higher process performance target scores are obviously better than lower ones, just because they are … well … higher; that setting a target of, say, 95% is, without doubt, better than a target of 88%, and in striving for improvement we should go 'as high as possible'.

Why Open Source Thrives on Cooperative Competition

Although I’ve spent the majority of my career on the consulting side of the fence I’ve also spent ten years on the client side, in senior IT roles, where I purchased a lot of software.  It was in 2006 that software sales people started offering alternatives to the traditional model of licence plus annual maintenance for proprietary software. These sales people were offering SaaS solutions and subscription-based open source software, neither of which I seriously contemplated buying.  Given that SaaS and open source software are now an everyday part of the IT landscape - why was I entirely unwilling to consider them a dozen or so years ago? The answer is simple. In neither case did they offer the benefits they do today, and, worse, the people selling them struggled to articulate what the real benefits of their offerings actually were. For the purposes of this post I’ll leave the SaaS model aside to instead focus on open source software. 

3 Ways to Measure the Usefulness of BPM

  In the fair dinkum department, the most important question about BPM must be "is it worth the effort?" It works in theory, but does it work in practice? What is the return on process? How should we measure, and report, the outcomes of process-based management?   The Wrong Answer Let's deal with the wrong answer first. It's not about the artifacts. No organization has a business problem called "we don't have enough process models." It is not a business improvement outcome to say we've trained 50 people on Six Sigma analysis, or appointed some process owners, or modelled a process architecture, or assigned process KPIs — these are all necessary, but none is sufficient. To the executive not yet fully engaged with the promise of process-based management, all this activity might sound more like a problem than a solution, more like a waste of resources than a successful outcome. And if that is all that is happening, she would be correct. We need good models, architecture, methods, and training — a metamodel of management — they are a means to an end, but not an end in themselves. Just having management tools is not the point; we must use them to deliver real organizational performance improvement. If our process management and improvement activities are not delivering measurable, objective, proven organizational performance improvements — improvements better than we might have otherwise achieved — then our process activity is, by our own definitions, waste.