#NodeMinds community group launches with huddle focused on users, contributors

#NodeMinds gathered in San Francisco for the group’s inaugural huddle.

The #NodeMinds community group convened its inaugural huddle in San Francisco on Tuesday to discuss one of the world’s most popular runtimes.

In just eight years, Node.js has grown to more than 8 million users, and all indicators point to continued user growth and an evolution into new sectors and geographies. Further, and perhaps more critically, Node.js is laying the framework for its users to achieve digital transformation. As a programming framework, Node.js has become ideal for everything from front-ending legacy systems on to the cloud to building microservices, tapping into serverless frameworks, handling mobile application delivery, integrating non-web systems and providing a foundation for the Internet of Things as a platform.

With this rapid growth and change afoot, IBM convened #NodeMinds to start to connect some of the brightest minds around the technology. This week’s huddle was a chance to put 24 of them around a table to discuss the challenges facing the technology as it enters this next phase. Our aim is to assist this community in coming together and growing to address some of these problems and take specific action toward solving them.

This week’s huddle, convened as the Node Summit kicks off, focused on the relationship between some of Node’s core contributors and the users (from startups to enterprise) who rely on it to build their applications.

Several themes emerged from the huddle, and we’ll outline those here and address them more in-depth in the coming weeks and months through public-facing articles and community discussions. Several questions were also raised throughout the huddle, which we’ll include below each insight for further exploration.

In a microservices environment, there’s a need for mature diagnostics and networking. In some cases, software engineers don’t understand or respect the complexities on the network side and vice versa. Developers are moving so quickly with microservices that in some cases developers aren’t really respecting the need for diagnostics in microservices.

Would a Node.js community-driven primer around this topic help?

For service discovery and service orchestration, that’s something you need to have. Most of the conversation is around a consistent environment. Is anybody talking about how to achieve this in a polyglot environment?

While Node has historically faced criticism over issues around debugging and metrics, part of the challenge is what the right primitives are to add to it and still keep it small and nimble. There’s a real challenge in matching the enterprise requirements for this and what can be done within Node. There’s not a great conversation that’s happening yet between those that are having the requirements and those who are actually writing the code.

How can the community bridge this gap?

How do we ensure that requirements for debugging node running in containers, in polyglot are making it back to the Node core developers?

The Node.js community could use a clearly defined roadmap of what it wants to achieve and what its priorities are. This would also include an effort to forge a deeper connection to the user base to understand what’s most important to them so that the core contributors are meeting their needs.

With limited resources — a total of five who are paid to work on the core repo full time — what is the best way to approach that roadmap?

How do we collaborate on building more of an end user-led community?

In bringing in more developers to make this a more end user-led community, how do you avoid creating the “junk box” effect where everyone is just contributing the code that they want to see, that serves their purpose alone?

How can we start to think more strategically rather than tactically?

Where’s the happy medium between people who love node because it’s tight and easy to use, and those who want to expand it and make it feature rich?

With so much that is right about Node and the community’s work, how do we prevent from over-rotating? In other words, with changes that are made in the future, how do we not mess it up?

The Node community faces a conundrum: While it doesn’t have the equivalent of a product manager, and could perhaps benefit from such a corollary, the community would perhaps reject that notion. And while there’s no product manager, per se, there are people filling the role, but they may not have those inherent skills.

How can the community ensure that the self-policing continues to be an effective means of regulation as the community grows?

What can the Node community learn from other open source communities that will help it manage this and some of the process issues it faces?

Despite the challenges the Node community faces, the general state of the technology is strong and getting stronger. The project is poised for continued success, which can be attributed to the fact that it has attracted such a passionate community dedicated to doing the right thing for Node.