How Node.js created a model open source community

The creation of programming languages and platforms is rarely without challenges. A case in point is in the experiences of the community around the Node.js platform. Node.js allows the creation of backend services using JavaScript and a collection of “modules” that handle various core functionality and other core functions. Node.js’ modules use an API designed to reduce the complexity of writing server applications. Node.js’ package ecosystem, npm, is the largest ecosystem of open source libraries in the world.

There are currently 5 billion connected devices and that will increase tremendously over the next few years. The current and continued need to connect these devices is very important, and many companies – including IBM, Samsung, Intel, and Microsoft – see both APIs as the key to connect these devices and Node.js as the glue that connects them.

I spoke with members of Node.js about their experiences in the community, recently at the Linux Foundation Collaboration Summit.

A short Node.js history of the problem

Node.js emerged in May 2009 and is a child of the git and GitHub era of open source. Its relatively short history offers not only lessons, but also solutions to open source communities dealing with internal conflict for those who function in this new era of development. A few years ago, Node.js had just a few committers (contributors with write access to the repository in order to merge code and triage bugs). Questions were raised about the managing structures and the personalities within. The maintenance overhead for the few committers on Node.js Core was overwhelming and the project began to see a decline in both committers and outside contribution. This resulted in a corresponding decline in releases.

According to those invested in the project like James Snell – now IBM’s Technical Lead for Node.js and a member of the Node.js core Technical Steering Committee: 

“Developers did not feel empowered to make changes, this drove away developers… the innovation decreased and it became less interesting to invest in the project.”

A change to “open” open source

In response to these challenges and corresponding governance conflict, in December 2014, Fedor Indutny started io.js, a fork of Node.js. Unlike Node.js, the authors planned to keep io.js up-to-date with the latest releases of the Google V8 JavaScript engine. io.js’ point of difference was that it operated using principles consistent with the Do-ocracy movement, an organizational structure in which individuals choose roles and tasks for themselves and execute them. Responsibilities attach to people who do the work, rather than elected or selected officials. Snell revealed that

“By liberalizing the contribution process we stabilized the platform more.” He went on to explain that contributions by community members to the code, community or documentation defined those involved in decision making as “everyone who pushes a request had an equal seat at the table.”

In the first few months io.js attracted more active developers than the node.js project has had in its entire history.

In February 2015, the intent to form a neutral Node.js Foundation was announced. By June 2015, the Node.js and io.js communities voted to work together under the Node.js Foundation. Node.js v0.12 and io.js v3.3 were merged back together into Node v4.0. This brought V8 features into Node.js, and a long-term support release cycle. 

 A new way forward

The Node.js Foundation governance was divided into two entities with equal standing: A Business Board  – responsible for business, marketing and legal direction – and a Technical Steering Committee – responsible for code development, testing, integration, and working groups and projects.

Snell explained that:

“Having a governance structure enabled decision making clarity and essentially resolved personality issues.”

 This also left room for developer-driver innovation as Snell commented,

“Our road map is whatever developers and contributors want to do and is reflected in the commit history.”

Screen Shot 2016-04-11 at 11.09.36 

Today, the Node.js project is divided into many components with a full organizational size of well over 400 members. Node.js Core now has over 50 committers and over 100 contributors per month. Mikeal Rogers, now community manager of the Node.js Foundation, explained that this innovation has extended into other areas of the foundation.

“We’ve just started doing analytics around who are our modern open source developers. We’ve trying to cater to more casual users and on how to convert users into participants. People don’t want to be passive consumers and we’ve trying to remove the barriers to participation.” 

The Foundation’s Technical Steering Committee (TSC) oversees a range of committees including the Inclusivity Working Group. They’ve introduced practical ways to be inclusive like a policy for timezones requiring “pull requests should sit for at least 36 hours to ensure that contributors in other timezones have time to review,” Rogers said.

“As projects mature, there’s a tendency to become top heavy and overly hierarchical as a means of quality control and this is enforced through process,” he added. “We use process to add transparency that encourages participation, which grows the code review pool which leads to better quality control. More people means more reviews and more checks and balances. We also break core groups into working groups to avoid being top heavy.”

With a growing community of not only the interested but also the committed, Node.js demonstrates that liberalizing contributions and participatory governance will be the future of open source development and as they continue to scale, they’ll create a legacy that future communities will strive to follow.

 schedule
Facebook Comments