I bet it was less than 15 minutes after the term "in-house development" entered the lexicon that some wag somewhere came up with its obvious corollary, "out-house development". But what does "out-house development" mean? I've encountered two different usages.
Now in-house development, as everyone knows, means software that's written by someone within your organization usually because there's no commercial or open-source product available that meets your precise business needs. We have a bunch of this stuff in the library: one example might be the web widget our staff use to track things like how many times they lend out camcorders, answer directional questions, and perform other categorized tasks. Our video booking system is another: perhaps surprisingly, we couldn't find a system that let us book videos for faculty and staff conveniently, so we built one. We also build a lot of "glue", which is software that enables two or more separate applications to talk to each other. So for example neither the Voyager Integrated Library System (aka the library catalogue) nor Summon (aka our search engine) were developed in-house, but the web service that enables Summon to pull circulation status information out of Voyager was developed by us.
Logically then, if in-house software is software that's developed within your organization, then out-house software would be software developed by third parties, right? Except it's never really used that way, not exactly.
"Out-house" is sometimes used as a synonym for "out-sourced" software development but with a negative slant, implying that contracting out software development that could be done within your organization can have regrettable impacts on quality. That is sometimes true but it's an oversimplification, the reality is It Depends.
The more interesting usage I've encountered doesn't make "out-house development" the opposite of in-house, it refers to a subset: the kind of in-house development that builds little pockets of software here and there, instead of building (or buying) comprehensive solutions. The implication is that instead of conceptualizing your organizational workflow holistically, out-house development treats it as a bunch of individual, localized problems to be solved incrementally. Think of building a lot of sheds (out-buildings, annexes) rather than one big warehouse.
And of course, here again the implication is negative. (It's probably impossible to use "out-house development" with a positive connotation). Of course the big picture, all-encompassing solution is better than the piecemeal approach, it seems to say. But the problem with that is the same as with the other usage: these kind of sum-it-all-up-in-one-catchphrase observations don't really do justice to the complexities involved.
And often, neither do the all-encompassing solutions. Case in point: about 14 years ago now we bought the aforementioned Voyager, intended then as a one-stop system for all our Library workflow management needs. And at the time, it wasn't, but it did meet a lot of them.
One of those needs was for a system to manage course reserves. Voyager does have a built-in course reserve management system. It's pretty basic, but it did the job for us for several years. But then our copyright environment started to change, which changed our business requirements to the point that the Voyager reserve management system could no longer be stretched or twisted to meet them.
So we acquired a new course reserve system, ARES, which launched over the summer. It too is not without its quirks but it does seem to be meeting the basic business requirement of limiting access only to students enrolled in the courses for which the reserves are available. However after we acquired ARES another business requirement surfaced; this time from the Bookstore. They had a business need to deliver coursepacks, which are similar but not identical to course reserves. Coursepacks have one additional requirement: you not only have to be enrolled in the class but you have to have paid for the coursepack. Turns out ARES can't handle that extra layer of permissions very well. Or at all, really. Some workarounds were proposed but they were generally acknowledged to be pretty ugly, both in terms of service delivery and staff overhead. You just can't shoehorn that capability into ARES, not gracefully. So what to do?
The best answer, as it turns out, was to build another system to host coursepacks. A shed, an out-building or annexe to the main system which has the singular function of checking to see whether you've paid up before it lets you download your coursepack.
One thing that makes this solution attractive from my admittedly biased perspective was that we were able to re-use some code I had written for a different project a two or three years ago, so we didn't even have to do that much work. Continuing the shed analogy, think of modifying an existing shed rather than building one from scratch.
And even more attractive is that because we have complete access to the source code, we can make it do exactly what we want it to do. No less, and, also important, no more. As a result the new system won't impose many changes to existing staff workflows and will be all but invisible to end-users: If you've paid up, you won't even notice it's there. If you haven't, it will provide a friendly notice with payment instructions.
Of course, when you don't want to talk disparagingly about this kind of development, you don't use terms like "out-house", you say things like "modular". The reality of course is that no system ever meets all your business requirements, and you can't junk an enterprise system every time you develop a requirement that falls outside its capabilities. Sometimes a small, targetted application is exactly what you need to fill the gap. And while it would probably be a mistake to develop all your software piecemeal, it's also a mistake to think there's some magic package that will do it all, now and forever into the future.