A recent issue of CACM covered software product lines in depth. The articles tended to be a glowing review of fabulous benefits being gained through the practice, and lots of technical jargon about how they do so. I should start by saying that I am extremely skeptical of one of the main proponents of SPLs, SEI, ever since I had the misfortune to experience high-level CMM first-hand. To briefly summarize, software product line development is a set of techniques or practices oriented towards building a family of related products that differ in a factorable set of ways. From the SEI page:

A software product line (SPL) is a set of software-intensive systems that share a common, managed set of features satisfying the specific needs of a particular market segment or mission and that are developed from a common set of core assets in a prescribed way.

Here's my core problem with the idea: most of the suggestions seem to boil down to: "spend some time/money making sure that you reuse code", basically, be explicit about code sharing and don't just make it an afterthought. I'm simplifying, but unfortunately, I don't think that much. From SEI's "About SPL" page:

Software product lines represent a significant departure from software reuse schemes in which attempts are made to make assets as general as possible without the context provided by an architecture and a scope definition, and from opportunistic reuse schemes in which low-payoff assets are scavenged adhoc from a reuse repository.

In other words, create an architecture that encompasses your family of products instead of trying to build totally general components, and don't just try to paste together a bunch of random code that may or not have good reuse potential. I feel like I must be missing something because that seems to be the very basics of good architectural design as captured by the concept of extensibility, i.e. that it should be easy to extend it in the future to do the things that you might want it to do. Perhaps there is an interesting kernel related to the idea of taking into account a fundamental set of features to be mixed-and-match, sort of a limited componentization, but it seems to be ignoring the key aspect of the problem. You often have absolutely no idea what a related system might look like at the time you build the original system, so you are often mostly guessing about where things might go. The SEI documents seem to admit that, and the theme of "hire a good architect" recurs throughout.

So if Software Product Lines amount to planned reuse, and smart archtecture, I fail to see what the actual theory or research is about beyond just reiterating things that good software engineers have been doing for years. Perhaps I have had the good fortune to work with people who take these things as tacit goals and this idea is big news to other software companies that have been writing dozens of one-off programs or throwing money at totally general frameworks, in which case, I hope they are getting value from them. To me, Software Product Lines appear to be a fuzzy restatement of clear software engineering principles, or else I must be missing something