The Open Source Enterprise, part 2

Part 2: Meeting and managing customer support expectations on open-source projects

 

This is part 2 in a series that shares the journey of F5 Networks towards becoming a member of the open source software community.

 

What to support…

From a customer perspective, every product should come with at least some level of support.  When releasing open source software, be transparent and open in declaring what is supported, and how.  The OpenStack solution combines commercial and open source products into a ‘blended deployment’.  Even within F5’s OpenStack product set, some are purchased (BIG-IP) and some are free under the Apache License (F5 OpenStack LBaaSv1 and LBaaSv2 plugins), but all products will receive support (more on that later…).

What makes a product…

We’ll define a product as a piece of hardware and/or software that provides a collection of domain-relevant features.  F5 makes ADCs, which do lots of things, but at the moment we'll only focus on the BIG-IP LTM module and the F5 LBaaS software packages required to integrate BIG-IP into OpenStack.

In the near past, the F5 LBaaSv1 plugin was closed source and community-supported.  It was not treated internally as a “product”, even though our customers used it as such.  F5 LBaaSv1, and newer offerings including LBaaSv2 and Heat, are now located publicly on github.com/F5Networks.  The end-goal is to market and support them as standalone products.

Traditional support model…

Companies that create products typically have internal organizations dedicated to training and supporting customers.  The virtual support team commonly includes representatives from the (literal) support, product, and marketing departments.  It covers both pre- and post-sales support.  The support hierarchy is built like a pyramid with horizontal layers: support staff receive and work through a majority of customers issues, escalating a relatively small number of issues up the chain to the product team when necessary.  This works fine for a black-box product with finite (not necessarily simple or small) number of inputs and outputs.

Paradigm shift…

What we’re seeing with F5 open source code for OpenStack is a more advanced, technical interaction with customers.  F5 OpenStack software actually consists of multiple, dependent software packages bundled together to present a product.  Customer support requests range from installation and configuration, up through a need for deep understanding of the software.  The latter can only be reliably covered by individuals with intimate knowledge of how the product works.  It doesn’t fit in well in a support team with expertise around what the product provides a customer.

Support model evolution…

Given this more technical nature of customer requests, successful support of open source products requires a rebalancing of the support model.  The more support requests require input from the product team, the more difficult it becomes to maintain the wall around the team that enables them to focus on building more widgets.  It is also harder to set boundaries around pre-sales engagement, in our case mostly due to the sheer complexity of an OpenStack deployment.  The pyramid base is contracting, moving more support requests to higher layers.  We’re also seeing an evolution that blends and overlays horizontal layers (escalation) with vertical lanes (entry points into the product).

Setting expectations…

OpenStack is a large, complex software solution with a steep learning curve.  Customers have a reasonable expectation that when they need assistance with a product, the company behind the product is able to provide support.  In the case of OpenStack, we’re not just seeing a need to support BIG-IP and its integration into OpenStack.  We’re also seeing a need to develop expertise in the overall solution to answer customer requests for guidance.

Ultimately, it doesn’t matter what role open source plays in the product.  When combining commercial and open source products in a solution, the support story gets complicated.  Companies need to (re)build the organization to accommodate a richer, broader range of customer interactions.  When the separation between pre- and post-sales support is no longer convenient, the story need to evolve to embrace a more holistic approach.  There are many benefits possible when building a cross-functional team with the collective experience to support the product or solution throughout its lifecycle.