The 2021 Olympics in Tokyo have officially kicked off and each night on the West Coast you can watch delayed broadcasts of events you’ve already gotten alerts about 12 hours earlier. The S&P 500 markets are reaching new records, cryptocurrency bulls finally woke up as BTC surpassed $40K for a few days, and the private venture capital markets seem to be blowing past record highs every week.
This week we spoke with Jeremy Stretch from NS1 who created Netbox, an open source infrastructure resource modeling application designed to empower network automation. Jeremy speaks about the genesis of Netbox, building a community (8,000 stars+) and how they plan to build on that success by supporting the technology within NS1.
We also caught up with Bryan Kirschner, Vice President of Strategy at DataStax on their State of the Data Race 2021, where they surveyed 500 enterprise leaders on a series of different data-related questions. A couple of key findings emerged including 1) The need for speed and continuous business intelligence trumps everything 2) Individual business leaders are now the “general manager of data” 3) Everyone says they have a data strategy, but very few companies have a delivery strategy for customers. Download the report and check out the findings!
Have you subscribed?
Private Markets
Odoo, the leading COSS business application platform, announces $213M growth equity investment from Summit Partners.
Replicated, advancing multi-premise software adoption, announced their $50M Series C led by Owl Rock Capital.
Element, the leader of the Matrix chat protocol, announced makers of an analytical API platform, announced their $30M Series A led by Protocol Labs and Metaplanet.
Aleph Alpha, building Europe's largest sovereign AI models, announced their $27M Series A led by Earlybird.
Julia Computing, makers of the high-performance Julia programming language and JuliaHub cloud platform, announced their $24M Series A led by Dorilton Ventures.
Treeverse, developers of the LakeFS data lake management solution, announced their $23M Series A led by Dell Technologies Capital.
Spectro Cloud, making it easy to manage the full lifecycle of Kubernetes environments, announced their $20M Series A led by Stripes.
Cube Dev, makers of an analytical API platform, announced their $15.5M Series A led by Decibel.
Gravitee, the open-source API management platform, announced their $11M Series A led by AlbionVC and Oxx.
Serverless Stack, making it easy to build full-stack serverless applications, announces their $1M Seed round led by group including Greylock Partners, SV Angel, and Y Combinator.
Public Markets
To track the performance of COSS companies, we’ve created an equal-weighted index comprised of public names including: Kaltura (new!), Couchbase (new!), Confluent, MongoDB, Elastic, Talend (acq. by Thoma Bravo announced), Cloudera (acq. by KKR/CD&R announced), Rapid7, Fastly and Jfrog.
Despite adding two new names to the COSS Index over the last two weeks, it continues to underperform the broader markets and has trended flat over the past month.
COSS Index -12%
NASDAQ +14%
S&P 500 +17%
The last two weeks pushed the rolling three-year performance of the COSS Index above the NASDAQ and the S&P.
COSS Index +97%
NASDAQ +90%
S&P 500 +56%
COSS companies traded up over the last two weeks continuing their winning streak over their Emerging Cloud peers. All three indices continue to trade significantly higher than their rolling five-year average.
COSS Index: Current Multiple 15.6x | Five-Year Mean: 8.2x
Emerging Cloud Index: Current Multiple 14.2x | Five-Year Mean: 9.5x
NASDAQ Composite: Current Multiple 4.2x | Five-Year Mean: 3.2x
OSS:
What's your background?
Jeremy:
I was originally a network engineer, got my background in network engineering, originally through the US military. I worked for a few commercial organizations after that, most notably DigitalOcean, that's where NetBox was born out of. I did some consulting work for that and ended up where I am today at NS1.
OSS:
How did you get involved in the open-source community?
Jeremy:
I've been using Linux for a number of years. So I've always been a beneficiary of open source from the very early days, but I didn't really get involved with it until I started working on NetBox when I was at DigitalOcean, the hosting company. So I was working as a network engineer then, and we identified the need for a tool to help us model our network infrastructure. So things like IP address management and data center infrastructure management, data circuits, power, tenancy assignments, all that kind of stuff. And we looked at the different options and everything that was out there. And I basically just started to build my own, which even to this day, I don't recommend people try to do, but we did that. And we built it internally and released it as open-source software after it caught on. DigitalOcean was a huge advocate of that. I didn't really know what I was doing at the time. And you could argue, I still don't, but it was a great experience. And we realized getting into it, it was like, Oh, when we're releasing this as open-source, we need to think about how issues are going to be handled, and we need to pick an open-source license. And it was all very new to me, but over the past five years or so, I think we've gotten more adept at it. So it's been a fun experience for sure.
OSS:
What is NetBox and what is the future of the product?
Jeremy:
NetBox, just to provide a very high-level view, is basically a tool for modeling infrastructure resources. So everything from cabling, to IP addresses, all the stuff that you need to build the network, basically; physical and virtual components. So NetBox serves to not only model that, but also make it accessible in a way that that data is easily consumed by and populated by outside tools. We integrate with things like ServiceNow, or monitoring applications, or anything else through various APIs and extensions and customizations on top of NetBox. So it's important to call out that it's not, it doesn't do monitoring itself; doesn't do any kind of operational state. It's really more for modeling what your network is supposed to look like. I talk a lot about the desired versus the operational state of a network. And Netbox is there to model the desired state, which complements the monitoring and automation tools that you have to validate the operational state of a network.
OSS:
How will NS1 enable NetBox?
Jeremy:
Yeah, my move to NS1 and NS1's sponsorship of it as an open-source project, has already been immensely beneficial. It's allowed me to operate at a much greater cadence than ever before, as far as developing the project, and having some powerful brand names behind it. NS1 and our other sponsors as well have been very helpful in securing the longevity of the product and making sure that people have confidence in seeing NetBox has these names behind it, and NetBox isn't going anywhere. It's kind of the go-to tool these days for infrastructure modeling. And moving forward within NS1, it's positioned very well because there's so much we can do around integration with it. NS1’s tagline is, "Modern foundational infrastructure," which I love. And that's exactly what NetBox tries to enable. So it's a very, very good fit in that NetBox benefits from NS1 in that it has this sponsorship and kind of the security that comes along within an organization of that size. And NS1 benefits from NetBox in that we can pursue different integrations with the tool, with our existing products, which I think are very complementary.
NetBox provides greater visibility than what the product suite offers today. When you start looking at integrating our DDI (DNS, DHCP, IPAM) product with something like NetBox, suddenly you open up this much, much greater world because it's not just IPAM. Well now we can see an IP address, but we don't stop there. We say, Oh, this IP address is assigned to this interface over here on this router. And that router is connected to this switch and that switch goes in this rack. So you provide a much, much broader, deeper sense of the infrastructure and this enormous opportunity of what we can do with that information.
OSS:
NetBox has over 8,000 stars on GitHub. How did you build that community?
Jeremy:
Incrementally over five years. So it's been a little over five years since our initial open-source release. It was June 2016, and we actually just released our beta for version 3.0 last week. So, making great progress there. Very excited about that.
It started through word of mouth, and I'll say that the project had an initial kick, I think from DigitalOcean. DO throw their weight behind the initial open-source release saying, Hey, this is coming out of DO. And DO to this day, I love the company because they're very well-liked by their community and especially by the open-source community for what they've done to encourage and support open-source development, so a huge shout out to them. They did some stuff to advertise NetBox when it first came out, as an open-source project born out of DigitalOcean.
In addition to that, I had a blog that was pretty popular at the time called Packet Life that has since kind of fallen by the wayside, unfortunately. So I did some blog articles on that and everything, and through that and Twitter and Reddit, and the normal social media platforms, it started to catch on. And NetBox in its original form was pretty limited. It was pretty much just an IPAM tool. It had racks and devices in there, but not a whole lot. It didn't even do cabling between devices, believe it or not. It sounds so funny to talk about now, but it started to catch on more and more in the community. And I think what really got people hooked was they realized that you could integrate it.
It wasn't locked down. It wasn't vendor-specific. You have this big rest API, but it wasn't that powerful, to begin with. It was very open and intended to be integrated with other tools and people realized, Oh, I can start automating things like this. And I have complete control over the end-to-end process. And that prompted people to contribute more, to start asking questions. We got lots and lots and lots of feature requests, especially early on for different things. And people realized that the turnaround time... If you go to a vendor like Cisco or Juniper, one of the big names, and you ask them to implement a feature, it's probably going to be a few years before you hear back about that unless something's already been underway. Whereas with open source, Oh, that's a good idea. Let's try it out.
And then two weeks later you have it in a news release. Now that doesn't always happen, of course. And I'll be the first to admit there are a few feature requests out there that have been around for years, but for one, it's more transparent, it's a higher release cadence and it's a lot more, I think, responsive to community requests. If the community identifies something that looks like it's a good candidate for a feature, then we'll move forward with it as best as we can.
OSS:
How would you define success for the project?
Jeremy:
That's a hard question. I think that the project's already been so successful, it's hard to envision an end state. For me, there's no finish line for the project. It's going to keep maturing and keep continuing to be developed. For as much as we've done with the project, of course, there's so much more that we can do, that we stand to do. Success for me is not an end state, but it's more of a continued sort of sustained rate of adoption and growth in the community.
Addition of new feature sets, better integrations, ease of use. There are always new aspects we can improve upon. And it's always kind of a shifting goal. One release will focus maybe on user experience, another will be more toward the integration and automation aspects. So, there's tons of different stuff out there, but mostly it should be a tool that people feel is going to be useful for them. It's going to prove its value. It's something that's they're going to be able to use and contribute back to, and it will continually improve over time.
OSS:
If you were building a new open source project today, what would you replicate from the NetBox experience, and what would you do differently?
Jeremy:
I've got the huge benefit of five years of experience running an open-source project now. And it's hard because it's so easy to forget what you've learned in that time; what you didn't know back then. I mean, back then it was even, like picking a license was like, Oh, Apache2, all these other projects use that. That sounds good. We'll use that. There are two main avenues to open source health. There's the project. So the codebase and the actual integrity of that. And then there's the community. And obviously, they inform one another because if you have a stagnant code base, something needs a terrible amount of work, you're going to have a whole lot of difficulty in attracting new users. And vice versa, if you have a hostile community, no one's going to want to work on the code. So, you need to nurture both.
I think on the code side, there were definitely the go-to's as far as setting up continuous integration and deployment testing, code health, some of the tools weren't even around back then, like Python Black, for code formatting and stuff like that. That's important to get done upfront because it's so hard to adopt later on when you have a large codebase, so there's a lot of lessons learned there, but those aren't as interesting. I think the more interesting stuff is on the community aspect. When we started, I didn't know what I was doing. I was the only real maintainer and it wasn't even a full-time maintainership back then.
So it got to be a few years before we really took an active approach to hire additional maintainers, to really start soliciting and maintaining contributions. And there's a give and take there. Because you can ask the community for contributions, but in turn, that means you have to have solid documentation. You have to have a solid workflow in place to do that. And those are things that we really kind of piecemealed together over time. We didn't set out on day one, Okay, here's our contribution policy. It's four pages long and it's going to detail everything someone needs to know. We didn't have one. It started out with, Oh, you want to submit a feature? Sure. Send in a pull request, we'll take a look at it. It was very, very relaxed, we'll say.
And some projects work like that, and that works absolutely fine for them. It really comes down to the frequency of change in the code base, the cadence of your releases, how formal you want to be with different contributions and stuff, and how large the project grows to be over time. But the more that you can put in place from the beginning, having solid frameworks for contributing policies, documentation around the code itself. So the best practices for that workflow. And even then, we've seen so much improvement in just the toolsets that have been available to us in the past five years. GitHub used to be that you could only have issues and pull requests. Now, they have this concept of discussions, which has been enormously helpful.
We were constantly fighting this battle where someone would open an issue, but it wasn't a feature request or a bug report. It was just them needing help with something. And we'd have to kind of gently shuffling people toward the mailing list or something to say, Okay, this is development chatter versus help. Not that you're unwelcome, but we were trying to keep it separate and organized as best we can. And so, GitHub discussion is an example, that's greatly improved for that. It's important to have those set up initially, so when you're going to produce an open-source project or release one, you want to make sure you have the policies, those forms, those templates, everything in place. The more you get in front of that, the better because it's going to make it easier for you to get off the ground.