Apache Authors: Yeshim Deniz, Pat Romanski, Lacey Thoms, Sandi Mappic, Michael Bushong

Related Topics: Open Source

Open Source: Blog Post

The Key to OpenDaylight Adoption: Salespeople

Open source adoption

The primary indicator of success is success. That is to say that the number one thing people look to as a predictor of future performance is past performance. In the product space, this means that things like adoption are important as much for what it signals to other people as they are for bottom line revenues. And this is true even in the open source world.

As SDN speeds its way towards mainstream adoption, this means that projects like OpenDaylight will need to establish early on that they are not only deployable but also deployed.

Open source adoption

People frequently point to Linux as an example of an open source project that has seen wide adoption. But even Linux adoption did not happen overnight. It took more than a decade to see growth. And if you look at RedHat as an indicator of when that growth spawned commercial success, you have to extend all the way out to 2012 before the first $1B fiscal year.

The point here is not that Linux was not successful but rather that it took time to become successful. And the more success there was, the more success there tends to be. The rise of RedHat has enabled an acceleration of Linux deployments, in part because of an improved support model but in part because it represents a visible measure of commercial viability.

OpenDaylight and adoption timelines

Now consider that Linux was largely unknown and had virtually no expectations around it when it was created. There was no market that was waiting for it to hit. There were not industry players banking on its commercial success. There was not an entire technology movement underway dependent in part on the rise of a vendor-neutral platform.

The conditions under which OpenDaylight has been incubated are markedly different. And that means the expectations are different. Imagine how OpenDaylight would be evaluated if it took more than a decade to reach any kind of adoption. The pundits would not be kind, the customers would not be happy, and the companies expecting OpenDaylight to contribute to their commercial success would not be satisfied. OpenDaylight simply has to accelerate adoption.

What the bulls would say

Those bullish on OpenDaylight will tell you that conditions are certainly different. Open source is a better understood beast than it was in the early 90s. The lessons learned by those that championed Linux should result in faster adoption for projects that follow, and having the very group responsible for Linux (the Linux Foundation) at the helm only makes those lessons easier to put to use. There is an entire consortium of industry giants and would-be giant slayers who are building products and an ecosystem around OpenDaylight. Marketing efforts are helping drive awareness in both the vendor and user communities.

There are absolutely reasons to believe that adoption will happen faster than it did the first go-around.

What the bears would say

But there is a case to be made for the bears as well. SDN is more than a new technology; it’s a new architecture. Migration between architectures is far more disruptive, and thus more risky. The only way to mitigate risk is to move even slower, waiting for others to pave the way. And with a much lower volume of customers to pull from, this means that there will be fewer success stories early on and less overall experience to rely on. On top of that, while the consortium of companies is building products, they continue to sling their legacy portfolios that compete with the very thing they are collaborating on. Can they possibly be expected to push forward aggressively?

The missing ingredient

So what is missing for OpenDaylight to be successful?

In a word, deployments. But how do solutions get deployed? In the networking world at least, the answer is that they are pushed by the people building and ultimately selling them. Whether that’s the vendor itself or the resellers working on its behalf, there is someone on the end of the sales cycle who is explaining to the customer why and how they should deploy the solution.

Who is going to do that for OpenDaylight?

Right now, the answer is unclear. The most obvious answer is that OpenDaylight needs a RedHat to help speed deployments. In the OpenDaylight case, RedHat seems like the likely company to be RedHat. They are already OpenDaylight contributors, and they understand the business model well enough that they should be able to take a page from their own playbook.

But RedHat doesn’t own the networking channel or have the networking street cred. It’s not that they cannot be successful, but it will take more than RedHat to sell OpenDaylight.

Of course, the individual vendors all have a stake in OpenDaylight as well. Maybe they will make up the salesforce? Perhaps. But there is a challenge here. OpenDaylight is not really a revenue generator (at least not right away and not directly). Individual salespeople are compensated on the revenue they bring in. They don’t have a personal incentive to promote an open source project. More tactically, even if they wanted to, they aren’t fully trained on how it works and how they ought to be selling it. And even then, whatever they do know will be specific to the context in which the rest of their product catalog functions. A huge part of the value of OpenDaylight is that it works in heterogeneous environments and has technologies contributed from a bunch of different players. No salesperson is ever going to promote those aspects as aggressively as their own products.

What is needed?

If the problem is similar to a sales problem, then the solution will resemble a sales solution. Adoption will hinge on marketing to drive awareness and field enablement to drive sales capability. The first one is already being done with great effect, but the second one is missing. It’s hard to enable a salesforce that doesn’t really exist.

My suspicion is that the very thing that makes OpenDaylight powerful from a development perspective will swoop in to help out here: namely, the open source community. If community members who are leading adoption become active ambassadors for OpenDaylight, they can take the role of a Systems Engineer (SE) and help speed along deployments.

Engagements will be a little bit tough. Pairing ambassadors with active opportunities is non-trivial because it requires the customer to seek counsel from an ambassador they do not know while being presumably in a sales cycle that is led by vendors who are pushing alternative solutions. Fortunately, the biggest thing OpenDaylight can help do here is right up its alley: provide transparency. If customers are active in registering OpenDaylight opportunities, the Linux Foundation can pair ambassadors with those seeking guidance.

The bottom line

The industry needs a neutral point of control, and having every company reinvent and maintain a common platform is silly. Open source is a great way to advance the industry while limiting overlapping investment on the vendor side. But for adoption to take place, adoption has to happen. OpenDaylight can do something to solve this chicken-and-egg problem. Ultimately, if OpenDaylight is successful at providing opportunity transparency to its community, everyone benefits.

[Today’s fun fact: A group of geese on the ground is a gaggle, but a group of geese in the air is a skein. This is to flocking hard to remember.]

The post The key to OpenDaylight adoption: salespeople appeared first on Plexxi.

Read the original blog entry...

More Stories By Michael Bushong

The best marketing efforts leverage deep technology understanding with a highly-approachable means of communicating. Plexxi's Vice President of Marketing Michael Bushong has acquired these skills having spent 12 years at Juniper Networks where he led product management, product strategy and product marketing organizations for Juniper's flagship operating system, Junos. Michael spent the last several years at Juniper leading their SDN efforts across both service provider and enterprise markets. Prior to Juniper, Michael spent time at database supplier Sybase, and ASIC design tool companies Synopsis and Magma Design Automation. Michael's undergraduate work at the University of California Berkeley in advanced fluid mechanics and heat transfer lend new meaning to the marketing phrase "This isn't rocket science."