In brief: Ksplice had a lot of work to be done and not enough time to do it. Since they were within close proximity to MIT, they decided to bring on a bunch of students as paid interns to help them out. The result was a huge boon for them and they got themselves back on schedule.
How were they able to do this despite the oft-quoted Brooks' Law? Here's the key bit from the post:
Divide tasks to be as loosely-coupled as possible. Our internship program would never have worked if we had assigned a dozen new people to hack on our kernel code—the training time and communication costs that drive Brooks’ Law would have swallowed their efforts whole. Fortunately, like any growing business, we had a constellation of tasks that lie around the edges of our core technology: infrastructure upgrades, additional layers of QA, business analytics, and new features in the management side of our product. These had manageable technical interfaces our existing software, so our interns were able to become productive with minimal ramp-up and rely on relatively little communication to get their projects done.
So, for all intents and purposes, each student was working on their own project and not as part of a single monolithic project (as Brooks was referring to when he wrote The Mythical Man-Month). Even the blog post admits that if they had they would not have realized the gains in productivity they boast about.
Admittedly, you could probably still make arguments that this particular instance applies to Brooks' Law, but I think it might be stretching the intent of what Brooks was getting at in the Mythical Man-Month.
Brooks' Law is more about the dynamics of communication than it is about any specific type of project. Whenever a project requires lots of meetings, IMs, emails, and whatnot to get things done, it's only going to get worse when you throw more programmers into the mix later, as your now adding their chatter to the already-large cacophony of communication going on. That is what Brooks was concerned about.