Forking brilliant – Node/IO.js and Docker/Rocket

spork

What’s up with Node: So there’s been a fork in Node.js land with the appearance of IO.js. A group of core contributing developers have lost patience with Joyent, the developmental home of Node.js, and have set out to accelerate the development of the Async-JavaScript server side platform. This is the world of open source where people can vote with their time and effort.

It’s easy to see both sides of the fork. Joyent want steady, stable development as they move towards a foundationed, open-sourced release. That progress has been guided from within Joyent, as is their right, but it has ended up with a situation where old code, like an unsupported version of the V8 JavaScript engine, is still actively used.

The forkers wanted to move things foward faster. Some had been involved in a light fork, Node-forward, which was designed to make the enhancements and then offer pull requests to the Node project. But that wasn’t working for them. According to one of the better know users of Node, the fork has been a relatively polite affair in itself and most of the noise surrounding it has come from outside the Node developer community.

Which makes it all the more likely that this fork is going to be a good thing for the generality of the Node community. It’ll push both sides to compete on quality and progress and with commitments to compatibility from the forkers, the door is still open for changes to be backported. Of course, it could all go off the rails. Right now, we get to look forward to January 13, when IO.js will release its first alpha.

What’s up with Docker: Over with Docker, another case of long time contributers starting their own project has popped up. This time it’s all about containers. Containers in Linux let you run multiple systems off the same kernel. The problem was that LXC (Linux Containers) were hard work to set up and manage. Enter Docker in 2013 with an easy to configure and deploy solution to that problem. This was great stuff, bringing containers to more than just the pioneers who’d been harnessing them quietly.

It quickly started catching on and CoreOS contributed to the development by dotCloud, the original Docker company which eventually became Docker Inc, because they saw a use for a de facto standard container within CoreOS making app depolyment easy.

Time passed and as Docker Inc needed to grow it started a process of adding more and management elements to their Docker offering. Some of this was undermining CoreOS as they just needed a well matured container format to integrate with their server Linux. They weren’t happy with where development in Docker was heading and that it was bringing a big technical and architectural debt with it.

So CoreOS started building Rocket. Rocket isn’t a fork though; CoreOS started from scratch releasing a prototype to Github and specs for review. They started from scratch because one of their problems is what the see as the monolithic approach in Docker which they feel is counter a good security model. So rather than Docker tools talking to a single process and letting that do all the work, Rocket tools do the work themselves.

The company already is committed to Docker integrated into CoreOS and isn’t dropping it but it seems it wants to get building the foundations of a more secure container platform now, not wait till there’s an incident which blows out confidence. Rocket will notionally be done when it provides enough to create, package and run containers, containers defined by a specification which the Rocket developers created first. They hope that the spec will evolve and be implemented by others, including Docker.

Thoughts: These are two interestingly different splits. Both are powered by the force that powers most open source – enlightened self-interest. Both have the capacity to enhance the ecosystem that they are splitting from. And both are being created by developers who are already vested and have contributed, and probably will still contribute, in the the platforms they are splitting from. These have the potential to be sporks, splendid forks, if all parties are able to take as much as they give. Six months from now, both splits should have full releases and positions should be soldifying. How these things look a year from now is going to be very illustrative for open source in general. Just let me pop it in my diary now…

Developer Catchup: ECMAScript 6, Scala Policy, JSON’d Postgresql and SHA-1 sunset

developercatchupECMAScript 6: It’s coming, for mid 2015, and its full of features. In this (https://www.youtube.com/watch?v=G21rdWfa_as), Alex Rauschmayer talks about all those features. If you prefer slides they are available too. It covers most of the language features (skipping promises and proxies), outlines the timetable for standardisation and how you can use ES6 features now. Bonus link, do checkout his blog.

Policy and Scala: Scala has been forked, and forked by one of its most active contributors. The fork, called Policy, is one of those forks which hopes to be folded back into the original because “The leadership of scala has shown itself unfit stewards of the core technologies and the total price paid by scala programmers (actual and potential) is too high. I failed for half a decade to change that from the inside. Now I’ll try from the outside”. The initial reception seems positive and the Hacker News thread is full of background. One to watch.

More JSON in Postgresql: Postgresql has some neat JSON support built into the database, but one developer wanted it somewhere else – in the logs. Michael Paquier shows how to make Postgresql emit JSON logs hooking in a JSON log function at runtime. The code can be found on GitHub in a repo of other plugins. Why JSON logs? Well, it does make it easy for a JSON aware system like Elasticsearch to analyse and search those logs.

SHA-1 Sunset Now: Back in 2005, SHA-1 was tagged as “weaker than it should be” as a crypto algorithm and its only got worse since them. So people are slowly stopping its use. Google has just announced its SHA-1 sunset which begins this month with Chrome 39 flagging sites with SHA-1 signatures that expire in 2017 and beyond as ‘secure with minor errors’. By end of 2014 that window will expand into 2016 and in 2015 those sites will come up with an straight error. Of course, thats just the Chrome and Chromium browsers… Google will have plenty of engineering to do to completely remove SHA-1 from their systems. Next time your doing crypto work, remember to have un-SHA1-ing on your todo list.