Apr 13
nTeam – Community “alternative” to VS Team System
The fervour surrounding the VS Team System pricing and target audience has whipped the community up into beginning the nTeam system, an open source alternative to VS Team System (although pitched at smaller development houses). The interest is such that they’ve already been featured in eWeek, before a single “line of code” has even been crafted.
The project is certainly ambitious, and has sensibly decided to leverage a key open source philosophy – that of reusing existing code bases. Whilst this will cut back on the amount of work they need to do, I think they underestimate how difficult it will be to cohere the different code bases together in a way that will actually get used.
Reading over the forum, in the first instance they plan to produce a suite consisting of a rather amorphous “server” that runs code control, server side unit tests, issue tracking and continuous integration. Client tools are also planned, consisting of unit testing, possibly refactoring, and similar. I don’t think the final feature set is nailed down yet.
Before it is, I’ll add my two pence and say I think some of the priorities are wrong; far too little emphasis is placed on the data repository (“source code control”). This is more than just a small server component – it’s the fundamental piece of a team management system. If a test framework fails, it produces an annoying bug, but it can be fixed. If an issue tracker looses an issue, it’s an admin headache, but someone will pick it up. If your SCC system fails, then you’re in deep, deep trouble – your product has just gone up in smoke.
The SCC is the fundamental system that ensures your fixed bugs stay fixed, your new tests hang around, and your continuous build server has something to build. A versioned SCC is not something that will be easy to “bolt on” later – the checkout/edit/commit cycle is pretty different to the “just save to disk” route. If I were designing, SCC would be the first system I would solidify (even if it is just the interface), and worry about everything else afterwards.
My other concern is that bringing together five or more totally disparate products will, without massive work, just feel like five separate products bundled into one installer. The danger being that nTeam could end up being little more than an installation tutorial for all the different projects. This could be valuable, but certainly wouldn’t represent a viable alternative to VS Team System. A lot of work will need to go into making each original product feel like a single system - suitable UI changes as well as a high degree of interlinking will be needed. Retrofitting all these different code bases (as well as continuously incorporating bug fixes from the original projects) could be a mammoth and tedious time sink.
I should disclaim that I’m no expert in team management software, so this is just my opinion. I think what the nTeam group is trying to do is admirable. If I find a sustained interest in the project, I’ll post further. I should also put my keyboard where my mouth is.
