Baseline magazine (which has been one of my favorites almost since its first issue) has a brief piece on companies that are forming software co-ops to help reduce their development costs and share some of the burden of creating new applications.

The idea on its own is intriguing, but it reminds me of a theory I heard that, while clearly not accurate, is still so plausible as to give one pause.

The theory goes like this: Companies which have made big bets on open source software, like IBM, do so because they see the licenses as a way to share work with their competitors while guaranteeing that they all get screwed equally. Which is to say, if you’re HP, you don’t mind splitting Linux development efforts with IBM because you know that at least neither of you is directly profitting from the software development to any great extent, and you’re ensuring a bit of independence from Microsoft along the way.

Now, to be clear, I don’t think this is true. I think the people evangelizing open software at places like IBM are doing so because they believe in the ideals behind it. (Though perhaps to varying degrees of St. Ignucius-ness.) But I can definitely see a clever middle manager pitching this to a skeptical person in the legal department by presenting it as a “if I’m going down, I’m taking you with me” sort of argument. I’m not sure whether that’s more damning of my cynical view of corporate manipulation or of the bad reputation many legal departments have made for themselves.

The motivation for this kind of thinking arises when you look at the code that’s submitted to most large-scale open source efforts. In projects like Linux, PHP, or MySQL, the overwhelming majority of check-ins to core components come from the very small number of (mostly commercial) patrons that subsidize the efforts. In the case of PHP and MySQL, Zend and MySQL AB (respectively) contribute almost all of the code except either bug fixes or accommodations for specific third-party technologies.

That’s not to dismiss the substantial contributions of any of the third-party developers that help make these great platforms, but rather to shine some light on the image that a lot of people have about how software gets developed. Lots of people who love technology, myself included, love the idea of a super-talented hacker toiling away in a dark basement to make a great world-changing app. And that’s sometimes what happens, especially early in the development cycle for a tool.

But usually, the more prosaic work of scaling up a platform isn’t glamorous enough to get the attention of a hardcore hacker who does it just for his peers’ respect. It’s more likely, these days, that it’s done by a person in a cubicle, under the instructions and management of a boss, to fit a timeframe that somebody somewhere is tracking on a whiteboard. And, just as so many geeks consider it beneath them to market their work, that application or platform being created might actually be marketed by a guy in a shiny suit who has glossy brochures, instead of merely succeeding on its technical merits. Like all software, only about 10% of an open source application is the code. It’s the rest of the process that makes for a product.

That’s not to dismiss the efforts of people who really do it for the love of coding. But perhaps it would help conservative organizations to feel even more comfortable with open source applications to know that there are “regular” software developers making a lot of the code they’re relying on. And it might make the line that separates different development communities a lot easier to cross if people knew that the “other” side was pretty similar to the one they’re already in.