So you probably didn’t hear it here first, but Feedster has closed a round of funding! Nothing like a little bank to help power through some issues. And things do seem to be powering along. I have no idea if I’m allowed to mention who’s joined up recently, but there are some kick ass folks joining the team. Definitely sorely needed. And there are others in line on the way in. Having a solid team come together was a major concern for me. It’s hard to ramp up such a small group. Mixing in two people to a group of ten is one kind of problem. Mixing in more than half the original group size gets into some strange group dynamics. So the next few months should be really telling. The systems have decomposed so far into completely distinct territories. One engineer worked on one system, and in general the systems broke down along well defined API boundaries. That’s not going to be the case any more, and the kind of engineering capability required to deal with that is much different than what we’ve practiced so far. I’ve been an avid user of revision control systems (CVS, Subversion, and most recently GNU Arch), that just grew naturally out of participating in a bunch of open source projects. As it turns out, those systems are an enormous boost when everyone knows how to use them already. But most people that I know get familiar with the “concurrent version system” methodology working on some side project and then carry it back into their work environment (classic disruptive behavior, I love it, but that’s another story). A bunch of the startups I’ve been at actually have that whole methodology baked right into the corporate DNA. The core of engineering work flows through that shared revision control system. And after a little while the concurrent version system becomes your primary collaboration tool. There’s less and less email, fewer calls, and no one throws things over the cubicle wall to get your attention any more.

So we come back to my original idea, which I almost forgot in my rambling. Companies structured around this open source methodology concept have a pretty natural path to scaling. The structure is instantiated inline with a revision control system that allows multiple people to just keep working and help them resolve conflicts down the line, which didn’t exist in specification driven engineering organizations I’ve been at. There are a bunch of little benefits that factor into making it a good way to work in my mind, but the principal I’m looking at now is that it’s very easy to bring new people in. So although it really seems at first glance to look like a trivial administrative task once you learn how to use it (it’s easy to forget how the concurrent version way of thinking transforms your work once you grok it) I think from an engineering standpoint the most important thing after having a good team might be having a good concurrent version system that everyone understands. It really can (and maybe should?) stand at the core of execution.