Author: Mark Stone
For a developer, nothing is more important about a computer than the ability to program it. One could argue that Linux was was born out of Linus Torvalds’ desire to have something with a C compiler on it in his own home. Having free and unfettered access to a programming language has been a priority for developers since the early days of personal computing. This demand was enough for a young Bill Gates to make a business out of developing and distributing Altair BASIC, and enough to frustrate him when he found that most copies of Altair BASIC were being distributed without compensation to his company.
Gates responded in 1976 with an open letter to hobbyists, in which he said (see Reference 1): “Who can afford to do professional work for nothing? What hobbyist can put 3-man years into programming, finding all bugs, documenting his product and distribute for free?” He concluded that the free redistribution of Altair BASIC was hurting software development: “One thing you do do is prevent good software from being written.”
The passage of time would seem to have proved Gates wrong. A programming language is a developer’s enabling platform, and the more freely and widely available that platform is, the more good software gets written. Even Microsoft seems to have overcome, and perhaps even benefited from, the free redistribution of Altair BASIC. The puzzles Gates faced still plague technology companies today, however, as they struggle to couple business models to the marketing mechanisms of free redistribution.
Libre or gratis?
Open source has two key components:
- The right to freely modify (software libre, or “free as in speech”)
- The right to freely redistribute, including modifications (software gratis, or “free as in beer”)
For programming languages, the latter is far more significant than the former. Perl provides a good example. Relatively few programmers have the skill or interest in modifying the Perl language itself, and indeed the core Perl development team isn’t particularly interested in outside contributions. So while Perl happens to be open source, that fact hardly matters to the Perl community. What does matter is that the Perl interpreter can be freely redistributed, enabling developers to create and use Perl programs without restriction.
“Free as in beer” is the force that has created over 7000 modules from 4000 authors in the Comprehensive Perl Archive Network(CPAN; see Reference 2). This is the force that has created over 5000 Perl projects on SourceForge.net (See Reference 3).
Does that make Perl the most popular language for projects on SourceForge.net? Not by a long shot. Both C and C++ have over 13,000 projects, and in a close third with 13,066 projects is Java.
Building business around a programming language
Java is all but open source. Being freely available, it has propogated an enormous and important body of Java-based software, both proprietary and open source. Many of the key business paradoxes around open source come to the fore with Java as well: How does Sun or any other company make money from something given away for free? Nearly thirty years later, do we have any better answers to the questions posed by Bill Gates’ open letter?
Freely distributable products engender three different business models:
- Market growth
- Market penetration
- Market preemption
All three of these strategies assume you have a product complimented by what you are giving away which gains substantial marketing benefits from the give-away. Let’s look at each of these in turn.
Market growth
Giving a product away for free encourages consumption. Increasing consumption of that product not only increases the size of the market for that product, but for any products and services that accompany that product. Because Linux is freely available, it gains market share in the operating systems market, and thus increases market size for Linux-related products and services. This enables a company like IBM, for example, to make money off of the hardware underneath Linux by promoting Linux and thus increasing the market for that hardware, as well as to make money off of services by promoting Linux and thus increasing the demand for Linux expertise within IBM Global Services.
Sun’s attempt to make Java ubiquitous was driven by similar motivations. Sun’s primary source of revenue derives from Sun hardware. Promoting Java’s “write once, run anywhere” philosophy aimed to bring Java to new hardware markets such as embedded systems, and to enable Sun to extend its business to those new markets on the basis of its Java expertise.
“Write once, run anywhere” has proved a double-edged sword, however. Among the platforms where Java runs well is the family of Intel-compatible x86 platform. Anyone willing and able to provide Java support on x86 can offer an architecture that competes directly with Sun’s core SPARC-based business. There are companies that have followed precisely this business strategy, with BEA being the leading example.
Further, other companies are pursuing a strategy parallel to and competing with Sun’s. Whether or not this was Sun’s original intention, Java now competes as one of several languages for the enterprise software development market. Probably the next leading candidate for an enterprise language is Microsoft’s C#. Even some traditional open source developers see a lot Microsoft has done right with C# (see Reference 4).
Market penetration
A large part of the business battle around Java, then, has to do with growing the market for Java as an enterprise software solution. The highest profile competition here is between Sun (Java, J2EE) and Microsoft (C#, .NET).
Part of the business battle, however, has to do with market penetration: Companies offering Java-based products and services vie for market share within the enterprise market already committed to Java. Here companies like Sun and BEA compete.
The result is an odd kind of coopetition (cooperation and competition). Both Sun and BEA want to advance Java as an enterprise software solution over C#, and thus they must in some sense cooperate. Still BEA’s Weblogic Platform (see Reference 5) competes with the Sun Java Enterprise System (see Reference 6).
Open source Java development can have a profound impact on these competitive balances of power. The existence of a freely available Java program may incline a company to favor Java over a competitor such as C#. The choice of open source developers to focus on Java also assures that good, freely available Java software will continue to proliferate. All of these factors affect the battle for Java market growth.
Market penetration is crucially affected by how a company positions its products with respect to open source projects. How much of the demand for Java software will actually be met by open source projects? And that leads us to the third aspect of marketing strategy.
Market preemption
The existence of a quality open source project in a particular technology market can preempt competition from proprietary software vendors.
Sleepycat Software (see Reference 7) has enjoyed success for years with its Berkeley DB embedded database. Because Berkeley DB is open source and freely available, it’s tough for anyone to introduce a competing product. Berkeley DB can’t be beat on price, and it has the full backing of Sleepycat for quality and support.
Sleepycat makes money by offering a complimentary product: Berkeley DB. While it’s rare for a product to be its own compliment, it is possible. The open source version of Berkeley DB comes with a “viral” license, meaning other software with which it is combined must also be open source. Given that this is embedded software we’re talking about — inherently meant to be combined with other software — that viral aspect is often unacceptable to companies looking to harness Berkeley DB as part of a larger product.
The result: they re-license a proprietary version from the license-holder, namely Sleepycat Software.
This is an extreme case of a more general open source business lesson: If an open source project preempts competition in a given technology market, that project can benefit your business if you can build complimentary products and services for the same market tied to that project.
Both Sun and BEA have carefully chosen marketing strategies built around Java and open source. They are, however, two very different strategies reflecting two different business priorities.
Drawing in to push a market out
To understand Sun’s open source strategy around Java, let’s look at a particular project with which Sun is heavily involved.
JOGL provides a Java wrapper to the OpenGL API (see Reference 8). While initiated by engineers at Sun, to be successful the project requires collaboration between several groups with different interests. For game companies this is an important project as it opens up the talent pool of Java programmers to technical graphics problems in game programming that were previously inaccessible to Java. For Java programmers it opens new opportunities in game programming. And for Sun it extends Java’s market reach further into the gaming market. This latter point is key.
As the creator of Java, Sun’s highest priority has to be market growth: Creating more demand for Java-based solutions. Towards that end, the more Java open source projects there are, the more open source developers focus on Java as their language of choice, and the more competitive Java will be compared to alternatives.
Sun does face one significant problem resulting from its decision not to open source the Java language itself. Any attempt by Sun to push Java developers in a particular direction can be perceived as overly authoritarian. Sun risks coming down on the wrong side of a delicate balance between controlling and owning on the hand vs. supporting and leading on the other hand. Open sourcing Java would alleviate fears that overtures by Sun have an ulterior motive revealed in Java licensing changes that developers are powerless to affect.
Unwilling to open source Java, Sun has made several other careful steps to support the growth of Java without appearing overly controlling. One of the most broad-reaching efforts in this regard is the Java Community Process (see Reference 9), an attempt to mimic the best practices of the Internet Engineering Task Force (IETF; see Reference 10) within the Java Community.
JOGL development could have been centered in any of several destinations. Sun could have kept the project in-house. This, however, would have made coordination with OpenGL members difficult, and done little to encourage participation by game programmers. Sun could have put the project on a third party site like SourceForge.net. Sun seldom turns to SourceForge.net for project hosting, however, perhaps wanting tighter communication and control over the process. Some sort of neutral ground is needed, however. Having an established neutral ground enables collaboration between different and sometimes diverging interests (OpenGL, game programmers, Sun Engineering) that would otherwise be difficult.
Sun’s solution to this dilemma has been Java.net (see Reference 11). The site self-proclaims that its aim is to “provide a common area for interesting conversations and innovative development projects related to Java technology.” While Sun Engineering provides the largest impetous for projects on the site, in the year and a half of its existence Java.net has garnered significant outside participation, with over 1,300 open source projects hosted and over 90,000 registered members.
JOGL is just one of these many projects, but it is typical of Sun’s strategy. Sun Engineering needs effective channels of communication with outside Java developers and other companies with a vested interest in various directions in Java technology. Outside developers need a roadmap of where Java is going. Different groups working on common problems need to not reinvent the wheel. Common problems need standardized approaches to solutions. A community portal like Java.net provides the communication links and common destinations that make this possible.
For Sun, Java.net is a non-threatening way of drawing the open source Java community closer to itself, a way of providing leadership without implying ownership. This approach works because while Java.net is Sun-owned, its stewardship is in the hands of third parties: O’Reilly, Collab.net, and senior editor Daniel Steinberg (formerly of IBM Developer Works).
Reaching out to draw a market in
A typical open source project from BEA reveals a different story and a different strategy.
Beehive is an official project within Apache. As an application development environment for J2EE, Beehive consists of three main parts:
- Metadata management for struts, called “PageFlows”
- A lightweight component framework called “Controls”
- A Web services layer implementing JSR-181
Two aspects of BEA’s Beehive strategy are significant. First, the key constituents of Beehive were all developed in-house at BEA as improvements to the WebLogic platform. Rather than keep these as value-adds to WebLogic, BEA chose to release Beehive as open source. Second, BEA did not attempt to create a BEA-controlled and managed development center for Beehive, but instead worked to make Beehive part of Apache, following the procedures of the Apache Software Foundation (see Reference 12).
While BEA benefits from continued expansion of the Java market, its most immediate concern is to be a leader within that market. In other words, market penetration takes precedence over market reach. What complicates market penetration, however, is the threat of market preemption by successful open source projects.
Not only does WebLogic Platform compete with products from Sun (as well as products from IBM, Oracle, and others competing in the Java space), it also competes to some extent with solutions derived from Apache’s Jakarta project, such as Tomcat (see Reference 13). It would be natural to expect BEA to wall itself off from open source in an attempt to differentiate and compete by providing added value in terms of service, support, and ease of use. Certainly this is a strategy many other companies find tempting when confronted with competition from open source.
In fact BEA’s strategy has been the opposite. They have become heavily involved in open source, not by trying to guide or direct as Sun does, but by participating from a grass roots level on up.
Cliff Schmidt, BEA’s Product Manager of Standards and Open Source Strategy, has offered a revealing interview on BEA’s open source approach (see Reference 14). Of Beehive, Schmidt says, “we felt like there were plenty of reasons to try to get that out there and collaborate with other people in the open source community and make it something that is not just about BEA but for all of Java.” More specifically Schmidt differentiates between “out-bound” projects, where BEA contributes code as open source, and “in-bound” projects, where BEA incorporates open source code into some part of its own technology.
Part of the outbound strategy is about market reach for Java overall. Says Schmidt, “Sometimes it is because the Java community needs it and our business is based largely on the Java community…. We felt like bringing this Beehive project out to the open source community was going to expand the Java pie basically and you know we have a business interest in making sure that pie keeps growing.”
It is the inbound strategy that is most revealing, however. Schmidt notes that incorporating open source is not without risk. For example, “There are legal issues that if you are not aware of you are putting yourself at risk. If you just blindly grab something and stick it in your product without paying attention to it you are putting yourself and your shareholders at risk.” However, he points out that some companies prey on that perceived risk, and “use fear, uncertainty and doubts to sell their products.”
Schmidt contrasts this with BEA’s view, saying, “software corporations… like to throw around the word community and it is a nice thing to say, but really if we want to make our customers happier we want them to be in the community that is vibrant and is as large as possible with as many resources going into as can be.” By being part of a vibrant open source community, BEA can leverage what the community produces on its customers’ behalf, while providing the stability and reassurance of corporate backing that open source on its own may lack. The bottom line, according to Schmidt, “It is important to us that open source remains viable forever and I think that is probably going to happen with or without BEA.”
In essence, BEA’s view appears to be this: The continued success of open source is inevitable, even if other companies choose to ignore it or spread fear, uncertainty, and doubt about it. The only reasonable response, then, is to allow and even encourage open source to further commoditize components of the enterprise software stack, while providing value further up the stack. Other companies (read: Microsoft) will be preempted by their unwillingness to embrace open source, while BEA will continue to build software that compliments what open source commoditizes.
BEA won’t make money directly off of Beehive. Beehive will, however, serve as a powerful marketing tool for BEA. The more useful Beehive is perceived to be, the more valuable its Weblogic progenitor will be perceived to be. Hence customers are more likely to turn to Weblogic as a solution when they lack the time or expertise to “roll their own” solution with Beehive.
Conclusion
Businesses and developers who fret about whether or not Java is or will become open source are missing the point. The free availability and near ubiquity of Java in the enterprise software market means that the open source software being created with Java is much more interesting than the open source status of Java.
Companies basing their business on Java software must have a well defined strategy about open source. A simple “ignore” or “accept” will not do. Companies as different as Sun and BEA see business value in open source, yet engage open source in very different ways. To succeed today, you must know how to match your business’ value with the value of open source.
References
Reference 1: “An Open Letter to Hobbyists”, reprinted at http://www.blinkenlights.com/classiccmp/gateswhine.html
Reference 2: CPAN, http://www.cpan.org
Reference 3: SourceForge.net project by language:
http://sourceforge.net/softwaremap/trove_list.php?form_cat=160
Reference 4: “A Conversation with San Mehat”,
http://webservices.devchannel.org/webserviceschannel/03/05/28/0821232.shtml
Reference 5: BEA WebLogic Platform, http://www.bea.com/framework.jsp?CNT=index.htm&FP=/content/products/platform
Reference 6: Sun Java Enterprise System, http://wwws.sun.com/software/javaenterprisesystem/index.html
Reference 7: Sleepycat Software, http://www.sleepycat.com
Reference 8: The JOGL project, http://today.java.net/pub/a/today/2004/10/15/jogl.html
Reference 9: The Java Community Process, http://www.jcp.org
Reference 10 The Internet Engineering Task Force, http://www.ietf.org
Reference 11: Java.net, http://www.java.net
Reference 12: The Apache Software Foundation and its project incubation policy,
http://incubator.apache.org/incubation/Incubation_Policy.html
Reference 13: Apache Tomcat, http://jakarta.apache.org/tomcat/
Reference 14: An Interview with Cliff Schmidt, http://dev2dev.bea.com/trainingevents/dev2devlive/cliffschmidt.jsp
Category:
- Java
