It's mainly a re-write of the older toolkit. Open sourcing has many benefits. As lead of the open sourcing initiative (not lead-dev) it's been an opportunity t

It's mainly a re-write of the older toolkit. Open sourcing has many benefits. As lead of the open sourcing initiative (not lead-dev) it's been an opportunity to re-evaluate what we're doing and a way to identify things that may change in the future e.g. we used to write JS in along namespaced style. This was - to be honest - nasty. We now use a node.js style, but because we've identified that as something that could change, we have a plugin for that area which means we can move to ES6 or TypeScript if we want to in the future. It's also been a great way to look at what else is out there, can it address our needs and how can we incorporate it. The obvious thing here is Node.js v Java. We originally chose to write our toolkit in Java as Node.js wasn't around and later on because Node.js wasn't an option for our customers. That's changing so we're looking at Node.js integration. We obviously want our own developers and those of our customers to be able to take advantage of the amazing tools available in Node.js. Java 8 is making things look very good in this respect. From the point of view of the company there's no doubting that we hope open sourcing will have a positive business impact. The toolkit does enable a very productive workflow when multiple teams are building large JavaScript apps. We built this to solve problems that we were having and that our target customers are likely to have. It's also going to be continually maintained as both our own dev teams and those of our customers will use it. The UI stuff (Presenter) has been open sourced but we've actually decided to go with KnockoutJS by default as it simplifies the onboarding process. As per this comment (https://news.ycombinator.com/item?id=7429659 https://news.ycombinator.com/item?id=7429659) BRJS is much more about the toolkit supporting an application structure.