This is a read-only archive. Find the latest Linux articles, documentation, and answers at the new Linux.com!

Linux.com

Feature: Java

Java and open source

By Mark Stone on November 12, 2004 (8:00:00 AM)

Share    Print    Comments   

Recent debates about open sourcing Java overlook the unique character of programming languages: the open source code that is written in a language is often more important than the open source status of the language itself. In this article we'll move away from questions about the Java language, and instead look at how technology companies relate to the large amount of open source programming being done in Java.
Language as enabling platform

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

Share    Print    Comments   

Comments

on Java and open source

Note: Comments are owned by the poster. We are not responsible for their content.

Not really paying attention again, author?

Posted by: Anonymous Coward on November 12, 2004 11:28 PM
From the article:

* 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")

Explain to me how one has the freedom to redistribute their modifications even though they don't have the freedom to modify it. How does that work? Also, does libre not also include the right to redistribute? I don't think you understand both these terms.

Look <A HREF="http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&selm=1992May11.134415.21977%40sunb10.cs.uiuc.edu" title="google.com">here</a google.com> for more info. Libre means that it is free to do whatever you want with it. Gratis means its simply free of charge. Some Gratis software isn't even open source and forbids you modify and redistribute.

#

Re:Not really paying attention again, author?

Posted by: Anonymous Coward on November 15, 2004 09:26 AM
Amen. Let's suppose that Java does become *the* language to use, supplanting even C and C++. So what happens when (not if, when) Sun decides, "OK, now that we've got dominance in these markets, let's close down Java even more than it is now and charge people boatloads?"

This is what Richard Stallman and others have been warning against for years. Were Sun to make Java into a truly Free language, then, if they did decide to make their specific implementation non-free, then that's fine. The language being truly Free, we would then be free to implement it ourselves. It is for this reason, among others, that C and C++ are so popular, and Pascal before it; while there were many non-Free implementations of these languages, the languages themselves are Free.

Free Software is not about price. It's about freedom--freedom to do what you want with it and not restricting those same freedoms from others.

Oh, BTW, the author is factually incorrect; Java is *not* freely redistributable. Read the license.

#

communitysource

Posted by: carmello on November 12, 2004 11:57 PM

Re:communitysource

Posted by: Anonymous Coward on November 14, 2004 06:08 AM
Sun Community Source License (SCSL) isn't an OSI-approved open-source license.

And for good reason, it's not anywhere near fulfilling the requirements. SCSL is not any more open source than Microsoft's 'Shared source initiative'.

#

Re:communitysource

Posted by: carmello on November 14, 2004 06:38 AM
You can also get it under Java Research License (JRL). Not an open source licence too but why do we need an open source Java?
Most developers don't look at the source (except maybe from src.zip).
Most people who look at the source don't change anything, so for that people the JRL should be good enuff.

And there are allready open source implementations
like gnu classpath, which is 71.72% compatible with 1.4.

http://weblogs.java.net/blog/editors/archives/200<nobr>4<wbr></nobr> /11/source_on_the_s.html

#

This is total crap.

Posted by: Anonymous Coward on November 14, 2004 06:23 AM
Mr. Stone. You write an entire article in NewsForge, the so-called "Online Newspaper for Linux and Open Source" on the subject of Java and open source, and the main point is that freedom to redistribute is important, not freedom to modify.

I guess you should rename yourselves the online newspaper of Freeware.

But even this point is irrelevant. JAVA IS NOT FREELY REDISTRIBUTABLE. Few Linux distributions include Java since they cannot accept Sun's terms of redistribution. Most developers also find these terms highly encumbering.

And in this rather long article, couldn't you at least have paid lip-service to those Open Source java implementations which do exist?
The GCJ native compiler, the GIJ java VM, the Kaffe VM, SableVM, JamVM, Japhar, and so on, and more importantly the class library used by most of these, GNU Classpath (Which has been undergoing rapid development lately and has set a date for its 1.0 release.)

I really thought Newsforge was a promotor of open source software, not an apologist for popular non-OSS software.

#

Re:This is total crap.

Posted by: Anonymous Coward on November 14, 2004 08:45 AM
NewsForge is a profitable business. Just like any other business. Welcome to the real world. See the ads?

#

Re:This is total crap.

Posted by: Anonymous Coward on November 14, 2004 10:37 AM
<A HREF="http://adblock.mozdev.org/" title="mozdev.org">No</a mozdev.org>.

#

Good article

Posted by: Anonymous Coward on November 15, 2004 04:46 PM
I think the article makes so good points here. Instead of ranting over two lines about what free is , the main issue here is about how companies can leverage open source in combination with their own business goals.

If businesses can't make money out of open source, open source will die.

Although Java isn't open source it doesn't prevent me from writing open source applications.

I agree though that the licensing of Java should at least be modified so that distribution of Java by Linux distributions should be possible. This with greatly expand the usage of the language because java applications can then be delivered (think about Tomcat etc.).

#

Bull.

Posted by: Anonymous Coward on November 16, 2004 01:33 AM
"If businesses can't make money out of open source, open source will die."

What are you smoking? Free and open source software long predate the viable existence of a personal computer business, let alone the PC software business. If your theory made any sense, FOSS would have "died" a long time ago.

#

No, No, No, and NO!

Posted by: Anonymous Coward on November 16, 2004 01:32 AM
Developing on a platform that isn't open is just leaving you open to the charity of the people controling the platform.

What good is it to develop free and open source software if there is a very real possibility that the software could simply stop working with some future version and a license change could prevent you from making your application work with it.

The development time would all have been wasted.

Don't make the mistake of simply ignoring the platform you are running on.

You are a slave to the licenses you use. You better pick wisely.

#

Re:No, No, No, and NO!

Posted by: Anonymous Coward on November 16, 2004 04:11 AM
That is the point. The work on a platform is often worth a very significant multiple of the platform itself. Any application on a non-free platform is more or less hostage of the will of the platform owner and his fate. For very good reasons, many of the free software products are platforms, e.g. the OS, to name just one. It is all a very, very economic decision. It is ways cheaper to develop a free (libre) platform and then use it but to use a cheap, but only beer-free one and loose you investment in the end.

#

Java is irrelevant

Posted by: Anonymous Coward on November 16, 2004 02:03 AM
Python is where it is at. And for so many reasons:

  • Python is clean, and stays clean
  • Python is fast for development
  • Python is cross platform
  • Python is redistributable
  • Python is easy to learn
  • Python is not subject to the rule of any company
  • Python works with<nobr> <wbr></nobr>.Net (IronPython)

Need I go on?

#

Java is MS-JAVA from MS-SUN

Posted by: Anonymous Coward on November 17, 2004 08:54 AM
And it all belongs to Microscoff and Robber Baron Billy

#

This story has been archived. Comments can no longer be posted.



 
Tableless layout Validate XHTML 1.0 Strict Validate CSS Powered by Xaraya