Some years ago, when open source was the fairly-long-haired hairshirt scruffy shorts-wearing barbarian at the gate, there was real sturm-und-drang around droll, berkeley-esque phrases like “copy-left” and “viral licensing”, enough to make some people wonder if these open source types used deodorant. And the RIAA, god bless ’em, was running around suing high school students and other customers who had the temerity to take a different view of the traditional marriage of digital content and intellectual property rights.

Well, you’d think we’re over most of that. First, I know a good number of open-source developers, and they use deodorant as often as anyone else (more personal hygiene tips below). On the intellectual property front, it’s still a little wild, but I think there’s a lot of sanity in the emergence of the Apache licensing model after GPL.

But then here we are this week with two legacies of that era, and some even goofier ones that preceded it, popping up: First, the love-your-lawyers-not-your-customers ethos popped in a story from The Guardian:

It turns out that the International Intellectual Property Alliance, an umbrella group for organisations including the MPAA and RIAA, has requested with the US Trade Representative to consider countries like Indonesia, Brazil and India for its “Special 301 watchlist” because they use open source software.

Having grown up in and around Washington DC, I know that sometimes political truth is stranger than fiction. But with media empires going down in the flames of new, cheaper technologies, it seems there’s always enough money for some litigation and lobbying rather than trying to figure out what’s new and how to prosper from it. Are these the same forces that give the US such advantages in mobile telephony, healthcare, and internet access (not)?

And here’s another blast from the past: open source is free lunch, therefore it’s easy, and anyone who work or invests in it is destined for easy nirvana. Which in fact is all we say and do in open source marketing, right? Or at least so says my blogging role-model Steve Arnold:

The use of the phrases “open source” and “support standards” sounds pretty good. Get the software into the company. When the organization’s boss figures out that the existing tech staff cannot make the open source software work as everyone believed it would, then the consulting engineers are ready to pounce.

Wait a minute: where exactly does open source lay a unique claim to getting the software the door, fooling management, and sneaking in consulting when the situation gets desparate? Anyone out there every install SAP, or Oracle, or deploy any other ambitious commercial enterprise software package, without a lick of service or support? Steve, you protest too much.

I’ve met my share of these “organization bosses”, and they usually got their jobs by figuring out that it technology alone can’t save anyone the hard work of sweating the details of ambitious, differentiated software app development. Why is it hard? Because you’re building a system that does what none of your competitors’ systems can do, so you can beat them in the marketplace. If it was easy, it’d be done already.

In fact, the “spaghetti code” that Arnold frets will uniquely undermine open source projects is how commercial software vendors make money: controlling access to the source code, changes to the code, consultants on the code, and deployment of the code.

What open source does do is make it easier for innovation to gravitate to an accessible, flexible code base. It makes it easier for new ideas to percolate into that code base following rigorous peer review. Transparency can abet performance tuning and optimization. And vendors who have complementary technologies, whether open or proprietary, can tap into its broad base for innovations and open up new market opportunities, where experts in a particular function haven’t gone the open source route. Seems it’s easier to integrate with an open technology than between two closed, commercial technologies. And since ambitious software will require expertise, why pay for vendor help twice — once for a license, and once for the expertise to use it?

So, open source doesn’t, in one swell foop, make differentiated enterprise software development a breathlessly trivial exercise. It doesn’t white your teeth or freshen your breath, either. But you can use it to build damned good software, and with some help, damned good search applications.