Observations on Seven Years of Maintaining Open Source

June 27th marks the seventh anniversary of NetBox, a one-time hobby project which quickly took off and today largely consumes my life. What began as a proof-of-concept solution for the network engineering team at DigitalOcean is now perhaps the most widely deployed network source of truth in the world.

This feels like an opportune time to reflect on some lessons I've learned along the way, with the hope of offering mixed encouragement and caution to those considering a similar path. And as I've felt the urge to pick up blogging again, this post will also serve to share what I've been up to recently.

Most articles about open source in general are boring. Reading about licenses and software governance feels like a punishment. Keenly aware of this fact, I'll do my best to navigate around the theory and stick with observations that are of practical use to the aspiring open source maintainer.

What Does it Mean to be Open Source?

Before we dive in, some context. "Open source" means different things to different people and in different contexts. The canonical definition provided by the Open Source Institute (of no relation to the OSI model network engineers know and love) asserts that any content which qualifies for the open source label must meet several criteria. The most prominent can be summarized as follows:

• The content must be made available for free
• Other people must be allowed to redistribute the content
• Other people must be allowed to modify the content

There are other stipulations in the "official" definition, but these are its key criteria. However, this definition is rather dated. It fails to address complexities of the modern software development industry, and has been challenged in recent years by the evolution of so-called "source-available" licenses which allow software creators much more discretion over how their work is used. (More on that down below.)

(The OSI actually attempted to trademark the term "open source" in 1999 to secure control over how the term is used. Several people were reportedly hospitalized from exposure to lethal doses of irony.)

Notice that I refer above to "content," not "code." Open source licensing can in fact be applied to other media: literature, music, videos - practically any form of creative work can be licensed as open source. In this article we'll stick specifically to software, and we'll assume the looser definition of open source meaning simply free software.

Everyone Does Open Source a Bit Differently

When you first begin work on an open source project, your decisions are heavily influenced by your choice of publishing platform. GitHub is by far the most ubiquitous platform, and Microsoft (which acquired GitHub in 2018) has done a tremendous job cementing its position as the de facto forum for open source development. I'm sure this will never result in anything horrible happening.

So, most people who start with open source start on GitHub, and learn how to do things by following the suggestions and limitations of GitHub's platform. This is largely a good thing, because it lowers the barrier to entry for novice developers and encourages many best practices.

However, it also places restrictions on how a maintainer can manage his or her project. For example, maybe this is a pet project of yours and you're not looking for help right now. Too bad: GitHub won't let you disable pull requests, leaving you with two choices. You can either set the whole repo as private, precluding you from sharing your work, or shoulder the burden of awkwardly closing any PRs that happen to be submitted.

I struggled for a few years to catch up on best practices for open source projects. Fortunately, today we have some helpful open source guides that address all manner of maintainer concerns. But I learned over time that even these should be considered in the context of your specific project. Maybe you need a security policy; maybe you don't. Maybe you need a formally documented issue triage process; maybe you don't (at least, not yet).

Too many novice maintainers make the mistake of working backward, writing policies and enabling features because they've been told they must, without any consideration of the problems ostensibly being addressed - and whether those problems even exist in the first place.

Perhaps the most egregious example is the code of conduct. "Oh, you simply must have a code of conduct! How on Earth will people know what behavior is acceptable without one?" Turns out that well-meaning people are actually pretty good at adjusting to group dynamics simply by observing the interactions of others. It's a skill we picked up somewhere between discovering fire and landing on the moon. Couple this with the fact that few people ever read the code of conduct anyway - other than trolls looking for loopholes.

My point is this: It will benefit you to read up on common best practices and be aware of the potential pitfalls they seek to address, but you don't have to check every box before pushing your first commit. You'll learn what works for you and what doesn't as your project and your community grow over time.

Licensing Matters

Open source or otherwise, all software needs a license. The license is what controls who can use the software and how they can use it. Few entities will accept the risk of using any software without a well-formed license because of the legal implications involved.

When working with DigitalOcean to release NetBox as open source, one of the first things we needed to do was decide on a license. We opted for the Apache 2.0 license primarily because it was a widely-used and well-known open source license, and frankly we hadn't identified any needs beyond what it provided. In hindsight, I believe this was a mistake, but it was not an unreasonable decision at the time.

GitHub maintains the aptly-named website choosealicense.com, which helps newcomers navigate the available options and compare licenses side-by-side. Some licenses are more permissive than others, and some address niche concerns where others are silent. If you've been around software for a while, some will probably sound familiar, like Apache, MIT, Mozilla, and GPL. There are many lesser-known licenses floating around as well; OSI officially recognizes dozens of slightly different licenses. There's even the WTFPL, which, despite its appealing brevity, is probably not the ideal candidate for most projects.

But as I alluded earlier, traditional open source licenses are failing the industry. While intended to promote collaboration and longevity, their radical fixation and openness leaves projects vulnerable to commercial exploitation. One way this contention has surfaced recently is the rise of server-side public licenses, highlighted by the fallout of a disagreement between MongoDB and Amazon.

And unfortunately, I was bitten by this myself. A consulting company for which I briefly worked began making demands of the project which were often at odds with needs expressed by its greater community. Rather than cooperate with the maintainers, they opted to fork the project into their own tool, which they immediately promoted as a direct competitor to NetBox.

