Thursday's panel debate brings together months of scathing remarks and heated retorts from all sides of the issue, and its outcome will be anybody's guess. But in the midst of the drama, we've lost sight of several important ideas that lie somewhere in the middle.
Let's start with a few assumptions. First, all software needs a critical mass of developers to build it, maintain it, and make it usable for others. Second, developers will not always magically appear around an open-source project once it's launched; "if you build it, they will come" is not always true, and there are plenty of stillborn open-source projects that provide evidence for that.
Third, not all users of the software will want to become developers of it or to even get technical enough to know how to compile it themselves.
In this situation, though an open-source approach would work in theory, the reality is that the only software likely to get created will use a license that mandates payments back to the software's authors--in other words, a non-open-source license.
The real meaning behind the license
However, unlike the claims of some people on the open-source side of the recent debates, this does not mean that such a license has to involve hiding the source code, preventing end users from modifying it or even from redistributing it. It also doesn't mean that "if a company goes out of business or stops supporting a product, you're out of luck."
Nor does it necessarily mean that once you view that code, you're "tainted," any more than viewing GPL code would taint you when working on a similar non-GPL project.
It may be that Microsoft's shared-source initiative does, in fact, carry these nasty implications--that indeed, you don't get access to the source code a developer really needs to be effective, or that modifying and redistributing those changes is arbitrarily cumbersome, or that signing a fierce NDA will be required. We won't know until Microsoft officially launches the program.
Certainly, Microsoft's recent licensing on their mobile software developer's kit, preventing linking against specific code under the GPL or Mozilla license, suggests it still has a lot to learn in this market. But other companies are successfully starting to tread the middle ground between closed and open in those situations where a purely open-source approach might not return an advantage.
Companies have been selectively sharing source code between themselves for years. For example, there's the company that delivers a software development kit to its manufacturing partners, updated twice a year; an outsourcing company in India being given a specification and returning a finished component in six months, necessitating a couple more months of integration; or even joint projects between groups of companies, where the source code remains with that project, and when the project dies, so does the code.
What the open-source community has proven is that individuals--and, by extension, companies--can work together on a much more discrete, iterative level. Rather than these big-block handoffs as described above, people are starting to understand that having interaction between developers on a daily basis during development is far more valuable than waiting through the typical product-revision cycles. It may seem chaotic at times; for programmers, balancing the requirements of their employers with that of the other participants may be a constant challenge. But it can work.
I've written before that the strength of the open-source process comes from the practical benefits of coordinated distributed development, not necessarily from the rules imposed by any particular license. There are some aspects of software development that are certainly enhanced by using an open-source license, such as the potential for widespread peer review, or the serendipic value of a bug report with a patch provided, but that doesn't mean the other benefits don't also apply.
For example, Hewlett-Packard's printing and imaging division recently adopted a software development infrastructure that allows the company to bring its other business partners closer to its day-to-day software development practices. The license on the software is the same, but the degree of access by those partners to their development processes is increased. This allows the engineers at these other companies to participate more closely with HP's engineers--finding and fixing bugs that HP alone might not have caught, and influencing the direction of the code more efficiently than before.
HP has also realized internal efficiencies by doing this. Whereas before, the software code repositories and issue-tracking systems were spread out within the company and usually were tied to geographic location, having the code in a common, high-availability place has increased the amount of knowledge transfer within the company overall. This kind of cross-project communication is quite valuable, and to see companies start to adopt this process internally is great.
This week's gathering in San Diego provides a unique opportunity to look at the terms of the debate in a new way. Open-source advocates should welcome attempts to explore more of this middle ground, because the more that companies realize the benefits of making their source code more widely available, under any license, the closer that company is to considering opening it even more widely.
Biography
Brian Behlendorf is founder and chief technology officer of CollabNet and co-founder and president of The Apache Software Foundation.
