I spent some time this week with some friends from the Portland Perl Mongers (PDX.pm) at 2007’s first meeting, devoted to Web app frameworks, games, and Martinis, in no particular order. Just as Seattle is blessed with a vibrant Ruby community (the Ruby Brigade meets up on Capitol Hill), Portland has a truly exceptional Perl community. At any given PDX.pm meeting, you’re likely to see any number of O’Reilly authors, high level Perl monks, and authors of CPAN modules you use regularly.
(Whether or not you know that you use them, the Perl language and its Comprehensive Perl Archive Network, or CPAN, are the behind-the-scenes heavy lifters of a great deal of the dynamic Web. The “modules” on CPAN are rarely applications themselves, but are underlying code libraries or components that enable user applications.)
Many of these luminary or guru type attendees at the PDX.pm, therefore, are effectively vendors and colleagues to those of us who have written Perl software using CPAN modules — whether or not we’ve ever met. And yet, apart from the occasional pint of beer, or royalties on an O’Reilly book or two, most of us will never pay (at least not directly) these Perl gurus for their work. This got me thinking, and, as I get to below, also got me somewhat concerned.
Open Source Software (OSS), including Perl itself and the modules on CPAN, is much loved in the business world due, in part, to its compelling price tag. Some OSS, like the Linux kernel, is developed with a great deal of assistance from commercial entities, who are often motivated to increase compatibility with their product offerings (as in driver development) or to serve some internal functionality requirement. But a dirty secret — one whose propagation has been discouraged by the promoters of OSS as part of their mostly laudable efforts to gain for it the same credibility enjoyed by commercial software — is that a vast amount of OSS is in fact written and / or maintained by the “volunteer” developers of lore. These folks are, I must emphasize, not amateur or “unprofessional” — indeed, the reason that many OSS developers / maintainers undertake the task is for professional recognition or advancement — it is simply that they have no (or only intermittent) direct economic ties to the software they maintain. Therefore, in many cases, you might have a software module whose author maintains it “out of the goodness of his heart.” Without the financial lever, users of the module cannot compel him to resume development if it falls off of his list of priorities.
(Note that I do not condemn OSS on this account; from the user’s perspective, the benefit of having free and unfettered access to the source code, in combination with the gratis price, should more than make up for the incremental uncertainty added by the reduced extortibility of the author.)
What is gained for the author and maintainer of, for example, CPAN modules, is a measure of respect and credibility among his peers. The merry band of geeks at PDX.pm, for example, treats certain of its guru alumni like conquering heroes when they return to give a talk. And I have no doubt that such a status gains one an entree when seeking consulting contracts or employment. But it’s not guaranteed, and just as the user has no leverage over the author, the author has no leverage over his users by which to demand a quid pro quo.
A disturbing consequence of this economic model came up explicitly in the PDX.pm post-meeting chatter at the Lucky Lab, however. There exist major contributors to software projects relied upon and used by thousands (if not millions; and in the case of Perl and its indirect users, it would not be much hyperbole to say a billion) of people — which OSS contributors essentially live in poverty.
Why is this, more so than other forms of poverty, especially disturbing? Well, for starters, these people are clearly creating economic value, but are martyrs to a system that doesn’t pay them back.
That open source is economically valuable may not be obvious to an Econ 101 student or the less thoughtful MBA, but even a nontechnical executive can look at the market cap of e.g. Red Hat ($4.2 B as of January 2007) and consider their ability to get there with only 1,100 employees (that’s $3.8 M per employee, comparable to $4.3 M for e.g. Microsoft, who is nearly 70x larger and is of course the global market leader and therefore presumably can get away with less SG&A per developer, and much more than $1.6 M for Oracle). If that doesn’t convince you, consider the replacement cost of many open-source products with their proprietary counterparts, and even applying a devil’s advocate discount, we find that the OSS developers are creating something worth money — yet, they often capture little or none of that for themselves.
So, although a brilliant developer on his own (or in loose collaboration with a few like minds across the world) can produce some useful thing that we believe to be worth money, that same individual has quite a challenge before him to monetize that work. And in fact, the rewards he seeks — recognition and social credit among peers — are best gained in precisely the circumstances that (are conventionally believed to) preclude monetization. By that, I mean that being a great software guru these days is best achieved by having others read and admire your code — which is done by open-sourcing it — and which in turn (notionally) stops you from extracting a fee from consumers.
Therefore, an injustice is done here because the rewards of good work are distributed not merely inequitably but in fact not at all to those who perform the work.
Another, and more practical consequence, is that there are any number of important parts of any sophisticated open-source software stack that are cared for by persons in limited or sometimes precarious personal situations. I mean cases like developers without health insurance, developers who share rooms with dodgy roommates, developers who could be staring down tax liens. You may point out that there are many more and poorer folks than OSS developers to worry about; of course this is true. But OSS developers are providing the raw materials from which innumerable startups (and incumbents!) are driving the highest-growth parts of our economy and building substantial empires.
There are very real risks for users of OSS that a dependency for some major project could fall victim to the personal hardships of a developer, if, for example, he is made to seek other work to support himself or if he falls ill without insurance. In the biggest cases (say, Google), the firm running the dependent project could simply take over the code — but in the case of a startup building on an OSS stack, the danger looms rather larger.
I have no grand plan to remedy this. And I don’t think that the (terminally broken anyhow) music copyright regime gives us much guidance. While in music it is the peripheral producers who languish unpaid and the stars who get big dollars, in the case of OSS developers, often the marginal producers are comfortably paid corporate contributors while the true “rock stars” of OSS go broke.
And although a large part of this problem comes from the effective waiver of copyright inherent in OSS, closed source software is not the answer. Closed source software (at least that which is meant to be used by developers or geeks) sucks too much.
Probably the closest I have to a recommendation on this is that users of OSS find and reward the “stars” of projects they depend heavily upon. And, having said that, I am off to send money to Bram’s Ugandan orphan
s (for the incomparable vim) and beer and pizza to the GNU Screen guys.