Io.js and Node.js reconciliation proposal(github.com)
github.com
Io.js and Node.js reconciliation proposal
https://github.com/iojs/io.js/issues/978
82 comments
Oh man I love it! There's no way Joyent is going to say yes to this, and the best part is that these are absolutely reasonable, sensible proposals. I grok that io.js core devs are totally serious about merging back into Node, but there's no way Joyent is going to go for this. I expect at best a counter-proposal (that may not even be public) that doesn't do these points justice. The ball is absolutely in Joyent's court, and whatever happens next will be at least entertaining.
I have read plenty about the io.js project's technical and political frustrations, but I have not seen much on Joyent's position. I don't understand why Joyent let Node languish when it is an extremely popular project and apparently a significant part of their business.
Recalling the GCC/EGCS schism in the late 1990s, I predict that Joyent will support Node 0.12 as an LTS release and io.js will become Node™ master.
http://www.softpanorama.org/People/Stallman/history_of_gcc_d...
Recalling the GCC/EGCS schism in the late 1990s, I predict that Joyent will support Node 0.12 as an LTS release and io.js will become Node™ master.
http://www.softpanorama.org/People/Stallman/history_of_gcc_d...
What is there to love, precisely?
I must admit, I had some weird notion when I first started programming that the world of software geeks might be just a little bit less drama-centric than the rest of the human world, but I was very wrong. The soap-operatic emotions around Node are amazing to me. Good lord, it's JavaScript on the server, not royal palace intrigue...
I must admit, I had some weird notion when I first started programming that the world of software geeks might be just a little bit less drama-centric than the rest of the human world, but I was very wrong. The soap-operatic emotions around Node are amazing to me. Good lord, it's JavaScript on the server, not royal palace intrigue...
Yes, software development involves humans, like many other human endeavors.
> these are absolutely reasonable, sensible proposals
No they aren't. If you look at the changes to the Technical Comittee. The proposal is to add 3 members to it. I can't help but think there are way more people at Joyent. The TC seems to have alot of power on the direction of the project.
It doesn't seem reasonable to effectively stage a coup on node and ask Joyent to give up control over it.
No they aren't. If you look at the changes to the Technical Comittee. The proposal is to add 3 members to it. I can't help but think there are way more people at Joyent. The TC seems to have alot of power on the direction of the project.
It doesn't seem reasonable to effectively stage a coup on node and ask Joyent to give up control over it.
I'm only a casual observer in this but to me it seems like Joyent pulled the coup. Node always used a benevolent dictator model but it seems lots of people don't like this being a corporate entity instead of some single guy to ping on github.
I know what you mean I feel the same way. I'm referring to only this proposal iojs have put forth, the proposals aren't as reasonable as claimed and joyents going to sideline it to my discontent.
Why do you think Joyent will not say yes?
Honestly, this just makes io.js look even more childish. They're issuing ultimatums without any reasonable chance of success.
There are completely logical technical reasons for forking node into io.js. There are even political changes which need to be made.
But instead of trying to reasonably discuss the future of Node in a collaborative fashion, io.js has essentially issued an ultimatum which determines the entire governance structure of Node (including an entirely new management team). It's a desired coup, driven by an ultimatum, in the guise of a "proposal."
There are completely logical technical reasons for forking node into io.js. There are even political changes which need to be made.
But instead of trying to reasonably discuss the future of Node in a collaborative fashion, io.js has essentially issued an ultimatum which determines the entire governance structure of Node (including an entirely new management team). It's a desired coup, driven by an ultimatum, in the guise of a "proposal."
Such a coup does rest on most of the 359 working groups voting in agreeance according to the provisional and not yet entirely decided, declared, or ratified by-laws of the tentative constitution of the current committee's purview of the project, however.
My opinion? I shall say that, as far as we can see, looking at it by and large, taking one thing with another in terms of the average of the will of the working groups, then in the final analysis it is probably true to say, that at the end of the day, in general terms, you would probably find that, not to put too fine a point on it, there probably isn't an easy way to tell if they'll vote one way or the other. As far as one can see, at this stage.
I do see that there is a real dilemma here. In that, while it has been the policy to regard policy as a responsibility of Joyent and administration as a responsibility of Joyent's officials, the questions of administrative policy can cause confusion between the policy of administration and the administration of policy, especially when responsibility for the administration of the policy of administration conflicts, or overlaps with, responsibility for the policy of the administration of policy.
My opinion? I shall say that, as far as we can see, looking at it by and large, taking one thing with another in terms of the average of the will of the working groups, then in the final analysis it is probably true to say, that at the end of the day, in general terms, you would probably find that, not to put too fine a point on it, there probably isn't an easy way to tell if they'll vote one way or the other. As far as one can see, at this stage.
I do see that there is a real dilemma here. In that, while it has been the policy to regard policy as a responsibility of Joyent and administration as a responsibility of Joyent's officials, the questions of administrative policy can cause confusion between the policy of administration and the administration of policy, especially when responsibility for the administration of the policy of administration conflicts, or overlaps with, responsibility for the policy of the administration of policy.
Downvoted or not, this is now my favorite comment on the site. Bureaucratic surrealism is the best way to describe the situation.
I can't believe I read it to the end. After, I googled some of the text to see if this was a variant of some copypasta.
It actually is. The last two paragraphs are reworkings of Sir Humphrey from Yes Minister, a British political comedy from the early 80s that mocked bureaucracy and politics (while scarily showing it for what it really was).
Yeah this whole issue can even be interpreted as being passive-agressive. Not saying that it is, but it just has a weird feeling surrounding it, almost as if there is a huge grudge between each other, and being overly political (correct).
They are not really starting a discussion, this is more of a "you need to do everything different, or else..", as if they are now building up some evidence that they can later use to support their argument of "hey, /we/ tried to be compatible, but it is /their/ fault".
But I'm probably reading too much into this.
They are not really starting a discussion, this is more of a "you need to do everything different, or else..", as if they are now building up some evidence that they can later use to support their argument of "hey, /we/ tried to be compatible, but it is /their/ fault".
But I'm probably reading too much into this.
Given that the majority of development contributers went over to io.js, it makes sense for the structure for technical decisions to more closely resemble io.js while yeilding marketting type things to the new Node.js organization.
I really hope we can see a unification of the efforts and work through the political issues. Having very talented developers working on separate codebases instead of improving one seems counterproductive.
They have to merge otherwise one will die. There is no alternative. I hope it happens sooner rather than later.
Multiple languages coexist. Within Javascript, there are multiple module systems, general utility/polyfill libraries, test runners... for better or worse, we continue to have many alternatives for almost anything. So why not also different implementations of a language interpreter?
> Multiple languages coexist. Within Javascript, there are multiple module systems, general utility/polyfill libraries, test runners... for better or worse, we continue to have many alternatives for almost anything. So why not also different implementations of a language interpreter?
As it was already said they run the same package manager and claim compatibility. This means you either can't take advantage of any new API in io.js ever to allow your module to work in both or you take the road where you're transpiling to support one and the other. It's not sustainable and it's prone to issues.
As it was already said they run the same package manager and claim compatibility. This means you either can't take advantage of any new API in io.js ever to allow your module to work in both or you take the road where you're transpiling to support one and the other. It's not sustainable and it's prone to issues.
Welcome to the wonderful world of writing portable C and C++ code across multiple compilers and OSs.
Because they run the same package manager and roughly do the same thing for the same purpose? It's not a JRuby vs Rubinius debate, imo; it's more like YARV vs MRI, you just don't need both. If they were more different I'd agree.
[deleted]
[deleted]
From my limited understanding of the situation as a casual observer, I'd say the optimal (or at least simplest) outcome here would be to do an egcs/gcc-style switch where io.js is officially christened as the next Node.js, and the incumbent Node.js deprecated.
That said, I'm not sure if Joyent will be receptive to such a move.
That said, I'm not sure if Joyent will be receptive to such a move.
My thoughts exactly. I think anyone not familiar with the history of GCC/EGCS would do well to read up a bit...the current node.js/io.js situation almost an exact parallel. I also hope that Joyent takes note that EGCS was probably one of the best things to happen to GCC, and that the shift in governance model is likely one of the reasons for GCC's current success.
This page has a detailed timeline and emails from the GCC/EGCS schism:
http://www.softpanorama.org/People/Stallman/history_of_gcc_d...
http://www.softpanorama.org/People/Stallman/history_of_gcc_d...
[deleted]
If these projects don't get merged, it's going to be a shitshow in my opinion.
Why? io is more stable and fixes get backported to node when it's possible to backport them.
io.js can certainly benefit from these fixes but I don't think it'll be a "shitshow".
io.js can certainly benefit from these fixes but I don't think it'll be a "shitshow".
isn't the reason io was formed because node was so outdated? It had a way old version of v8.
The reason io.js was forked, in my opinion, is because a core group of very strong contributors wanted control over Node. They gained that control by forking, giving away control of the fork to the community (open governance model) and working to make the fork a superior product.
It still does have a way old version of v8 that's unsupported by Google. For the record.
Technically, io.js' v8 version in release 1.4.1 is unsupported as well; it was released 01/07, and Google's support of v8 ends when it is replaced by the next version (their release/support cycle is 6 weeks).
https://groups.google.com/forum/#!msg/v8-users/UUyavs0KtwE/d...
https://groups.google.com/forum/#!msg/v8-users/UUyavs0KtwE/d...
I'm not sure that this is correct. io.js 1.4.1 just shipped with v8 version 4.1.0.21[0] which was released on 2/24/15[1]. Additionally, the post which you quoted specifically says that "4.1 -> Chrome 41" and "and every branch's support period is also the same (another ~6 weeks until the next Chrome version goes on the stable channel)."
So this means that the branch is supported until Chrome 42 goes in to the stable channel. Though a case could be made that since 4.1.0.21 is tied to Chrome 41, which is still on the Beta channel, and "Our stability expectations are the same for every branch (once it starts shipping on Chrome stable, which is roughly 6 weeks after it's been created)"
[0] - https://github.com/iojs/io.js/blob/v1.x/CHANGELOG.md
[1] - https://chromium.googlesource.com/v8/v8.git/+/4.1.0.21
So this means that the branch is supported until Chrome 42 goes in to the stable channel. Though a case could be made that since 4.1.0.21 is tied to Chrome 41, which is still on the Beta channel, and "Our stability expectations are the same for every branch (once it starts shipping on Chrome stable, which is roughly 6 weeks after it's been created)"
[0] - https://github.com/iojs/io.js/blob/v1.x/CHANGELOG.md
[1] - https://chromium.googlesource.com/v8/v8.git/+/4.1.0.21
Incorrect. We support the V8 versions shipping in stable Chrome and, to some extent, onward. Per http://omahaproxy.appspot.com/ current Chrome is on 3.30.33.16, so we support that. 4.1 is not quite supported yet, but it's actually ahead of the curve, not behind.
I think you nailed it with "when it's possible." What about when it isn't? They're clearly divergent projects, so now you have to keep track of whether every npm package you use supports Io or Node, and which version of each. Package authors are now responsible for supporting one or the other, or becoming an expert on the differences in order to support both. It's a crappy burden on all parties involved.
[deleted]
Why reconcile? This is awesome competition. It involves open-source competitors. Today's gripes will soon be forgotten.
Open source competition can be good when the differences are primarily technical (e.g. GCC vs LLVM/Clang). When the differences are primarily political (e.g. GCC vs EGCS), then the competition serves only as a distraction. As a mostly-uninvolved outside observer, this competition seems more like the later than the former.
Political competition is hugely important. Governance models are tech.
What? No.
Political debates occur when everyone involved agrees that they're at "A" and they want to get to "B", but they disagree on the best path to take. A technical debate is when there is a fundamental disagreement about whether "B" or "C" is the better end goal.
In the EGCS case, the goal of building a cross-platform compiler collection was clear, but the process of getting contributions accepted into the mainline had become increasingly onerous for a large number of (potential) contributors. With LLVM vs GCC, there's a fundamental difference of opinion regarding the importance of modularity of the compiler stack (LLVM) vs speed and efficiency of the generated code (GCC).
In the case of node.js vs io.js, it seems to me that everyone still agrees they want an Ecma standards-compliant, evented JS runtime built upon V8 and libuv. If io.js had forked, say, because they wanted to rebase on JSCore or Rhino, then I could see the value in keeping both projects around.
As it stands, if I am a developer, and I want to help build an Ecma standards-compliant, evented JS runtime built upon V8 and libuv...then where do I go? node.js? io.js? If that choice is made based on governance model, then we're enriching the world of governance models, not the world of tech.
Political debates occur when everyone involved agrees that they're at "A" and they want to get to "B", but they disagree on the best path to take. A technical debate is when there is a fundamental disagreement about whether "B" or "C" is the better end goal.
In the EGCS case, the goal of building a cross-platform compiler collection was clear, but the process of getting contributions accepted into the mainline had become increasingly onerous for a large number of (potential) contributors. With LLVM vs GCC, there's a fundamental difference of opinion regarding the importance of modularity of the compiler stack (LLVM) vs speed and efficiency of the generated code (GCC).
In the case of node.js vs io.js, it seems to me that everyone still agrees they want an Ecma standards-compliant, evented JS runtime built upon V8 and libuv. If io.js had forked, say, because they wanted to rebase on JSCore or Rhino, then I could see the value in keeping both projects around.
As it stands, if I am a developer, and I want to help build an Ecma standards-compliant, evented JS runtime built upon V8 and libuv...then where do I go? node.js? io.js? If that choice is made based on governance model, then we're enriching the world of governance models, not the world of tech.
The path is technical, the goal is technical. Teams are involved so both are also political.
Most importantly, we should not spend any more of our precious time on this unnecessary distinction.
Change is the only certainty. As a javascript developer I now have two options to help me through those changes. That makes me happy.
Lastly, I love a good fight.
Most importantly, we should not spend any more of our precious time on this unnecessary distinction.
Change is the only certainty. As a javascript developer I now have two options to help me through those changes. That makes me happy.
Lastly, I love a good fight.
This type of competition is not good as there will only be minor differences which will confuse others. They will not be viewed as two different environments but two version of same environment. Developers will not want their libraries to work only with io when they can make it work with node with a hack. This can create situation like unix/windows compatibility. And using same package manager worsens the situation.
it's open source, not commercial. there's no point for competition. it's better to join resources and create equilibrium. the industry will need standards which will cause one project to die (sooner or later) and we will loose all the talent and energy spent there.
Competitive pressure isn't just useful for commercial projects, it is also useful for open source projects.
It's not even uncommon to have projects compete inside a company, like linux vs osx for ios in the early days. And in-house or open source competition is much better than a typical commercial competition because the good parts from all sides can be reused, lessons learned. This is why I am against software patents, too.
Awesome points :)
The joint resources/equilibrium broke down. That’s why the fork happened. It's a natural process.
Open-source competition is critical and beautiful. This is a major function of Github and a big reason why it’s successful.
Forget what the industry needs. Technology creates the industry. Now we're at the crossroads between the next great tech and the next great bureaucracy. Which side sounds cooler?
Open-source competition is critical and beautiful. This is a major function of Github and a big reason why it’s successful.
Forget what the industry needs. Technology creates the industry. Now we're at the crossroads between the next great tech and the next great bureaucracy. Which side sounds cooler?
You just made my life sound way more awesome than it is.
Is the Node Foundation truly independent from Joyent? If not, I don't think it could work.
I hope the two groups are able to work out their differences. I would love to see some of the strengths of io.js transfer into Node.js from both a technical and organizational perspective. The io.js project has been surprisingly thorough. So far they have kept on a consistent schedule of updates, provided excellent transparency regarding their team meetings and working groups, and they have been very responsive to feedback. I still use Node.js (with the harmony flag) for my production servers in hopes that there will be a merger soon but I may be in a dilemma if it doesn't happen within the next few months.
Funny thing about trying to standardize products or frameworks - You start with one fine product. Someone wants a bit extra, so they make a fork of the project. Then someone tries to make an all encompassing product to cover all the subsets. So there is a third one out there. Now you have to maintain not 2 but 3 separate projects, and document everything. The same story happens so often, people still try.
What's the background to all this? I'm not a JS dev so haven't been following, but the history would be interesting.
OK, so: Henry VIII needed a male heir to ensure his power on the throne...
Well played!
All the core team really lacks now is the node.js label. Joyent's trademark seems weak, since the term was in prior use for commercial purposes well before they came along. A trademark challenge might be one possibility. On the other hand, name changes in other open source projects have worked out just fine.
This is shaping up to be even more entertaining than I previously imagined
... or just abandon both and use a proper server-side language?
Similar thread on NodeJS's GitHub. Booming with comments and interesting discussion as usual ;) https://github.com/joyent/node/issues/9295
Well, considering the issue was created 6 minutes before you posted this comment, this is facetious and disingenuous.
I didn't notice that - but 42 minutes later I think the comment still stands :)
Check out the other top 5 issues - it's mainly a bunch of people talking to themselves.
Anyhow - I genuinely wanted to link to both - not trying to poke at node.
Check out the other top 5 issues - it's mainly a bunch of people talking to themselves.
Anyhow - I genuinely wanted to link to both - not trying to poke at node.
Just because no one has had the time to read the whole thing, think deeply about his position and state it in the last hour proves nothing.
Ok. Here are some issues from joyent/node that have not gotten any comments in over a month:
https://github.com/joyent/node/issues/9022 https://github.com/joyent/node/issues/8987 https://github.com/joyent/node/issues/8975 https://github.com/joyent/node/issues/8974 https://github.com/joyent/node/issues/8931
Just randomly went to the issues page and looked
https://github.com/joyent/node/issues/9022 https://github.com/joyent/node/issues/8987 https://github.com/joyent/node/issues/8975 https://github.com/joyent/node/issues/8974 https://github.com/joyent/node/issues/8931
Just randomly went to the issues page and looked
Given that the Node guys are publicly saying things like 'Io.js, what's that?' I think a little bit of snark is justified.
Wow. Can you provide a URL?
>> “IO.js, what’s that?” asked Joyent CEO Scott Hammond in response to my query about whether projects based on the fork would be able to enter.
http://readwrite.com/2015/02/03/joyent-nodejs-incubator-iojs...
Edit: Agreed with @caipre's reply that the quote isn't as bad as it sounds totally out of context (in hindsight I should have included more of the context in my reply too), and was probably meant tongue-in-cheek. However, I think considering the (perceived? real?) animosity between these two projects, his choice of wording could have been better.
http://readwrite.com/2015/02/03/joyent-nodejs-incubator-iojs...
Edit: Agreed with @caipre's reply that the quote isn't as bad as it sounds totally out of context (in hindsight I should have included more of the context in my reply too), and was probably meant tongue-in-cheek. However, I think considering the (perceived? real?) animosity between these two projects, his choice of wording could have been better.
The quote in context isn't nearly as damning as GP made it out to be. It seems to me that Hammond was answering tongue-in-cheek and only meant to emphasize that his focus was on Node.js alone:
One more thing: Developers using IO instead of Node are,
well, not invited.
“IO.js, what’s that?” asked Joyent CEO Scott Hammond in
response to my query about whether projects based on the
fork would be able to enter. “This is a Node.js project
for Node.js innovations.”
Why would people comment there though when the issue even points out that the discussion is on the io.js issue? Seems rather petty.
[deleted](1)
and it all goes downhill from there... I was never a big fan on node.js. it's mainstream popularity seems due to its corporate governance. io has just been so much more agile and faster, that I really worry that we will see stagnation now if this all goes through
However io.js seems to be setup the right way here. Javascript development growth is still in massive growth phase. It is hard to prove the singularity exists when paths keep diverting.
I think it is probably healthy to have 2+ or have one win out in the market. Or maybe create others as javascript becomes more prevalent. As the overall javascript development market gets bigger, this will happen more and more. If it gets crazy divergent then standards come about so they work together better. Everything is going to be alright.