An Alternate Model For Open Source Funding: Cooperative Patronage

In a piece earlier this week, I made an offhand mention of a potential method of funding open source software projects that I thought had a lot of potential, but which did not seem to have been attempted yet. Since it’s an idea I don’t know if anyone’s tried yet, I thought I’d throw out some more details and see if You, My Frighteningly Intelligent Readers, have heard of it being attempted anywhere — and if not, whether or not you think that’s because it’s ahead of its time or because it’s amazingly stupid.

I call this model of development cooperative patronage.

The thinking goes like this. Currently, open source software (henceforth OSS) projects have tended to concentrate on building tools that scratch the itches of software developers: things like Web servers, operating systems, and 4 kajillion PHP content management systems. That’s natural, since people will only spend their free time working on projects that interest them, and developers are interested in developer-oriented tools.

A side effect of this, however, has been that development of business productivity applications has lagged. Currently the lead in this respect is held by OpenOffice.org, whose office suite is somewhat clunky but usable. A few other projects exist as well. However, few of these have the same priorities as businesses do; for example, the killer feature needed to get OpenOffice into the enterprise is bulletproof document compatibility with Microsoft Office, but OpenOffice, even at version 1.1, has settled for an acceptable but incomplete level of compatibility in order to pursue other features that businesses couldn’t give a hoot about.

So, given that this disconnect exists — that developers’ priorities don’t map very well to those of the enterprise for desktop apps — what can be done to bring those two sets of priorities in line?

This is where cooperative patronage comes in. Say that you’re the CIO of a major, non-IT, Fortune 500 company — Proctor and Gamble or GM or the like. For you, office software is not a profit center; it’s an expense. Your goal is to provide employees with the software they need at the lowest cost, both in up-front charges and ongoing maintenance fees.

Currently, your only realistic choice is Microsoft Office. Microsoft knows this, and they deal with you accordingly. You find yourself getting more and more squeezed by Big Red every time a new version of Office comes out. Now they’re pushing you onto a subscription model, where you’ll pay for upgrades whether you want them or not — never mind that you’ve standardized on Office 2000 and see nothing in Office XP or Office 2003 to justify the expense, you’re gonna have to open the checkbook for each new version. That’s a scenario that’s hard to explain to the CFO, but thanks to Microsoft you’ve gotta do it.

Or…

You could think about desktop productivity software like this. It’s an expense that falls equally on both you and your competitors. It gives neither of you a competitive advantage over the other; GM is not going to slide into the abyss because Ford upgraded to Office 2003 and it did not. In fact, the only advantage anyone has is the advantage Microsoft has over all of you — and that’s an advantage that’s costing you all more and more money each year, money that you could be using to improve your products, or that you could just pass back to the consumer.

So, maybe what makes sense is to call a truce. Gather together all the major players in your industry — say, in the auto industry case, the Big Three plus the major Japanese companies. Get them all around a table. Lay out the numbers for what you’re all paying right now for office software. And then propose that, instead of sending all that money off to Redmond, you and your competitors take a fraction of those resources and pool them together into a common fund. Appoint a board to manage that fund with a director from each company. And then send that board out with a mandate to hire some developers and “adopt” OpenOffice.org, or a similar project.

What do I mean by “adopt”? Not that you’re going to go and take over the project — that would be counterproductive (not to mention impossible). No, your programmers are simply going to contribute to the project, either by giving work back into the main code base or by building on a fork of that code base. And the code they contribute will be code that makes OpenOffice.org do whatever you want it to do.

Why put that money into a group of developers, instead of just shipping it off to Redmond? The short answer is security. When your only option is Microsoft, your expenses aren’t driven by your needs, they’re driven by Microsoft’s. New versions are planned and executed based not on what features are important to you, but what features they think will move product at CompUSA or will get the Justice Department off their back. And you’ve gotta pay up, even if none of those features mean anything to you.

Funding development yourself gets you off the upgrade treadmill. Those developers you’re funding can focus 100% of their time on making OpenOffice do exactly what you want it to do, and nothing more. Microsoft’s priority is adding more and more features to the already bloated and overloaded Office suite so they can add more checkboxes to the sales collateral. That’s great for them, but what does it get you? Nothing — or, worse than nothing, increased cost to deploy and manage your Office systems. You want developers whose priorities are the same as yours, and that’s what you’d get from your cooperative patronage investment.

Funding development yourself means no more nasty surprises. Since you’re adding code to an OSS project, nothing is stopping you from auditing the complete code base for potential security problems. Compare that to the black box of Office, which always seems to be finding new and exciting ways to crash your systems or launch viruses across your network — and you’re at the mercy of Microsoft to plug those holes.

Funding development yourself means a better negotiating position with Microsoft. If an OSS project meets all your needs, that puts MS is an unfamiliar position for them — they have to really innovate and come up with a compelling reason why you should buy a new version of Office. They have to work for their money, since you always have your OSS project in your back pocket. Therefore, even if some members of your consortium choose to stay with Microsoft, they still benefit from their investment in the consortium, since now Microsoft will either have to work harder to make their products compelling, or they’ll have to cut prices to make Office more attractive. That’s a win for your Microsoft loyalists either way.

Finally, why do this in cooperation with your competitors? The answer is simple: none of you earn your money from this product. It’s a cost center, a tangential expense, for all of you. In these times of economic slowdown, the pressure is on all departments to cut cost centers down to the bone — but, when it comes to Microsoft, you have no control over the expense. It just keeps mounting and mounting every year, in complete defiance of economic reality. Sharing the code with your competitors doesn’t give away any of the “secret sauce” that keeps you competitive in your market. What it does do is let you dramatically reduce the cost of the development team to your company, since you can now share the cost across many companies. And since each company only has one vote on the board, there’s no danger of Ford getting uppity and muscling the developers to start putting blue ovals all over the user interface.

Anyway, that’s the basic idea of cooperative patronage — taking on some of the work of developing an OSS solution in order to avoid the much greater cost of having to buy a monopoly’s commercial offering. Considering the potential money to be saved, I’m surprised nobody’s tried this already. Your thoughts, as always, are appreciated — that’s what the comment and TrackBack fields down there are for — so let me know what you think.

Posted by Jason Lefkowitz at August 24, 2003