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.
- Blind Trust. We download it, use it, and hope that the rest of the community has thoroughly vetted the project. This is the way most organizations use products like Apache or Linux. They just download it and use it without giving it much more thought than that.
- Healthy Respect. We download it, put it through an acceptance test cycle, and determine that it is fit for purpose and can be used in our in-house solutions.
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.
- Configuration Management. Rather than simply downloading blindly, someone is in charge of a subversion (or CVS) repository for the latest and greatest, the official, the development and the testing releases of open source packages. This person can create value in the OS community by validating the releases.
- Testing. Rather than implementing blindly, someone has specific use cases, and conducts performance, integration, and functional tests. This person can create value in the OS community by reporting bugs.
- Patching. Rather than deprecating OS software, someone can look into the problem, and determine if it is fixable and how to share the fix.
- Extending. Perhaps the most valuable contribution from a mature organization is the extensions and new directions for an open source project.
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.