Node.js's hosts at Joyent didn’t plan for this -- the code had been an employee project rather than a strategic investment. While Node.js is an important part of Joyent's operations, it’s not a key product for the company, which has certainly spent far more to host it than it has received in business value as a pioneer of container-based cloud deployment. Joyent deserves credit for acting responsibly and maintaining its commitment as steward, despite the intense interest -- and fierce political intrigue -- in which it found itself.
Node has seen grassroots adoption that has led to enterprise deployments of the kind many recognize in open source, where CIOs are sure the technology isn’t in use in their business until they actually ask the operations staff. That in turn has led to the usual dichotomy between the needs of operations teams for stability (change only where it’s needed, preferably infrequently after rigorous testing) and the outlook of developers (who want to try every new idea now or sooner).
As might be expected of a company with a deep commitment to stable operations, Joyent falls firmly in the first camp. Its operations focus is supported by large deployers of Node applications globally, some of whom can be found guiding the new Node Foundation.
But widespread adoption also spawns startups looking to exploit new needs and monetize their resolution. Plenty of those startups are involved in the io.js fork of Node.js, calling for frequent releases to support their innovations and business plans. Developers and entrepreneurs in that camp have expressed exasperation that Joyent hasn’t driven multiple releases.
Their criticism of Joyent has been frequent and eloquent, but ultimately neither side has a monopoly on the truth. Joyent feels justified in its caution by the “sequence of unfortunate events” around the multiple faulty efforts to roll out a release over the last year, which would have led to chaos had it reached the user base. After all, Node.js is a platform, not a library, and it needs to be managed conservatively.
All this -- the corporate politics, firebrand developer outbursts, and the rest -- convinces me that Node.js needs an independent foundation. Not that I’m a fan of creating open source foundations for every project -- putting your project into a nonprofit rarely solves any problems, and most projects are better off joining an existing organization.
The creation of a government-recognized nonprofit has been historically important in open source for two purposes:
- As an imprimatur of “openness” by an otherwise proprietary activity by a single company that happens to involve open source code
- As a way to sandbox the politics of business from the practicalities of development, creating a neutral venue for genuine collaboration among peers
In that first role, the problems remain, even if they are masked by the veneer of a nonprofit. The second role needs a firm base of collaboration before it is put in place. Foundations don’t solve problems, but they make solutions permanent once they are put in place. Solve problems first, make a foundation afterward.
Node.js needs a foundation to supervise it. Its community is probably already large enough to render the idea of joining an existing community such as Eclipse or Apache inappropriate. But is the proposed foundation the right answer? Bill Scott of PayPal said at the Node Summit that PayPal is supporting the foundation, but watching the community. That seems to me to be the right balance.
What’s being proposed so far is a pay-to-play corporate trade association in the image of the Linux Foundation, with large, non-revenue-linked fees to scare away the startups and rules drawn up by big corporate participants like Microsoft and IBM. This is surely not the right answer to bring io.js partisans back into the fold. The bitter politics around Node.js certainly needs sandboxing, but so does the desire of developers to drive the agenda. A working Node Foundation will need both the operations-respecting release cadence Joyent seeks and the dynamic R&D space that io.js entrepreneurs desire.
A model like that used by Eclipse might work better here. After years of evolution, Eclipse now has a set of appealing governance features for this situation, notably pay-for-play fees that also require commitment of developers to the project and strict boundaries between fiduciary and technical governance. Eclipse also requires donation of the trademark to the foundation, a step neglected by projects at their peril if they are to avoid future exploitation by the trademark holder.
Of course, this all may be in vain; a crucial control point for Node.js, its package manager NPM, is controlled by a startup company of the same name. Divisive politics could recur unless that's dealt with as well. It seems the Node.js community, not only Joyent, has its work cut out for it.