| date: | 2006-07-11 14:23:12 |
|---|---|
| category: | Economics of Software |
What is the reward structure for open source?
If a corporate IT team builds software using open source components, CP insists, they’ve made a fundamental blunder. I forget CP’s litany of concerns, but he worries that the software is unproven, untrustworthy, risky, etc., etc.
My argument that “you have the source” means nothing to CP, since any commercial license also has a complex source-escrow clause that – he claims – provides the same level of assurance. Unless, of course, your commercial package is no longer officially supported, then all bets are off. But somehow, lawyers will cover this base to CP’s satisfaction, and actually having the source isn’t as good.
But CP does raise one point of some value: what about innovation? What happens when the open source author moves on, and the package stagnates?
Rewarding Innovation
First, open source tends to be far more innovative than commercial products. We have to separate open source from individual efforts. In CP’s world, open source means an individual developer slaving away for the love of the craft. This is often false, and consequently, misleading.
An individual contributor’s rewards are clearly different from an open source community’s reward structure. And, of course, corporate users of open source have their own internal rewards, as well as a contribution to the open source author (or community) rewards. Since all of these are separate, it’s helpful to have a nice Information Week article to lay out some of the issues.
Corporate IT Rewards
As a consumer of OS projects, a corporate IT department is rewarded by implementing (a) cheap, and (b) effective solutions to problems. Open Source software tends to be more standardized than commercial products, making it more adaptable. Further, the presence of the source, makes it easier to understand, adapt and maintain. It’s a big win, all the way around.
But how can corporate IT reward an open source community or the authors?
Acknowledgment is a significant part of the reward structure. Corporate IT should clearly and boldly document the technology stack for the various applications that are built and maintained. Intranet web sites should have links and logos for the OS projects. Since corporate users now have to support the OS project, they should become active, visible members of the community.
Serious use of Open Source projects means that the solution developers can find problems, extensions and new directions. Much of this can help the open source community. Feedback – in the form of fixes and extensions – is what validates the design of an Open Source project. This intellectual investment increases the value of the project.
What About Money?
Money is always a good thing. Some open source authors have day jobs because their open source project is so valuable. A company is willing to put up with time spent nurturing an open source community, in order to maximize the value from the open source project.
In the more common case, the open source author has a day job and builds open source solutions entirely outside their work life. Their company is unwilling to foster an open source community. Or their company doesn’t make direct use of the open source project.
Perhaps the most rare situation arises with OS projects that also have commercially usable counterparts. MySQL, for example, has a commercial license, as well as supporting an open source community.
Conflicts and Shifts
Babcock’s article identifies the conflicting goals of creating proprietary solutions that include open source components. This provides some prominent reasons why open source contributors aren’t rewarded appropriately for their contributions.
Perhaps, however, as open source use matures, the economics will shift.
Currently, we have two ways of using open source components.
There are many war stories where people find that open source was expensive, perhaps because of the support required. This is not a third scenario, because it leads to open source being banned or deprecated. Once consequence of an official position against open sources is that it forces the organization to use PERL, Apache and Linux in Blind Trust mode.
Using Open Source software in Healthy Respect mode means that we put OS projects through the same processes we put our in-house solutions.
All of these quality-related activities feed back to the open source community. But more importantly, the people being paid to do this work, are being paid to create and maintain open source projects.
This mature use of open source puts a solid, predictable, corporate-friendly reward structure in place. Once people are paid to contribute, the “business risks” are eliminated; eliminated in the sense that being able to explain the reward structure to lawyers and accountants reduces the sillier objections to open source solutions.