Why did Network to Code Fork NetBox?

[This post was reviewed and edited by many of the people who have contributed to the Nautobot project at Network to Code.]

Over the last five years, NetBox has gained adoption as an IP Address Management (IPAM) and Data Center Infrastructure Management (DCIM) platform while also serving as a Source of Truth for documenting networks and network automation projects. In fact, Network to Code has been heavy users, supporters, and contributors of NetBox for years. While we started offering NetBox professional services in 2018 and support for NetBox in 2019, we have continued to support an ever-growing customer base that has evolving requirements around Source of Truth and more broadly around creating holistic network automation solutions. Because of this, and in order to better serve our customers and the community, Network to Code made the difficult decision to fork NetBox and drive it in new directions.

Let’s dive into the details.

Background

Network to Code has been a power user of NetBox for the past 3+ years. We’ve designed and deployed numerous solutions that revolve around and integrate with NetBox. We have used the existing models, extensibility features, worked on a myriad of private customer-specific forks, created ways to manage settings and URLs, as well as created plugins for various use cases. In short, over the course of countless projects, we have seen first-hand what works well for users and what has room for improvement.

There have been questions raised in different public forums if Network to Code has been a contributor to NetBox. The answer is yes. Let’s explore some of those contributions.

First and foremost, as part of the NetBox community, Network to Code has contributed numerous blog articles, published videos, hosted a NetBox Day, presented at conferences, enabled and participated in innumerable Slack discussions hosted on the Network to Code Slack workspace, participated in podcasts, hosted low-cost training, and more. While all of this was not hand-to-keyboard development, NTC has undoubtedly contributed thousands of hours toward NetBox in this capacity in recent years.

For contributions to the core of NetBox, NTC employees (not counting the lead maintainer of NetBox, who was employed by NTC for 18 months and spent the majority of his time actively maintaining NetBox during that time) have contributed 78 issues and 35 PRs, two of which are still being worked on. Some of these contributions have been significant in scope, such as the initial implementation of the NetBox plugin API that was released in NetBox 2.8.

When you look at code and development, there are NTC projects that also build on top of NetBox. We have built a Device Onboarding plugin, Prometheus metrics plugin, a number of other plugins that we are working to open source, as well as projects like network-importer to simplify adding data into NetBox. Each of these projects individually are the result of hundreds of hours, adding up to many months of dedicated development effort.

While we have never claimed to be an official sponsor of NetBox, we were effectively an unofficial and informal sponsor of the project. Lastly, one of the core committers on our fork had also been a maintainer of NetBox for a number of years while at Network to Code.

We have always had candid discussions on feature requests, support, and on the direction that we believed was in the best interest of the long term success of NetBox. As time went on and after numerous discussions, there became a growing divergence in our vision about what a Source of Truth for networking should look like and how to get there, and the NetBox project team suggested that we should consider forking. Late in 2020, we took a step back to think about the options.

Taking what we’ve learned deploying and integrating NetBox solutions for customers over the past few years, what we have seen and heard from the community, coupled with discussions with the NetBox project team, Network to Code came to the conclusions that it was best to fork NetBox with the vision and direction necessary for powering network automation platforms. Next, from a business and technical perspective, let’s explore the key reasons we considered and what drove us to make the decision.

We need to provide world class support for our clients.

We need to offer high-touch support models with Service Level Agreements (SLAs) we can guarantee. We need flexibility to offer Long-term Support (LTS) for customers who can’t upgrade at the pace of a fast moving open source project. In addition, we need to be able to deliver the features required to get a system into production in an enterprise environment. Some examples include simplifying the ability to integrate with Single Sign-On (SSO) services such as SAML or OIDC and adding support for additional database backends such as MySQL.

Define a strategic vision for Source of Truth that enables network automation.

We firmly believe that a Source of Truth is a fundamental requirement to enable data-driven network automation. This is where we are able to leverage our collective experience at Network to Code and add functionality that simplifies integrating with network automation solutions. While the new platform can still be used for network documentation, its key focus is on enabling network automation. After all, network automation is our core business at Network to Code. It has become apparent through our customer projects that there is a need for more flexible APIs and more seamless ways to integrate with other data sources.

Build a Network Automation App Platform.

This is one area that we think is quite unique. The goal is to leverage the rich data stored in the Source of Truth and build high-value apps that use and consume that data while interacting with other systems and network devices as needed. The best metaphor to consider is a smartphone. It will always be a “phone.” However, this “phone” is a delivery mechanism for high-value apps that we all get to use on a daily basis (should you choose to). In this example, the Source of Truth is the phone, i.e. the delivery mechanism. Our goal is to enable the Source of Truth as a platform through which high-value apps are deployed. These apps can be lightweight (creating new models and APIs) or be used to deliver solutions (pre/post change, integrate with monitoring, perform backups). We believe it should be up to the users to decide.

Community Committed

Network to Code has deep roots in the community. As mentioned earlier, we have spent thousands of hours on community work around NetBox. If you look at every other project we’ve been a part of, that number goes up significantly. From open sourcing various projects of our own to contributing to other such projects to engaging in discussions on numerous forums, community is extremely important to who we are as a company.

We know there is A LOT of work to do to gain the respect and trust of the community as we move forward with Nautobot. We are committed to fostering user and developer communities that are fully transparent. We will be hanging out in the #nautobot channel on the Network to Code Slack. Please come join and let us know what you think! You can also view the initial Nautobot roadmap.

If you have ideas, enhancements, or feature requests for Nautobot, please don’t hesitate to open an issue on GitHub.

Going Forward

Just to get us where we are with Nautobot, we have invested close to a “work year” of effort across our team just over the past few months. This effort and focus is not going to stop. While Nautobot is much more than NetBox with additional features, it’s actually not even about what you see today. This is just the first release. If you haven’t already done so, please check out the roadmap. You’ll see that our goal is to empower flexibility and extensibility while truly being a Source of Truth foundation for network automation. Our vision will see Nautobot continue to diverge from NetBox in such a way that the separation of the two will become much more distinct.

Git History

When we first released the Nautobot project on GitHub, we had made a decision, based on technical considerations, to not keep the complete NetBox commit history. It was never our intent to “erase” the NetBox commit history because that history exists within the NetBox project and we are making every attempt to be fully transparent about the forked status and attribute proper credit. We have heard your feedback that this can give the appearance of dismissing the history and community engagement that has brought NetBox to where it is today, and we apologize for that. We are grateful and we are re-adding the NetBox Git history to Nautobot. Below are the technical reasons we had in mind when we chose to reset the commit history.

First, we thought that it would make it possible to draw a clear dividing line between the development of NetBox and the development of Nautobot so there would be no ambiguity as to whether a given commit in the Git history is a shared NetBox commit that was inherited by Nautobot, or whether a commit is specific to Nautobot and distinct from NetBox. This would make it easier to see over time how the two projects have diverged.

Second, we wanted to avoid any ambiguity about version numbers. Creating a new repository from our own version 1.0 allowed us to avoid these collisions and confusion without needing to do anything messy like deleting old tags and releases from the history.

Third, we have made a large number of invasive changes related to packaging and renaming which greatly reduce the historical relevance of the history from a purely technical standpoint.

Fourth, it reduced the size of the repository substantially. A fresh clone of nautobot.git is only about 28 MB in size, versus a fresh clone of upstream netbox.git weighing in at about 185 MB.

We remain grateful to all developers of and contributors to NetBox, and hope that this provides appropriate clarity as to the reasons why we initially chose this particular approach.