Tuesday’s announcement of the creation of the Node Foundation backed by a number of founding sponsors who are all big names left a few folks asking, “is this big companies taking over Node?” “What about io.js?” The Hacker News thread seemed to leave a few folks confused as to what the future holds for node.js and io.js, the two mostly-compatible forks.
My prediction: io.js and Node.js will unify
Before I explain why, let me explain where my perspective is coming from. Although I only came to the Node community two years ago, by the fortune of my position at StrongLoop I’m now something of an insider. On the technical side StrongLoop employs 7 Node core contributors including Bert & Ben, the two longest-standing contributors still active on the project, both of whom are io.js TC members.
On the business side I am a member of both the Node Advisory Board and the informal group of Node community leaders, sometimes known as node-forward, who organized and held regular meetings starting over a year ago which led ultimately to the io.js fork. Along with my coworker Bert who is also a member of all these groups and has been around Node since 2011, I feel fortunate to have been able to observe many (but certainly not all) sides of the debate about how Node should be run.
[sidebar] Full disclosure: I also have my own opinion, motivated by my position at StrongLoop, that the Node community is best served by a single project governed by a foundation. This is why I first reached out to Jim Zemlin at the Linux Foundation a year ago to see if they’d be willing to help. Since our founding, StrongLoop has had the ability to fork Node – and most likely the ability to deliver a Node with a significantly increased feature set from what was then Joyent’s Node.js – but I never thought it would be good for our business. To use a line from Joyent CEO Scott Hammond, “I’d rather have a slice of watermelon than a whole grape.” Rather than forking, StrongLoop pivoted early on from having our own Node to distributing all of our additional value via Node modules, all of which can be downloaded using npm, and Bert & I got involved in the community process to create open governance for Node.
Why will Node.js and Io.js unify?
1. Everybody wants a single Node
If we go back to the reasons why io.js was created, it was about governance and how the project is run, not a desire for a second stream. While the concerns of core contributors ranged from wanting more inclusiveness in the development process to not wanting to further the bottom line of Joyent to the inability to impact when a release would happen, nobody was saying (and still isn’t) that Node is headed in a fundamentally different direction than where they thought it should go and therefore needed a separate project to explore a radically different technical direction.
Also notice that the difference between the active Node.js contributors and the io.js technical committee (TC) is a small handful of individuals. There is significant overlap on the projects, not a broad schism, and everybody is talking to each other. Compare this to other forks where whole factions of contributors have stormed off in a flame of glory refusing to speak with the others ever after.
2. There is incredible pressure to have a single Node
From community members using Node every day who have to choose which codebase they want to use, to the sponsors who have committed over $1M to support an open governance project, most external consumers of the project would prefer there be a single codebase and singular distribution. Certainly our customers like GoDaddy and Staples would like for there to be a single project to track.
If you look at what many of the large vendors are doing with Node, they’re either running Node on their platforms (i.e. Amazon runs Node on Beanstalk and Lambda, IBM runs Node on their mainframes, F5 runs Node on their load balancers, Heroku hosts Node, etc) or building tools or applications for Node (i.e. StrongLoop, New Relic, JetBrains with Webstorm, Circle CI, etc.) Having two binaries to test against creates more work for everyone. For the sponsors like IBM, StrongLoop & Walmart, who can commit plenty of resources, I think we’d all like to apply that in a single place concentrating innovation.
3. It’s technically more work to maintain multiple projects
As Gianugo Rabellino from Microsoft Open Tech said on the foundation panel at Node Summit on Wednesday, “If you split the communities, you split the innovation.”
Contributors that want to see their patch land in both io.js and Node.js would have to double-commit. Even today Trevor and others spend time porting changes from one project to the other rather than working on improving things overall. Even if most of the work is happening in one project and simply being pulled into the other, there’s still the incremental work of doing the rebase. For us at StrongLoop, we already are testing against io.js and Node for Arc, strong-agent and Process Manager and it doubles our CI load.
4. It was never the goal of node-forward nor io.js to produce a second Node
Node-forward and io.js are an experiment in community governance. Keep in mind that there is a wide set of experience and opinions on governance structures. Each time a more distributed governance model has been brought up for Node in the past it has been met with skepticism. And Joyent’s CTO (and project lead TJ’s boss) has been very public about his belief that committees don’t work and dictators do.
In early discussions about changing the governance model, we asked the same questions: could a committee-based model actually sustain progress? One amazingly positive contribution io.js has made to the community is it has shown that a technical-committee model can not just sustain innovation, but accelerate it. Indeed the working success of this model heavily influenced the advisory board’s recommendation to move Node to a foundation where a TC-style technical governance would likely be used.
How it will happen
The Node Foundation will have two main committees:
The Foundation Board oversees the foundation and deals with things like marketing, trademark, organizing events, budget, fundraising, and legal matters. Often the foundation boards will delegate responsibility (such as organizing a conference) to a subgroup.
The Technical Committee oversees the technical direction of the project, the codebase, the build system and downloads, and other technical matters.
Both committees can (and likely will) organize, appoint or contract subgroups to take on particular tasks. For example, the Foundation Board might hire someone to do administration, and the Technical Committee might recruit people to form a working group to decide on issues of internationalization.
Importantly, the technical committee operates independently from the business board and does not take technical direction from the business board. This kind of “separation of church and state” is fundamental to ensuring that the technical committee is free to serve the entire community. Like other open source projects, members of the technical committee will be elected or appointed according to their merit to be technical project leaders, not the size of their wallet or who they work for.
Nobody involved is going to endorse and participate in a foundation where either committee is dominated by a single entity. Because of this, the technical committee will not be allowed to be controlled by Joyent, StrongLoop, IBM, etc. The io.js technical committee is already made up of a cross-section of qualified contributors representing many organizations and viewpoints and already has a rule that not too many of its members can work for the same employer.
For each board, they are bootstrapped, and then use a process they decide on to organize their own composition. For the business board, it’s likely membership would be a combination of sponsors and elected representatives from the community. For the technical committee, it’s likely the membership would be initially composed of contributors to both Node.js and io.js and then use some form of elections to nominate new members on a periodic basis. (For example, io.js has already expanded its technical committee using this process.)
How do we get to unification from here?
The role of the Node advisory board, the foundation, and the working group that will become the foundation board even before it is officially formed, is to help facilitate this unification. On the panel yesterday, when asked about what the big names would be doing to help, Bill Scott from Paypal summarized it well, “Top down should be providing the infrastructure that gives the freedom for technical innovation.”
Unification is something you can help with! The io.js repository and the Node Google group are open to all. Get involved, post issues and comments, let people know your ideas and solutions. Tell people where you stand on the issue. I’ve worked with all of the contributors in small or large ways and they are each kind people – if they hear from a wide swath of the community something you want, it will surely get considered, as everyone I’ve met likes to serve the community.
Do you want a more recent version of v8? Do you want slower releases and a more conservative approach? Do you want semver? Do you want multiple release vehicles for development, testing and stable? Make your voice heard!
For my part, I am working with a few others on the advisory board to organize a one-day technical summit where as many of the io.js and Node contributors as we can get together in a room for a day can hash through the technical issues that are keeping the code bases and the governance structures separate. I hope this will be a forum for key contributors to air their differences and find common ground.
Perhaps in explaining the mechanics I am not explicitly connecting the dots enough, so let me do that here: The Node Foundation technical committee is going to look a lot like the io.js technical committee plus or minus a few people. This is because if you go recruit qualified technical project leaders you end up with the group io.js has already recruited (and BTW TJ Fontaine has always been invited to be an io.js technical committee member and certainly would be a member of the Node Foundation technical committee.) If the new Node TC looks a lot like the io.js TC, I think you can deduce how unification would happen.
Having witnessed some of the early discussions between the io.js technical committee and the Joyent contributors, there are only a small number of points of disagreement on both governance (stuff like how voting would happen if needed) and technical decisions (stuff like which version of v8 to use in the next release.) I have confidence we’ll get through this and back to a single Node project with a transparent and open governance model based on a technical committee and we’ll have tons of innovation in Node!
Special thanks to Adam Crabtree and a few StrongLoopers who gave feedback on this post.