During our 'day jobs' advising large enterprises, services providers, network vendors, and software developers on strategies and execution options for their SDN ambitions, we are routinely asked questions about pursing an open-source business model or participating within an open-source SDN ecosystem.  The 'right' answer is dependent on a combination of factors including the organization's short and long-term goals, position in the market, and strategic importance vs marketing importance of SDN to sustain their long-term business -- and is different for every organization.

We emphasize is that before making an investment decision to pursue (or not pursue) an open-source strategy -- it's important to understand the alternative paths and respective pro's and con's from a customer and partner value creation perspective.
Customer Value Creation:

Customer value creation is defined as the place in the ecosystem where value is created for the end customer (say an, enterprise or service provider); such as delivering a new capability or connecting an open source technology to an existing process or system.

For customer value to be created on a large-scale, a project typically needs to posses some combination of attributes including: a) stability and transparency in the stewardship of open source project; b) code to work as advertised; c) integration into existing IT environment; d) solution support (i.e. one throat to choke for the entire solution), and e) broad developer community available on the open market (to avoid lock in and hire to adapt to specific needs).

Partner Value Creation:

Partner value creation is defined as the place in ecosystem where value is created for supporting organizations (like a software developer, systems integrator, VAR, etc) of a specific ecosystem; such as delivering a service or software add-on to the open source project.
For partner value to be created, a project typically posses attributes including:  a) stability and transparency in the stewardship of open source project;stable ecosystem; b) enough customer momentum so that it attract new users / customers to a partner solution; c)  a broad development community (i.e. a large pool of developers available for hire); d) for developers, the open source software should reduce their internal software development load; and e) assurances that the open source project will not compete with partners who are expected to use the open source software.

Types of Open-Source Ecosystems

To determine how to create customer value or where to locate opportunity to create partner value in an open source driven ecosystem, first you have to understand the structure of the open source ecosystem.  There is a range of open source ecosystems, which generally can be simplified into three types:

Loosely Aligned and Foundation Managed Projects

Generally speaking, the most impactful open source projects tend to be Foundation Managed and many of the Foundation Managed open source ecosystems started off as a Loosely Aligned projects.  Loosely Aligned projects often morph into a Foundation Managed model due a strong independent community that grew from the ground up with a clear customer value proposition and transparent partner rules of engagement (which defines the boundaries where a partner can and cannot make money).  Typically Foundation Managed open source projects can support a number of venture-backed companies that each play a unique role in the ecosystem.

Vendor Dominated Projects

Vendor Dominated open source projects are projects that are dominated by a single (usually commercial) organization who directly (via employees) or indirectly (via paid contractors, students whose professor(s) encouraged them to contribute to his/her project, semi-autonomous organizations that are dependent in large party by a vendor for funding, etc) provide more than 50% of contributions to an open source project.  Additionally, the vendor who leads an open source project -- need to find a source of revenue -- which could be a) support services (like Red Hat for Linux); b) up-selling to a commercial version of the open source software (Big Switch with the Floodlight Controller); or c) building apps on top of the open source software (Big Switch with Firewall or CircuitPusher for Floodlight).

Few Vendor Dominated open source ecosystems transition to Foundation Managed because the bulk of the engineering talent and contributors to the project work for the vendor -- which limits diversity of the development community and opportunity to grow expertise outside of the organization sponsoring the open source project.

What does this mean to the SDN Community?

SDN Open Source:  Primarily Vendor Dominated

If we look at the most popular SDN open source projects toady we see that they are primarily vendor dominated, including:

• Floodlight: Big Switch
• LINC:  InfoBlox
• Open vSwitch:  Nicira (now VMware) (See our post on Open vSwitch)
• Trema:  NEC

For example -- even though OpenFlow is driven by the Open Networking Foundation (ONF)-- there isn't any software produced or managed from the ONF today - making the ONF dependent on Vendor Dominated open source.

SDN Open Source:  Potentially Risky Business Proposition<

For aspiring SDN start-ups, established networking or virtualization vendors, software developers or even end customers; these Vendor Dominated open source projects are risky projects to place strategic focus and investments in, due to:

