Economic Motivation of Open Source Developers
Dirk Riehle, the guiding spirit of WikiSym, spends much of his time studying open source software for SAP. His essay on “The Economic Motivation of Open Source Software: Stakeholder Perspectives” (IEEE Computer, vol. 40, no. 4 (April 2007). Page 25-32) is very much worth reading; in place of the usual quasi-religious handwaving, this excellent essay approaches the question with sound analytical tools.
I think it might be mistaken. I can’t see a way to be sure. In some ways, that uncertainty is worse than simply being mistaken.
Perhaps the most interesting part of the paper is Dirk’s analysis of the impact of lower software pricing on the strategic choices of system integrators. Broadly speaking, he argues that lower software costs from open source let integrators keep what they would formerly have spent on software; alternatively, they can cut prices and buy market share. The details of the argument are sometimes confusing because Dirk (or his editor) assumes that the reader can't face algebra or calculus, and so the argument is couched in terms of geometric analogies ("the total profit is represented as the area of the gray triangle"). The reader is left to struggle, or expected to derive the equations herself.
In discussing the impact of open source on software vendors, Dirk examines an interesting strategy in which he envisions two existing, competing products. He shows how a failing competitor might cripple its more-successful rival by open sourcing its own, doomed product; if the community can keep it viable at no cost to its original owners, the abandoned product will provide a permanent drag on the victorious competitor's profits.
I'm not convinced this outcome is actually desirable. Admittedly, prices are lower, the loser's product remains available, ultimately both products are available as cheap community projects. What Dirk fails to consider here is capital: who will ever build new software, or new software companies, if they can be so easily destroyed? The scenario demonstrates how open source can act as an agent of capital destruction; it's not clear what role it plays in renewing this resource.
Finally, Dirk suggests that dominant community open source projects help developers by making it easier for them to find new jobs. If everyone uses Apache, then an Apache developer can easily pick up and work for anyone. This is not necessarily good news for employees:
Hiring and firing becomes easier because there’s a larger labor pool to draw from, and switching costs between employees are lower compared with the closed source situation. Given the natural imbalance between employers and employees, this aspect of open source is likely to increase competition for jobs and to drive down salaries.
Where the employee is a commodity, easily interchanged with another employee, then prudent management will drive wages and benefits down to subsistence levels. If developers don’t like subsistence wages, they can find another job. Unskilled labor, after all, is readily portable. As I wrote a few months ago:
We all woke up one day to find ourselves living in the software factory. The floor is hard, from time to time it gets very cold at night, and they say the factory is going to close and move somewhere else.
The essay suggests that rational developers should rush to become committers to successful open source projects; once securely ensconced in that role, they can command a premium salary (even though they may no longer have time to do actual work for their employer!). But will this work? There can only be a few committers; this seems a recipe for building a software world with a few well-paid foremen (who don't actually do any work) and a lot of poorly-paid mechanics who spend their days writing production code and their nights struggling to please the foreman and aspiring to reach the airy heights of open source. This seems a recipe for recreating the worst aspects of the labor union, stripped of the notion (sometimes, arguably, a pretense) that the union represents its members. In this brave future, we’re all going to be Teamsters.
My main concern, though, is that the framework is not developed in sufficient depth to be testable. Is the omission of capital a mere detail that might require amendment, or a consequential oversight that changes the result entirely? We don’t know; I don’t see any sure way to find out.
It requires capital to start a software project. The failing competitor can treat this as a sunk cost and write it off, and if Dirk is right all our existing software is destined to be Open Source or abandoned, and all the capital invested in these projects will be written off. Where the capital is then to be found for new software becomes an interesting question. I think Dirk assumes that willing volunteers will contribute sweat equity, and so the requisite capital will appear, but I don't think this is explicit in his model. Nor is it clear how the market could efficiently allocate this capital since there is no market! My guess at the software designer's exit strategy: lots of tiny firms that make artisanal software. Give people or businesses a unique and useful tool to do jobs that need doing, specialize, and keep well away from commodity software.
Update: Peter Merholz (whom I thought to be blissfully honeymooning in Dublin) deplores the design industry’s exploitation of its workers. “It's not uncommon for services firms to have their staff work 50+ hour weeks,” he observes. (A fifty hour week is light for me, but then again I have a great job and only myself to blame.)
Make sure you know the rate you’re billing out at, figure out how much money you’re bringing into the company, and how much of that you are seeing... Find out what your company’s profit margin is, and what the company is doing with those profits. You don’t need to put up with bullshit in order to work on sexy projects — I know design firms that land great work AND treat their employees well.