Node.js, Code Commits and the Future of Open Source Programming

Contributing to open source is now stunningly easy, and more people than ever are doing it. What does that mean for the future of open source code and developer communities? I spoke recently with Mikeal Rogers of Node.js to get his take.

Christopher Tozzi, Contributing Editor

April 26, 2016

6 Min Read
Node.js, Code Commits and the Future of Open Source Programming

Contributing to open source is now stunningly easy, and more people than ever are doing it. What does that mean for the future of open source code and developer communities? I spoke recently with Mikeal Rogers of Node.js to get his take.

Node is a framework for developing Web applications. Introduced in 2009, it’s a quintessential next-generation, open source-by-default project that offers lots of advantages for programmers. In particular, it makes it easier to build real-time applications, which HTTP was never well positioned to handle on its own. It also offers a rich, modular ecosystem, which means developers can borrow code from one another easily and use it to build new apps quickly. (If you’re a programmer in search of a geekier explanation of Node’s advantages, here’s a great overview.)

But the reason you’ve probably heard about Node lately is not those features, but its role in March in causing lots of websites that depend on certain Node modules to break. That happened because a particular developer decided to unpublish code that other developers used in their own projects.

The issue was quickly fixed. Still, the affair underlined a sort of paradox: Because the Node ecosystem is so open and expansive, it depends on the goodwill of all members to function healthily. A single contributor’s decision to abandon the community suddenly, which is what happened in March, can have large ramifications for the rest of the ecosystem.

It is hard to imagine the same sort of thing happening at a more traditional open source project, like the Linux kernel, where a core set of elite developers control which code goes in. At Node, in contrast, a large group of programmers contribute in an automated fashion, with less centralized regulation or personal bonds of trust. In some ways, that exemplifies everything open source is supposed to be about. But it also shows how the open source community has become more vulnerable than ever to a breakdown in community consensus within a particular project.

Node and Open Source: Past, Present and Future

Rogers and I talked about this challenge, and what he sees as Node’s big innovations as an open source project, last week after the Node.js Live event in Paris. He made some interesting points, which underline how Node exemplifies major new trends in open source, as well as novel challenges.

When asked about Node and the affair of the “broken Internet” in March, Rogers told me he was surprised only that something like this had not happened sooner, since Node is such a large and comparatively decentralized community. But he also emphasized how npm, Node’s main package manager, quickly took steps to ensure that the issue would not recur. Going forward, he said, he expects challenges like this to be less of a concern.

A more interesting trend that Rogers mentioned was the fact that a very large share of Node contributions are now coming from a very large group of people. And most contributors are donating only a small amount of code. He shared figures showing that, in January 2016, the majority of contributors to Node made fewer than 20 code commits. (His figures discount the 124 biggest contributors.) The number of coders who issued 51-100 commits represented the smallest group of contributors.

That’s interesting, Rogers pointed out, because it shows, again, how Node exemplifies a new sort of trend in open source. The barrier to contributing is now lower than ever. You don’t have to gain social reputation to be accepted as a Node contributor. You don’t need to write a large volume of code before the project will accept your contributions. You just need to write something, then use Git to upload it. And if that’s the only commit you ever make, that’s fine. It’s no less significant to the project than the commits of people who work on Node code full-time.

To me, this is a hugely important change because it represents the culmination of a longstanding trend in open source (and free software before it), which stretches back decades. The GNU project in the 1980s mostly assigned responsibility for building each of the various parts of the GNU system to specific programmers, rather than seeking many smaller contributions from a larger group of programmers.

In the 1990s, Linus Torvalds broadened community participation within the Linux kernel project by accepting contributions over email and, later, Git. The Apache people did the same. But you still had to have some sort of social standing or reputation to contribute meaningfully to these projects. (Indeed, Eric S. Raymond pointed in “The Cathedral and the Bazaar” to reputation as a chief motivator for programmers to contribute to the open source ecosystem, which he conceptualized as a “gift culture.”)

Projects like Node, which became important parts of the open source once open source was already a widely accepted trend, take the openness of collaborative code development to a whole new level. They maximize the ability of anyone to contribute. And reputation isn’t necessarily the main reason why people choose to submit code. Instead, programmers who don’t care at all about winning the esteem of their peers contribute to Node because that’s what they have to do to participate in the ecosystem. In this respect, the cultural calculus of open source has changed.

Yet at the same time, as I have suggested above, the extreme openness of contributions to projects like Node also creates a sort of paradox. The lack of centralized regulation at Node means that things can break more easily than they could in, say, Linux, where Torvalds, as benevolent dictator, is unlikely to let a bad code change happen.

Making things even more complicated is the fact that, unlike more static, incrementally released projects like Linux, Node software follows a sort of continuous integration model, where updates are always happening and can affect functionality in real time. When something breaks in Node, it affects production users, not just their bleeding-edge counterparts.

But maybe that’s also the culmination of a big open source trend. Updating software early and often, rather than trying to find and fix all bugs before code is released, was another of Torvalds’s innovations. But Linux didn’t take things in this respect as far as a project like Node.

Node, of course, remains under heavy development, in terms of both its code and its community. Developers will no doubt continue to work through the issues described above and create new solutions for them. If you want to understand what open source is going to mean five or ten or twenty years from now, this will be a crucial space to watch.

Read more about:

AgentsMSPsVARs/SIs

About the Author(s)

Christopher Tozzi

Contributing Editor

Christopher Tozzi started covering the channel for The VAR Guy on a freelance basis in 2008, with an emphasis on open source, Linux, virtualization, SDN, containers, data storage and related topics. He also teaches history at a major university in Washington, D.C. He occasionally combines these interests by writing about the history of software. His book on this topic, “For Fun and Profit: A History of the Free and Open Source Software Revolution,” is forthcoming with MIT Press.

Free Newsletters for the Channel
Register for Your Free Newsletter Now

You May Also Like