X

Decoding the "FUD" surrounding open source

Microsoft may have other ideas, but Richard French argues that Linux, and open-source software in general, can in fact coexist with proprietary software.

4 min read
In his recent column, Jack MacCrisken criticized open-source advocates for treating the merits of open source vs. proprietary software development as a simplistic battle between the forces of good and evil.

Let's be clear. It's Microsoft that diagnosed Linux as a supposed "cancer" and polarized the debate to begin with. (Read MacCrisken's column here.) So I'm here to offer a second opinion.

Contrary to Steve Ballmer's misinformed prognosis, the weight of evidence shows that Linux, and open-source software in general, can in fact coexist with proprietary software. Companies including Oracle, IBM and Hewlett-Packard are successfully using open-source software--including GPL software--with no harmful side effects or infection of their intellectual properties.

Furthermore, as others have pointed out, many open-source licenses, such as the IBM Public License, the MPL, and BSD-type licenses, enable and facilitate the peaceful coexistence of open-source and proprietary software in different ways.

This may come as a surprise to Jack, but as a passionate advocate of the open-source development model, I am also realistic about where it's applicable today.

Not "all or nothing"
For companies accustomed to proprietary software development, determining where it makes strategic sense to "go open source" can present a significant challenge. And contrary to what Microsoft may want you to believe, it's far from an all-or-nothing proposition.

As it turns out, many companies today choose to develop and release the source code for specific pieces of software under open-source licenses for sound business reasons: to leverage rapid innovation; to improve cost savings in research and development; to increase quality assurance and support; to build a broad base of developers, advocates and consumers; and even set standards for specific market segments.

CEPS, the Cisco Enterprise Print System, is a classic example of infrastructure software that was released under the GPL to maximize the cost benefits of leveraging a larger community of developers and testers and to make sure that the code would continue to be supported in the future.

Similarly, HP has contributed a significant amount of open-source printing software to improve printing solutions for Linux, thereby demonstrating leadership as a provider of printing hardware.

Many other companies choose to contribute to existing software projects, because it often helps them with the development, support and sales of their products. Vendors that have contributed software code to Samba, for example, include HP, IBM, SGI, Sun Microsystems, VA Linux Systems and Veritas Software.

Decoding Microsoft FUD
After all is said and done, what's buried under all of Microsoft's anti-open source fear, uncertainty and doubt (or "FUD," as coined by IBM's Gene Amdahl) is its own little secret: The Redmond empire is quite happy to fund open-source development when it suits its purposes.

For example, in 1999, ActiveState announced that Microsoft was funding a three-year initiative to enhance and extend the popular open-source programming language, Perl--a technology so pervasive that it has been referred to as "the duct-tape of the Internet." Microsoft could no longer ignore support requests from customers running Unix who wanted interoperability across platforms. Helping open-source Perl grow on Windows helps Microsoft sell more copies of Windows. Moreover, as others have pointed out, Microsoft Windows itself makes use of many other open-source technologies such as Kerberos security.

Once a company has decided to adopt an open-source development strategy, planning and implementing the open-source release is the next challenge. Proper planning, guidelines and grassroots publicity can often make all the difference in how successful an open-source project is, particularly in terms of creating a community of developers and consumers.

The Open Source Development Network (OSDN) realizes that not all companies are ready to make the leap into developing open-source software themselves. In fact, many of our customers have come to us asking for help in how to learn from and leverage open-source best practices, collaborative tools and methodologies.

SourceForge OnSite, an enterprise-class collaborative development solution, takes the best of the standard open-source development tool set available on SourceForge.net and makes it easy for companies to use internally, most often for proprietary software development.

Apparently Microsoft, with its "shared source" strategy, is just now beginning to acknowledge that it may have a thing or two to learn from the open-source collaborative development model. This comes as no surprise to me, given that SourceForge.net supports more than 9,000 open-source software projects for Microsoft platforms.

On behalf of OSDN, I welcome not only Microsoft developers, but also Microsoft managers, to continue to explore all that open source and OSDN have to offer. If Microsoft is interested in contributing to open-source software projects, we're more than happy to show Microsoft the way.