It Takes a Village to Raise a Child

It takes a village to raise a child. Or so the old saying goes. Creating a product is the same. It takes more than small group of developers (or parents) to raise a product. There’s a lot more to creating a product than writing an application. Don’t mistake a feature or application for a product.

Look, Six Engineers Created a Product!

People hear about new applications or protocols, or small companies selling for millions. They then leap to conclusions:

“Why is it that big vendors like Cisco need thousands of people to create a product? Facebook can put 6 engineers on a project and produce something like Open/R. It’s easy, right? We don’t need big vendors any more!”

“Look at Instagram - they only had a dozen people and they sold their company for $1 billion dollars! You don’t need any more people than that.”

Let’s look a bit closer at Instagram. How much revenue did they have? Zero.

How long were they in business for? A couple of years. So how many generations of product were they supporting? One. And did they have complete support structures for users? No. How many products had gone through end of life? None. In how many countries had they figured out how to sell their products and handle payments? Wait, they had no revenue, remember?

How many people do you think Facebook now has working on Instagram, and all the related services? My guess is thousands, and it’s not even a product. It’s a feature of the broader Facebook group of applications.

Hell, it’s so big & complicated that they’ve outsourced their product design to Snap.

This is not to take away from what the Instagram founders achieved. They got a big payout, and millions of people use their application. Good on them - they can now do whatever they want with their lives.

A Feature Does Not a Product Make

But don’t confuse a feature or application for a product.

Creating a complete product, and a sustainable business is bloody hard. Consider some of the things required for managing the lifecycle of a network device:

  • Initial product planning & investment.

  • Hardware selection, planning, testing.

  • Software development, including third-party library selection and licensing.

  • Feature planning and prioritization.

  • Testing features and combinations - not just a minimal set, but any that customers might use.

  • Testing optics.

  • Documentation.

  • Hardware testing.

  • Certifications and Compliance.

  • Export compliance agreements.

  • Responding to detailed RFPs.

  • Pricelists, order handling.

  • Understanding legal frameworks in different countries.

  • Shipping.

  • Product Education and Training.

  • Support: Diagnosing bugs, or answering simple questions because users don’t read documentation.

  • Hardware spares, diagnosing failures and managing replacements.

  • End of Life, including support for years beyond End of Sale.

The list goes on…

Do We Need All That?

You could argue that some of these things are not necessary. E.g. Do we need a traditional salesforce to sell products? Can’t we sell online at a fixed price? What about support - why do we need full hand-holding support organizations? If we all used Open Source software without paying for it, it would make everything else easier. Not having to worry about revenue dramatically simplifies things. There is of course the tiny problem of “Who pays for ongoing development?” but we’ll gloss over that for now.

Users have options. In the networking market, users can choose from vendors or Open Source software with whitebox hardware. Or they can develop their own hardware and software. Not everyone wants to do that. Given the relative costs, effort and rewards, the majority of the market chooses commercial products from vendors. They could choose something else, but don’t. They decide the price paid is worth the time and investment tradeoff.

Is that changing? Yes, it is, and will continue to do so. Open Source options are evolving, and large network operators are able to extend these to suit their needs. As they continue to evolve, Open Source options will address a wider section of the market. Vendors will also continue to evolve their products. Customers will choose the option that makes the most sense for their needs.

It’s not all going to change overnight because someone releases a new network application. There’s more to it than that.

Back to Open/R

Facebook first started talking about Open/R in May 2016.

But it wasn’t until November 2017 that the code was released. What was released is not in itself a complete solution. How many businesses could take that, and actually deploy it today? Very, very few.

Does this mean it’s not useful? Of course not. I don’t want to pick on Open/R at all. I find the concept exciting, and I love that users are able to develop their own features, without relying on vendors. But don’t think that it’s going to straight away change the way the industry works. Because it’s a long way from a complete product.

Users Don’t Become Developers Overnight

On a related note, if you think that all network engineers should become developers, you’re dreaming. Some people will write their own applications, but most won’t. System Administrators didn’t become developers overnight when Linux came along.

Most Linux users have never contributed any code. Most don’t even use it because of the freedom that access to source code provides. They use it because it’s free as in beer.

The Linux ecosystem didn’t develop purely through users contributing applications. Distributions played a key role in pulling together a set of applications and features, and turning them into a product. They did the hard work, the often thankless work, the things no-one else wants to do.

That’s what developing a product means. Creating useful features, or an application, is not easy. But it’s one part of a complete product. Don’t confuse an application for a product.