Collaboration in industries can create more powerful tools

The open source advantage: Executives learn how to stay competitive

open source why
Image by :

Let's say you're a big company in a competitive industry. One who innovates and succeeds by creating software. Not extending COTS, not adapting existing code. Generating fresh, new code, at your full expense. The value the company receives by investing in the creation of that software is competitive advantage, sometimes known as the profit-motive.

You’re an executive at this company. Creating the software was your idea. You are responsible for the ROI calculations that got the whole thing off the ground.

Your career may rest on the advantage the invention provides, and you are boldly considering opening up the code you’ve created. But first you need to understand why so many of your peers (at company after company) have staked their careers behind open-sourcing what was once their company's secret sauce.

Let's look at some examples. Because I work for Red Hat, I’ll mention a few of our own first. But we’re a different animal, so I’ve looked further into different verticals to find other powerful examples.

Over the last 5 years, Red Hat has open sourced software we've both built and acquired, such as RHEV-M (oVirt), CloudForms (Katello), and OpenShift (Origin). Just as other companies derive value from our software, we also derive some value from individuals/companies extending software, generating powerful ecosystems of contributors both public and private. For example, Studio Grizzly is extending the open source upstream for Red Hat’s Platform-as-a-Service called OpenShift Origin.

Both Rackspace and NASA also identified open source as a way to build better software faster. Their OpenStack project is a living, breathing example of how a project can be incubated within a closed ecosystem (closed in governance rather than code), grow beyond anyone's imagination to scratch an itch that no one else can, and blossom into an incredible example of community driven innovation. As a proof-point, this year the governance of OpenStack transitioned to a Foundation model. I should mention that Red Hat maintains a seat on that Foundation board, contributes significant resources/code to the upstream project, and productized an OpenStack enterprise distribution over the summer.

More recently, DreamWorks has decided to open source an in-house tool they’ve developed called OpenVBD.

It's well known that DreamWorks relies heavily on open source software (Linux in particular). But to have them contribute directly using The Open Source Way, truly deserves a closer look. What could have led them to possibly eliminate any competitive advantage derived from OpenVBD?

While I have no specific knowledge of DreamWorks' particular situation, here are some ideas:

  • The industry moved on, and they’ve extracted most of the value already.
  • They are moving on to greener pastures, driving profit through new tools or techniques.
  • Maybe OpenVBD has taken on a life of it’s own, and although critical to business processes, it would benefit from additional developers. But they’d rather pay artists and authors.

If I had to guess, it would be closest to:

  • The costs/maintenance burden for OpenVBD exceeds the value derived. Set it free.

Now it's the competitor's move. Will they simply study OpenVBD and take whatever pieces they were missing or did poorly? Will they jump into a standardization effort?

The answer may lie in the competitor's view on the first bullet above, and if they have a source of differentiation (aka revenue), outside of the purpose of OpenVBD. If they do, standardizing tools will benefit both parties by eliminating duplicate effort/code, or possibly reducing/eliminating maintenance burden on internal tools. And that will generate better software faster.

This speaks to a personal pet peeve of mine; duplicated effort. Again and again I see extremely similar open source tools popping up. For argument’s sake, let's say this means that the ecosystem of developers spent (# of projects x # man-hours) creating the software. If they'd collaborated, it may have resulted in a single more powerful tool with added feature velocity, and potentially multiplied any corporate-backed funding. That’s a powerful reason to attempt to build consensus before software.


About the author

Jeremy Eder - Jeremy Eder works on network performance for Red Hat's CTO Office, concentrating on low latency. He can be found blogging, or on Twitter as @jeremyeder