So you’ve decided to embrace open source in your organization. You’re sold on the big-picture benefits of open software: Eliminating vendor lock-in. Tapping the innovation and problem-solving capacity of a broader community. Giving yourself the flexibility to adapt your network as you see fit rather than as your vendors dictate.
Excellent, welcome to the party! But you probably have some questions. Like:
- Where does open source fit best in my network?
- Which projects should I prioritize?
- Where the heck do I start?
Those are all excellent questions. And the short answer to all of them is, it depends. Every network is different. Every organization has its own unique business priorities and brings its own mix of skills and experience to the effort. Having worked with service providers around the world to implement open source in production networks, however, we can offer some common guidelines to help you think through the process.
Remember the big picture.
If you look at some examples of what different Communication Service Providers (CSPs) are doing with open source software, you might imagine they’re attacking entirely different problems. Verizon, for example, is using OpenDaylight and OpenFlow to deliver provider edge functions. Telstra is using it to support a nationwide transport network for analytics and telemetry. Meanwhile, AT&T led the charge to build an open-source framework for the entire network architecture through the Open Network Automation Platform (ONAP) project.
Look at these projects from a distance, and you might think they have nothing to do with each other. Peer under the hood, however, and you realize they’re fundamentally the same. Each operator is using the same basic open source technology (in this case, the OpenDaylight SDN controller) just implemented in different ways to support different goals.
That’s OK—that’s exactly how open source is supposed to work. Unlike more fully “productized” solutions built to be used in a specific way to deliver specific outcomes, open source technologies are meant to be adaptable. They’re more like a set of ingredients (if you will) than a fully-cooked meal. It may take more effort to do the cooking yourself. But in return, you retain the freedom to cook up exactly what you want—to use those open source software components however you choose to support your unique business priorities.
Do something with business impact.
Recognizing that you have lots of flexibility, where is the best place to start using open source? Again, the answer is different for every company. But one piece of advice that applies to everyone: wherever you start, make sure it’s an area with real business impact.
Don’t get into open source as a research project. That’s been done a million times before, and you’ll end up wasting everyone’s time; kick off your project in an area that will have a meaningful effect on your business. That way, you have something at stake—and you have a tangible framework to make decisions and evaluate how those decisions pan out.
Choose a project that will make your vendors take notice.
So where in the network you should focus? An excellent place to start is an area where you can compare open source components against incumbent vendors.
When you look at the CSPs making significant open source investments, invariably they pilot them against network vendors they already work with. Maybe you’re piloting OpenDaylight for edge routers where, until now, you’ve been using Cisco or Juniper. Or, maybe you’re piloting an open source analytics platform which you can compare with what you’re currently spending on Splunk or LogLogic.
By launching your open source project in an area like this, you’re planting a flag for your vendors. If you want to participate in this part of my network in the future, you’re going to have to adhere to common standards, and you’re going to have to compete. Now, you have a real, tangible comparison to evaluate the impact of your project. Are you getting better pricing from your vendors? Better support? More time and attention?
Choose the right open source project.
It should go without saying, but not all open source software is created equal. The reality is, anyone can publish code under an open source software license that people are free to download and use. The kinds of projects CSPs should stick to, however, are efforts backed by large, active contributing communities.
Remember, one of the main rationales for using open source in the first place is community innovation. When you work with software like OpenDaylight, you’re using code that hundreds of the smartest minds in the industry have developed and tested and validated. And, as an active contributor, you can go back to that community when you (inevitably) hit roadblocks in your integration.
Effectively, for every dollar you put into open source (in time and effort you devote to integrating and troubleshooting the code for your network), you’re getting back three via the efforts of the rest of the community. Choose a small open source project without that kind of backing? Now, you are the community. And the only one contributing to solving your problems is you.
Enlist the right partners.
Part of the beauty of open source is the ability to work with innovators in new ways. Not only can you solve existing problems, but you can reimagine new opportunities and have the flexibility to make it happen. While transitioning to this software world that will empower a new DevOps mentality, you need a portfolio of partners to support your transition. Lumina Networks’ NetDev team leverage their leadership in the open source community and agile methodology to help customers transform. Through agile sprints, we co-produce a strategy to suit your business needs while transferring open source and software knowledge to your transitioning team.
Learn more about Lumina NetDev Services and why we’ve been proven to partner with operators around the world.
Next week we’ll dive into the RFP process to help you understand how to properly engage the open source community in your transformational projects.