Is ‘corporate open source’ an oxymoron? Not where Node is concerned

Ben Wen is vice president of product at Joyent, the corporate steward of open-source project Node.js

There are plenty of reasons for a corporate enterprise to sponsor an open source technology, from better code testing coverage to community development to direct monetization.  There are lots of motivations.

My colleague Bryan Cantrill has some hard-learned lessons, colorfully told in his Corporate Open Source Anti-Patterns talk.  Products released this way (and I use the term “product” here specifically) often have sponsors with their economic caboose hitched closely to the open-source community train. This isn’t necessarily the way to win the hearts of the open source community. Often, it is misaligned with the values of a broader community.

Looking back in time, we’ve seen how this philosophical divide is created. When a company releases a product under an open source license, they will usually market a distribution of the open source software under a pay-to-use model with annual support and update subscriptions.  Sometimes there are licensing changes as well which may limit the number of CPUs, locations, spindles, or artificial computron units that a customer may run.  This direct monetization model means open source software buyers suffer the same indignities as commercial software buyers: license audits and vendor lock-in.

There’s also a more subtle but equally problematic flaw with this model. When the corporate steward of an open source project engages in direct monetization, they implicitly divide the community into two factions: the “open source” camp and the “enterprise” camp. That means that the community is now separate from the software. Specific examples of this factionalization include the Oracle MySQL license divide, OpenJDK versus Oracle JDK, and Red Hat Enterprise Linux versus CentOS and the larger Linux community.

So where does that leave an enterprise organization looking to sponsor an open source technology and meaningfully justify to shareholders a return on that investment, all without souring a community?

For starters, you need to have some long-term vision about how open source can support the profits of its sponsor. It also means defining very clear goals and objectives and aligning with open source values.

When Joyent became the corporate steward of Node.js, we wanted to find a way of monetizing Node.js that would serve to strengthen the community instead of dividing it.  That is, we want to lead the project for its own best interests while still being able to fund that effort with a viable economic model.  We started with our current business, something customers would rightly pay for — high-performance cloud infrastructure-as-a-service. Operating with the given that people were already paying for these things, we asked ourselves: Can we use open source to make our public and private cloud offerings more appealing and differentiate them in the market?

To be clear, that doesn’t just mean making the claim that an open source project should be run on the infrastructure of its steward. The combination of the two must produce an obvious technological differentiation that makes the pair especially compelling.  A counter-example of sorts is Sun Microsystems. The integration between open source Java and the rest of Sun’s hardware and software stack was essentially nil.  There were attempts at Java microprocessors and Java operating systems, but as our former Sun engineers remind us, few earnest attempts were made to really integrate Java with the system beneath it.

Having witnessed those mistakes, we were eager to find ways to improve Node.js in production.  So, we started using it ourselves to develop production services. To that end, our integration with Node.js happened naturally, because we developed the modules that we needed for our own purposes, including Mark Cavage’s node-restify for API-driven applications like Joyent Manta, and Trent Mick’s node-bunyan for logging.

Importantly, both of these modules are DTrace-enabled.  Each can be run in production on any system (many do), but if you run them on SmartOS (or any other system with DTrace), you have the added advantage of being able to understand their behavior in production.  There are myriad other ways that our expertise with Node.js has made our cloud offerings better, and in a virtuous cycle, we have been enabled to contribute back to the community.

When we say that SmartOS is the best environment for running Node.js in production, we hope it is not an empty boast, but rather a reflection of our innovation, our technology and our own experience.  It’s something of a point of pride for our Sun alumni that in terms of production maturity, Node.js on SmartOS has now surpassed the much older Java in its ability to be understood and debugged in production.

Insofar as Node.js has made our cloud and SmartOS more compelling products, we’ve found a clear, clean way to monetize code without alienating the community. As a result, we have won many production Node.js customers and host the Node.js PaaS Nodejitsu.  This has in turn allowed us to pay for our engineers to work full-time on Node (project leader Isaac Schlueter and core committer TJ Fontaine) and we’ve been able to charter them with the community’s interests over our own.

We believe that the right model for Node.js is a win for the community, a win for the project, and a win for the steward. Those who contribute to Node, use Node, or are evaluating Node can take comfort in knowing that we will never be the Red Hat of Node!