Disappointing? Yes. Illegal? Nope.

The Apache 2.0 license which governs NetBox expressly permits forking a project (that is, creating a copy of it with custom modifications) and redistributing it under a different name. This is an often overlooked caveat and in my opinion the single biggest reason not to employ a traditional open source license. Had NetBox not amassed such a large, supportive community by that point, this could have been a death sentence for the project.

Fortunately, alternatives to traditional open source licenses are surfacing to address this shortcoming and afford creators more protection over their work. Source-available licenses, mentioned above, are very similar to "true" open source licenses and afford many of the same liberties, while protecting work against exploitation by would-be competitors. In practice, there is little if any difference to the end user, as the software is freely available in either case.

In researching source-available licenses, I came across the PolyForm license suite, which offers several licenses with varying degrees of protection. Most interesting to me is the PolyForm Perimeter license, which permits all uses of the software except those that compete with it. I believe this approach best represents the intent of most open source projects, and I frequently encourage maintainers to consider its adoption for new projects. Unfortunately, the PolyForm licenses are still relatively uncommon and thus subject to a higher degree of scrutiny.

In the wake of the fork, the NetBox maintainers team ultimately opted not to change the project's license from Apache 2.0, both because the damage had already been done and because it could potentially preclude many of NetBox's thousands of users from using new releases of the software (due to the need for renewed legal review).

Still, I suggest that maintainers-to-be strongly consider opting for a source-available license to protect their work from exploitation by third parties. It may not seem important today, but your project could really take off one day and it's best to establish safeguards now rather than risk waiting until it's too late.

Project Management & Embracing Chaos

Many of the strategies used to develop software internally fall apart when applied to open source due to the chaotic nature of working in public. Open source introduces numerous challenges that we take for granted in closed development environments, and adapting to these can be tricky if you're accustomed to strict processes.

Perhaps the biggest obstacle is that you have no control over the development resources available to the project at any time. Aside from core maintainers, contributors come and go freely and often without warning. One week you might have someone volunteer to finally tackle a new feature, and the next week they disappear. Or you might experience a barrage of new pull requests during the one week you finally decide to take a vacation.

Interaction with end users can be similarly challenging. Frequently we see people submit new feature requests or bug reports and then immediately ghost when prompted for additional detail. (Though they inexplicably return the moment the issue is closed.) And the users who engage directly with you typically represent a small minority of your actual user base, the true size of which may forever remain a mystery because its use does not require any form of registration.

I don't have solutions for any of these challenges. I wish I did. The best advice I can offer is to keep your workflows for triaging issues and reviewing contributions as simple as possible, and recognize that they will change over time. The NetBox project has seen several iterations of its approach to issue management, and I have no doubt that it will continue to evolve along with our code, our user base, and our tooling.

There Really are Some Things Money Can't Buy

Numerous people have reached out over the years offering to sponsor the project, for which I'm extremely grateful. We gladly accept sponsorship in the form of paid maintainer time and in-kind donations of hosting and related services. Ironically, the one thing we historically haven't had much use for is cash.

I mean, what would we do with it? We could use it to offset the miscellaneous costs of hosting the project (GitHub fees, maintaining the demo instances, etc.), but we'd rather pursue sponsorship directly from the companies providing those services. We might use it to incentivize contributions, such as a reward for fixing a bug, but that would require formal rules for assigning bounties, evaluating submissions, disbursement of funds, resolving disputes, and so on. It can quickly become more hassle than it's worth, especially for small teams.

That isn't to say your project shouldn't accept monetary donations. Direct payments certainly make sense for smaller projects, as a way to compensate the volunteer maintainers for their time. But once you have salaried employees working on the project, a few hundred bucks a month doesn't really move the needle.

And just last week, we announced a $100K community fund. Rather than focusing on NetBox development directly, this fund was established to encourage and reward ancillary community projects, such as plugins. Keep an eye out for more details about this initiative in the very near future.

Still, the most valuable additions to NetBox today come in the form of quality contributions from community volunteers, not just code but written and video content as well. Our focus these days is on continuing to grow and engage our community, because experience has shown it's what makes NetBox thrive.

Open Source as a Business

Most successful open source projects that reach any appreciable scale inevitably find or establish a commercial entity to help fund and govern the project. This could be the lead maintainer's employer, it could be a non-profit organization, or it could be an entirely new company founded solely to offer commercial services related to the project.

Commercial stewardship becomes crucial because at a certain point your project needs to be able to pay and hire developers, form contractual agreements with partners, and basically do all the things a business does, even if that was never your intent from the beginning.

In my case, this company is NetBox Labs. Earlier this year, NS1 (where I previously worked) was acquired by IBM, while NetBox Labs was simultaneously spun out as an independent entity focused on NetBox development and products. In conjunction with the spin-out, NetBox Labs raised $20 million in series A funding. Not bad for an old hobby project.

---

Bear in mind that everything I've shared here derives from my own personal experience and perspective. Other open source maintainers, many with far more experience than me, will no doubt disagree with some of my points, and that's okay. Every project is different. The key to success in maintaining open source is to always stay focused on solving the problem at hand. As the mantra goes: Improvise, adapt, and overcome.