Business concerns (primarily compatibility with Node.js)
blakecallens opened this issue · 7 comments
Though I'm not at all opposed to this fork, as a developer of a very feature-dense open source platform for Node.js, PencilBlue, my main concern is compatibility between the two platforms in the long term.
As things stand it's not feasible for us, until a clear frontrunner emerges, to take advantage of any individual features of either io.js or Node.js; the effort it would take would all but negate our ability to improve our platform. I'm also concerned about differences that might emerge in the more intricate features that exist in both platforms, such as cluster management, which we make full use of. I'm sure other large, open source and enterprise projects share our concerns.
Assuming your plan is for the market to choose io.js as the preferred version, what are your plans for inter-compatibility with Joyent's version until that happens? Thanks for your time!
It's outlined in the io.js README:
We intend to land, with increasing regularity, releases which are compatible with the npm ecosystem that has been built to date for node.js.
Basically, we'll try very hard to remain 100% compatible, with a possible exception for native dependencies.
I suspect that the most noticeable aspect is going to be the growing feature disparity between io.js and joyent/node. For example, the version of V8 that is likely to ship with joyent/node v0.12 is older, has generators still behind a flag, has somewhat buggy promises and generator implementations, etc. That's outside of our control, though.
Thanks for the quick response. Do you intend to have a support channel/process for projects like ours, should major incompatibilities emerge?
I would assume that focusing on a growing list of io.js features could eventually make some core things incompatible with Node.js.
I wrote a lengthy piece on fragmentation that should alleviate some of these concerns. https://medium.com/node-js-javascript/fragmentation-7e87d28f60fe
Thanks for the quick response. Do you intend to have a support channel/process for projects like ours, should major incompatibilities emerge?
In case @mikeal's post didn't address all your concerns: I think we would treat incompatibilities as bugs (within reason) so you can always raise an issue on the io.js bug tracker.
If you are worried about turnaround time, there are companies backing io.js (NodeSource, StrongLoop) so it should always be possible to get commercial support.
But, you can imagine a future where io.js, or node.js, choose to adopt new APIs that differ in some way.
@mikeal, I agree with you that this possibility - though I think it more likely an eventuality - will pose a small risk for those users who are building new sites and can choose where to start from. It could prove to be much more work, though, for middleware platforms like ours that would be left with legacy support, be required to build two versions, or have to completely drop Node.js support.
Hopefully the community will make a move to a single node platform by this point, but I'd like to get involved with your team, even if it's just in a perfunctory manner for now, to help prepare larger, open source, middleware platforms like ours with this potential upcoming split. Let me know how we can help.
+1 @blakecallens for posting your concerns, as this is one of mine.
@mikeal , thanks for the thoughtful write up on fragmentation. Having sat by during the fork of Solaris (while working for Sun), and two other OSS projects which I was personally involved with, and having witnessed first hand the fall of J2ME (Java on Mobile for a bygone era before Android/iPhone) at the hands of Google, there are plenty of reasons to be concerned, and many ways this ends badly for the wider node community (both Node.js and IO.js). Forks are the nuclear option when one side isn't giving up and quitting.
My read is there are four issues that must be addressed in the wider node community (in no particular order), prior to this fork:
- Enterprise readiness (stability, documentation, training, formal LTS, availability of developers)
- Personality issues in the core commiter group (current and ex)
- Advancement of the architecture and features in the runtime and api
- Stewardship and ownership of the wider Node Community (Node.js currently under Joyent ownership/copyright with some input from committee)
The fork adds in a fifth dimension:
- Fragmentation and compatibility
The ex-Sun guys at Joyent have a pretty good idea of what I am talking about with the true cost of forking a community, and I only mention this because often history is forgotten or rewritten by winners. The Solaris fork isn't relevant here, but is part of a long continuum of forks in the Unix community driven by corporate mishandling and greed. I will mention the JavaME case, as it is what motivated Google in large part to go out and build a new ecosystem around Android instead of sticking with JavaME which had enjoyed an installed base of about 3M + devices at that point in 2004 or so. Google came to Sun and requested/demanded:
- "Better" OEM implementations because fragmentation was affecting quality and behavior (UD aspects of spec between platform and JavaME layer were everywhere)
- Sun should release their software as Open Source without the SCSL license and JDK classpath exception (http://openjdk.java.net/legal/gplv2+ce.html). Move the code to a governing body or 501c3 (not unlike what the Node community has been after for sometime). The JCP was not the place to actually get things done quickly. Licensing was an onerous burden on Java's neck.
- More features and richer APIs (not unlike what I am hearing today from Node community)
- Faster (both performance, and time to market)
- Better developer tools (it was like string, gum, and spit building mobile apps back in 2004)
In Google's case, Android was a wild bet, one of the first bold efforts by them to re-invent the wheel, and then make that wheel really a lot better. They've done a fantastic jobs, and I am thankful because Android has been a boom for my company. But it came at a tremendous cost. I would have rather seen them partner closely with Sun on a nextgen mobile platform so they could get to what Google needed. I think the two would have been better off working together, and long term, both companies would still exist (Sun is gone, and I have to accept it), and Google spent a ton of money and effort to circumvent Sun/Oracle and the GPLv2 "tainted" code that exists in userspace Linux. They don't make a lot of money on Android and it is a huge legal liability still.
Fragmentation in the JavaME ecosystem was not easy to manage. Sun screwed it up royally. They did do well, and continue to do well with JavaSE. It is non-trivial, but Sun's success in Enterprise with Java was driven by the success in addressing enterprise readiness and keeping up a rapid pace of modern language and performance development. Android and fragmentation has been addressed smartly by Google, using a carrot and a stick (read: scary language in contracts, google branding, google play distribution, and google apps) to keep forks from destroying the ecosystem through fragmentation. Still, Amazon has forked. China Mobile has invested in companies that have forked. In fact, China is the wild west for Android forks, as Google's carrots don't matter much there. Google may still lose control of the ecosystem outside of US and EU, but they've done what they can for now to keep a unified tent.
If you want to address concerns about fragmentation, I'd suggest a long term roadmap with a clear plan for addressing upstream/downstream code issues, api compatibility, how legacy code will be managed, and places where runtimes may converge, and how "Soviet/US" style peace summits will happen and when, to prevent a nuclear war. For us who make money building enterprise solutions, or who simply want to know where we should place or energy in the Node community, this matters a lot. The worst that can happen is stuff pulled from NPM won't reliably run on Io.js or from the other direction. This will set back the value in the efforts of the greater Node community.
Sorry for the history lesson. I feel this pain and bruising from past forks that I've gone through (I won't even get into the last few years on my other projects) is worth sharing.
I wish you could upvote comments on Github. Great comment @truedat101 and helpful history lesson. I'm excited for a 1.0 and regular semver-flavored releases but agree we're at a pivotal point here which could turn badly for many.