You may recall back at February’s Networking Field Day event that there was a big announcement from Network to Code regarding their use of Netbox and the move to a new platform they call Nautobot. The announcement came with a bit of community kerfuffle about how to handle open source projects, forks, and ultimately what role developers and maintainers can play in the wider community. Now that the uproar seems to have died down a bit, I wanted to wade into the discussion a bit and talk about why I think this is a good move overall.
Working For Your Living
Open source projects are great. They allow people to build software that can be used by the widest number of people with the lowest barrier to entry. You can pull resources from across the world to help you build something you wanted to put into the world. And when developers get the support of like-minded organizations looking to capitalize on the momentum of a project, it’s like a dream come true. You get to turn your passion into your day job!
However, you also have to consider something more important down the road. As long as your desire for the software platform is aligned with the desires of the organization you work for, everything is coming up roses. But what happens when those two viewpoints diverge? Before you start stammering, realize that every project that involves more than one person doing work on anything will eventually reach a point where people disagree. It’s the nature of any relationship to find points of friction. Maybe you disagree about a new feature. Perhaps you disagree about a support model. You could even disagree on the mythological creature that the next major release is named after. The point is that disagreements happen.
In a normal open source project, if there is a disagreement between the main developer and one of the other contributors, then someone has to give. Usually, it’s the contributor moving on to a different project or creating a fork of the original project with the intent to keep whatever they wanted or add the new thing they were looking for. One way or the other, there’s going to be some discussion on both sides. But what happens in a fork relationship? What if the company that hired someone to sponsor the project has a disagreement with the lead developer? What happens when the project has to move in a certain direction to keep the customers of the company happy?
I don’t know the details behind the scenes when it comes to Netbox versus Nautobot. Frankly, it doesn’t really matter in the long run either. I know the community was frustrated by some of the execution behind the implementation of Nautobot and how it appeared to be divorced from Netbox. Ultimately, I think the reasons behind it weren’t malicious in nature but instead were just poorly executed and ultimately resolved. Given that there hasn’t been much discussion of it since the launch of Nautobot, I’d say that the purpose wasn’t to cause trouble at all.
Feature Complete
This brings us back to the reason to create Nautobot. I’ve heard people say that it’s not right that Nautobot was created because those are features that could have been added to Netbox easily. I would hazard a question here: Could they? If the discussions happened and the decisions were made to not add certain features for one reason or another, what then? What if the only way to get those features added was to create a new version of the software and add them? I mean, isn’t that the point of open source? I can remember people forking Mozilla browsers to remove branding and other things and simply putting it out as their own. Heck, even the old CentOS Linux was essentially a version of Red Hat Enterprise Linux built from open source with the logos changed.
If Network to Code built a part of their business around Netbox and needed to add features that were necessary in the eyes of their customers, then creating a version of the software that has those features is exactly what they needed to do. As a customer of the company, what would you do if your requirements were shot down with “the other developers don’t want to add the feature”. Would you leave? Would you build it yourself? Would you shame them in discussion forums? I don’t know the solution, but any customer out there wouldn’t accept “someone doesn’t want to do it” as the answer to their issue.
Features are added to software every day. Some are huge and important. Others are designed to embrace new technology or methods of doing things. Still, others are dedicated to laying the foundation for changes on the horizon. Whatever the reason for those feature additions, it has to be assumed that they’re included for a good reason. If there is a discussion and a plan for implementation, then they need to be included. If someone in the process has the power to invalidate those changes or their implementation, then a good reason needs to be given. And ultimately, the developer and the business need to decide what’s best for them. In this case, I think both Netbox and Network to Code have done what they needed to do.
Bringing It All Together
The path that Nautobot is on seems to be a great one. More and more companies are building integrations for the software into their automation tools. Community members are adopting it and installing it in their environments. Being backed by Network to Code also ensures longevity as the platform is included more and more as an important source of truth for the network.
Does that mean that Netbox is going away? Absolutely not! There are those that rely on it and will continue to use it and deploy it over Nautobot. But having another choice in the matter is good for networking professionals. They get to decide what features they need and know that they can make requests that can get fulfilled and implemented. Forking open source projects isn’t always fun but it can be necessary. I think the path that Nautobot is taking is the one that will end up well-traveled.
To find out more about Network to Code and Nautobot, make sure to check out the Nautobot project page.
