Node.js reference architecture

The Node.js community is working on an effort to ensure the Next-10 project is just as successful over the next ten years as it was in the first ten. This large open source project is the basis for many backend web applications and offers lessons for other open source communities. This article discusses the project's goals and progress.

Why open source planning is difficult

Many open source projects find it difficult to plan upgrades and set roadmaps because nobody is in charge of telling people what to do. The collaborative process can be a difficult mind shift for people coming from teams that have done internal development.

Roadmaps are easier for projects sponsored mainly by a single organization. Although the single organization project is open, a lead from that organization can more easily influence the direction of the work. The same is true for projects with a single contributor because they can set a roadmap based on their commitment.

The Node.js project is not in that easy position. In this large project, managed by its community through a  GitHub repository, no single person or organization provides enough resources to set a fixed roadmap. Still, we must determine what is necessary to accomplish goals and ensure the project's future success.

Gathering opinions from the expert community

The Next-10 effort kicked off in January 2020 to make the second ten years of Node.js even more successful than the first ten. Initial discussions quickly revealed that we needed to document the foundations for discussing, documenting, and enabling the work required for future success. As a result, we wrote the following:

  • The project's technical values: The fundamental criteria we should use to assess tradeoffs and priorities. The success of the first then years can be credited to a set of core values. Documenting and evolving these values would be critical to continued success.
  • The project's constituencies: Having a clear idea of our stakeholders helps us prioritize the features and changes made in the project.
  • The needs of the project's constituencies: Understanding the needs of different constituencies helps us assess which work will benefit the broadest range of constituencies and ensure we are addressing all of the constituencies sufficiently.

We created these documents through a process that included the following:

  • Brainstorming within the Next-10 team.
  • Input from Node.js core collaborators.
  • A broader survey to get feedback from our ecosystem.

After this input process, we were ready to capture the top technical priorities that we felt were important to the project's future success. A summary of these priorities (in no particular order) includes:

  • Modern HTTP
  • Suitable types for end-users
  • Documentation
  • WebAssembly
  • ESM
  • Features from the latest ECMAScript specification
  • Observability
  • A security model for permissions and policies
  • Better multithreaded support
  • Single executable applications

We generated this list by brainstorming in Next-10 meetings and received broader input from the Node.js collaborator base. Since then, we have worked on each priority to dive deep and define concrete steps.

As mentioned earlier, no single person or organization can direct collaborators to work on a technical priority, but it is vital to enable volunteers who want to work on them. A well-defined set of priorities, and an agreement about what we need to do for each priority, can help collaborators feel empowered to jump in and help out.

The Next-10 team's progress

At this point, the Next-10 team has led deep dives on most of the technical priorities and has documented the way forward. We documented the agreements on what was important in the project's contributing documents. Examples of the documents include:

The deep dives also helped to drive discussion and critical mass to kickstart initiatives, which included:

I am very grateful to those who participated in the mini-summits, where we held the deep dives (refer to the files that begin with "summit" in the meeting minutes). It was great to bring together people from within and outside the project with relevant expertise and opinions.

I found that the summits were all great learning and collaborative experiences. They helped me understand and prioritize where the Red Hat team needs to contribute.

The Technical Priority Working Summary captures a high-level overview of the technical priorities and next steps.

So, where are we now? We have a good set of technical priorities and defined concrete work for most of them. As always, more volunteers are welcome to help move these forward. We plan to revalidate the foundation's technical values, project constituencies, needs, and technical priorities. This process will be ongoing to ensure we adjust as the environment and our requirements change over time.

We plan to start the revalidation process in a session led by Jean Burellier, Ruy Adonrno, and myself at the Collaborator summit in Dublin in October. If you have a passion for Node.js, a great way to help out is to contribute to our Next-10 discussion and make sure we get this right.

Community outreach and documentation are keys to success

Planning is essential to the success of open source projects. Planning is not about directing project resources to tasks but building agreement on direction and empowering volunteers to make progress on that agreement. We hope to inspire other projects by explaining our process of gathering information from our constituencies and recording everything to mark agreement.

We hope that sharing our planning process in the Node.js project has been interesting and might even give you some ideas about how to do the same in your projects. On the flip side, I am always interested in learning new methods. So let us know if you have found a great way to handle your project planning.

Check out our Node.js topic page to stay up to date with what Red Hat is up to on the Node.js front.

Last updated: August 14, 2023