Why Open Source Kicks Butt for Incremental Innovation

February 9 2012 | By | in Open Source

Open Source absolutely kicks proprietary software’s butt, when it comes to incremental innovation. Yes, I just used incremental and innovation together, in a phrase. Now, please humor me, as I elaborate.

Having been in Product Management & Product Marketing for a couple of decades, I’ve been through a few new product launches – and I don’t want to talk about those. What I want to talk about is small tweaks to a product, and I’ll specifically use Systems Management, to illustrate my example. Lets say that two systems Management software companies, company “P” (proprietary) and company “O” (Open Source), want to extend their product to support monitoring a new line of servers – let’s call them “Gizmo” servers. Here’s how company “P” would launch support for the new line of “Gizmo” Servers:

Typical Commercial Systems Management Software Extension project

  1. Get in line phase (1-12 months) – Marketing and/or Product management put support for monitoring “Gizmo” servers on their radar
  2. Thinking about it phase (1-6 months) – Product Management familiarizes themselves with the new “Gizmo” servers, and drafts a MRD/PRD
  3. Writing it down phase (1-6 months) – The aforementioned MRD/PRD bounces between PM, Development, and other teams
  4. Actually developing it phase (3-6 months) – Development familiarizes themselves with “Gizmo” servers, and begins to develop the extension
  5. Fiddling with it phase (3-6 months) – QA and various other parties familiarize themselves with “Gizmo” servers, and attempt to install one or more in the lab. Ideally, this happens in tandem with development, but budget and prioritizations often cause a lag.
  6. Seeing if it’s completely broken phase (1-3 months) – QA tests “Gizmo” server, in the lab. And Development refines, based on those tests.
  7. Seeing if it’s anywhere close to what the customer actually wants phase (2-6 months) – Beta testers, with production “Gizmo” servers are identified, and recruited. Usually, because the product was developed and tested against a sterile, non-production version of the “Gizmo” server, the beta gets kicked back to development and QA. And several more months and iterations may be required.

So, if you’re keeping track, that’s 12-46 months, to add any new extension. If you think I’m exaggerating, or clueless about this, please think back on vendor roadmap presentations you’ve sat through. But the most important part of this whole timeline is that most projects don’t pass through step #1, meaning while they’re on a vendor’s radar, many extensions may never get funded or prioritized.

For an Open Source platform, steps 1-4 are skipped entirely. Furthermore, steps 5 and 6 are truncated, as the developer is already an expert in “Gizmo” servers. Since they put it out for the community to test, steps 6 and 7 are arguably truncated, as well. But the most important part is that step #1, where the majority of incremental innovations die, is eliminated entirely. A community developer recognizes a need to support something new, and they just build it.

I am not saying that traditional commercial vendors can’t be innovative; I’m saying that innovation requires a considerable amount of overhead. This is because there’s an opportunity cost to every new capability added, and every new innovation tends to add additional support & complexity baggage. And the overhead to innovation ratio is especially noticeable forsmall innovations, (eg. adding support for monitoring a new type of server), where a company may waste several times as many man-hours on such overhead,than in actually developing the new stuff. This is why many of these small innovations tend to sit in commercial vendors’ queues, until they’re no longer relevant or needed.

Zenoss customers get the best of both worlds with a packaged commercial product that has been buttoned down and tested & vetted every way till Sunday. Not to mention, an open source core that they’re free to innovate and extend, as they wish.  And this is why I’m now happy to be associated with an open source project, where innovations like Zen Packs are both allowed and encouraged.

Image via The Telegraph