1. Rules of engagements are set by one organization which can be changed at anytime with a lack of transparency around how decisions are made about the project or sometime even how or why contributions are accepted or rejected.
2. Acquisition of the dominating vendor in an ecosystem by a less friendly company puts entire ecosystem at commercial risk (ala MySQL via Sun to Oracle; Java (again Sun) to Oracle; or in the SDN space Open vSwitch from Nicira to VMware).  There are plenty of plays the acquiring company can run:  such as changing licensing terms for future versions to slow rolling acceptance of 3rd party contributions or standards.
3. Business model always favors the dominating vendor -- by definition a vendor dominated project is organized to make the most within the ecosystem for the vendor that dominates it.  They also have the power to change their rules that adversely impact other members of the ecosystem.  This is one reason why it difficult for companies supporting a Vendor Dominated project to raise venture financing -- meaning what venture investor is going to invest in company that is dependent on another company that may compete with them in an early market?  One common trick the dominating vendor may play is encourage people to write apps for their project -- only to write their own version of once the 3rd party app has customer traction.

This risk applies to both customers (potential lock-in that worst than many commercial licenses) and partners (potential future lock-out and uncertainty of financial return).  The customer risk is mitigated -- if the application is a tactical application with many alternatives.  One example, is SNORT which is dominated by SourceFire where IDS is tactical and there are many alternatives; though has a relatively small partner ecosystem.

Partner risk with Vendor Dominated open source is more challenging -- especially given the lack of transparency in decision-making  process; lack of external developer community to which to leverage to expand your internal capabilities, and risk the dominating vendor is acquired by a company that isn't friendly to your organization.  Remember MySQL.

Biggest Risk to SDN: Broad Customer and Partner Adoption of Floodlight and Indigo

To demonstrate the above-mentioned points, let's just pick Floodlight and Indigo as an example (you could apply this logic to any other Vendor Dominated project). Say both become broadly adopted - if I was in Cisco corporate development -- and realized that a) Floodlight and Indigo are open source projects dominated by Big Switch; b) who had locked up the most knowledge developers of those projects; c) and was convincing Cisco competitors to rely on Floodlight and Indigo for their SDN Strategies; while d) being the closest code to an OpenFlow reference implementation that the ONF is largely dependent on today -- I could easily make a business case to John Chambers to spend $1B to acquire Big Switch; make it part of onePK.This would likely kill OpenFlow and any other emerging SDN standard -- as Cisco by marrying the Cisco install base and channel with a path to installed base programmability via control of Floodlight -- Cisco would over night have a credible SDN story with upgrade path for a large portion of the market.

This is why being a customer or partner with Vendor Dominated open source could be hazardous. The same, nice, cool company that you enable and help grow, once acquired by your large supplier or rival, will turn the net positive to either further vendor lock-in, or a dangerous weapon against you.

Conclusions:

The problem we face in the SDN market is tricky -- the open source that may help SDN get started; maybe the same open source with potential to kill the market opportunity as the more a Vendor Dominated open source project is adopted the more risk it brings for most members of the ecosystem.

If you are a customer with a tactical problem -- working with Vendor Dominated open source is a great solution to get you started and experiment with.  If your problem has the potential to be strategic to your business -- look at other alternatives that may provide a large, non-vendor dominated base of developers and integrators -- or price in the risk of vendor lock-in to your long time supplier financial models.

If you are a prospective partner for a Vendor Dominated open source project, tactically partner with a vendor who dominates your open source of choice to be 'in-the-flow-of-customer-information' and use cases.  If customer interest warrants, leverage that partner to provide a stop-gap solution while you buy or build your own.  Realize that if this open source project is successful - that your largest competitor may likely acquire the open source ecosystem your business is / becoming dependent on.

If you are the ONF -- create a reference implementation of OpenFlow before it's too late -- see our thoughts for LibOF.

If you are Cisco -- I'd be surprised if you are not looking at Big Switch already.  If you are a major network or virtualization vendor not named Cisco or VMware -- the market is early and there are plenty of alternatives; start identifying and engaging those alternatives before it's too late.

Lastly, the how and to what level you engage with Vendor Dominated open source may not be a straight line.  Remember that one size doesn't fit all and what maybe right for you today, may not be right for you tomorrow, or what's right for your competitors today will be different from tomorrow.  Focus on creating customer value and if you choose to engage with Vendor Dominated open source -- start working your back up plan.