[_delirium]

Well in my case it's easy: I don't need people. :)

Or to be more precise, I don't need employees. I do work with other people, but they aren't my staff. I do some collaborative projects with colleagues, work with masters students doing their masters theses if they're interested (usually 3-5/semester are interested in working on either my projects, or projects I'm interested in), and also work with some people in industry.

Some kinds of research require an army of minions, but I don't really need employees to do mine. In fact generally I prefer having a smaller number of collaborators so I can really be a researcher doing research and writing papers myself, not a research manager, the kind of professor who's the last author on papers written by their students and postdocs. The institution I'm at doesn't expect American-R1-style large labs, so I can do that. Fortunately there are a pretty wide range of institutions with CS departments with different expectations, so there is quite a bit of choice.

[h0cked]

If your goal is just to producing quality papers, this is perfectly great. If your research involves systems and implementations, it sucks to have to write every bits of code yourself. I don't think CS research is just about theory, at least not the line of research I am doing, I am all about making it readily available to others to use.

[_delirium]

Yeah, it certainly varies. I'm in AI, which is a bit different from systems. A lot of the work is based on existing open-source code, since you don't need to (probably shouldn't) be constantly reinventing the wheel. In my case it's usually the modeling, data analysis, and insights gained from the data that's new, not the underlying software (e.g. I wouldn't write an SMT solver myself).

When I do produce code, I produce prototype code myself or working together with masters students. When the goal is to produce robust, end-user-ready software, I prefer one of two approaches: 1) work within an existing open-source codebase, contributing improvements upstream; or 2) collaborate with a company to turn a prototype into something polished and end-user-ready. Even if I had a bunch of funding, I don't think I'm in a good position to produce and maintain polished end-user-ready software. Academic software has a habit of going unmaintained when the PhD student graduates or the NSF/EU project ends, and research funding isn't really aligned with production needs. John Regehr talks a bit about that here: http://blog.regehr.org/archives/1058. So I tend to stick with either one-off prototypes, or find a way to collaborate with someone (open-source community, company) that is better positioned to maintain software.

Other decisions are also perfectly valid, just given resources and interests I don't see maintaining essentially a software-production company within academia, with paid staff, as feasible for me personally.