Open languages are not required

There has been a lot of discussion over the past few months about Java, and whether it is an open language or a proprietary language. This has led to speculation about whether it makes sense to invest in Java, should the language be determined as...


There has been a lot of discussion over the past few months about Java, and whether it is an open language or a proprietary language. This has led to speculation about whether it makes sense to invest in Java, should the language be determined as under the sole control and direction of its new steward, Oracle. In this scenario, people have expressed concern over the long-term direction of the language, and more importantly, over any potential increase in licensing fees and costs to develop and run software written in Java. This further leads to asking whether open, vendor-neutral languages should be used, in order to avoid tying your infrastructure and development to the business requirements of a single vendor, such as Oracle. Languages such as Python, C/C++, JavaScript, Ruby, or Perl are excellent candidates for avoiding such ties. These languages are maintained, developed, and enhanced by open source communities and open standards organisations (e.g. ISO and Ecma). In general, a business never wants to be bound to the needs and direction of another business. Alternate supply chains, multiple vendors, and open standards are some ways that businesses keep themselves independent from falling under the jackboots of an oppressive vendor that has locked those businesses into their products. So what about Java? Is it an open language, and will you possibly be subject to Oracle's business needs? The Java Community Process (JCP) exists as an open community to continue the development and direction of Java. However, a large rift has opened in this community around Oracle’s licensing practices on the Compatibility Kits that are necessary to demonstrate conformance with the Java specifications. The current licensing model prevents an independent, open source implementation, such as Apache Harmony , from being developed, tested as conformant, and offered to the public under an open source license. Given these licensing terms, the language is arguably not open, and can only be provided by Oracle or its licensees who choose to pay Oracle for the right to develop and offer alternative solutions. If Oracle does not adjust the licensing of some key Compatibility Kits, then the open principles of the JCP will be demonstrably unfulfilled. The conclusion will be that Java is not open and defined by a community, but according to Oracle’s wishes, needs, and concerns. The outcome and resolution of this fracturing and opposing point of view is still unknown. The Apache Software Foundation is pushing this issue into a public discussion, and the next few weeks will shine light on the issue. But for the sake of argument, let us say that people declare Java closed and proprietary to Oracle. Is this a problem for Java developers and users? No. History easily explains why investing in a proprietary language is not a problem for developers, enterprises, and other users. Looking back to the 1990’s, one of the most popular languages for custom enterprise development was Visual Basic (VB). The entire VB ecosystem was managed, controlled, and defined by Microsoft. Despite this complete control, businesses spent billions and billions of dollars investing in VB software (tens of billions?!). For these businesses to spend that kind of money, they must have seen tremendous value from the software that was developed. Developers had to pay Microsoft for development tools, and the end-users of that software had to pay for Microsoft Windows licenses. In many cases, the VB applications connected to other Microsoft products carrying further licensing costs. All of this was wrapped up into a cost/benefit analysis, found to be a good and proper choice, and the VB software was written and deployed. Since that time, the Visual Basic ecosystem evolved into a completely new, and somewhat incompatible, direction: Visual Basic .NET. This was and is part of Microsoft's plan to move its development ecosystem towards .NET. While possibly altering some of the deployment costs, the software developed in VB back in the 1990’s will continue to operate in a backwards-compatible mode, with only minimal maintenance costs. Moving that software into the .NET world would certainly be a new and potentially expensive endeavor, but Microsoft has expended tremendous resources towards backwards compatibility to ensure that the Windows ecosystem can avoid requiring those transition costs. For Microsoft, Visual Basic and its development ecosystem are a key part of its program to have software available for its platform, which then drives sales of Windows licenses. In light of this, it created the MSDN program which sets the golden bar for developer support/outreach that others can others can only hope to emulate. Through this program, and its relationship to the tens of thousands of Windows developers, there is an implied agreement that software developed today will continue to run tomorrow. There is a very real business need for Microsoft to avoid alienating their developers. Oracle is in a different position from Microsoft. While they may own Solaris, it appears to be a component of a whole-stack approach to selling database systems. Oracle does not seem to be positioning Solaris as an independent platform, nor do they appear to be setting up a developer program to build applications for that platform. Their moves and evolution around Java will be for the language, rather than as support for other initiatives at Oracle. While Oracle is not exactly forthcoming with their business plans around Java, it is likely they are continuing along Sun’s chosen path: license the Java Virtual Machine (JVM) for various environments, along with the Java Runtime Environment (JRE). If Oracle does manage to preclude open source implementations, then all existing JVMs and JREs will come from Oracle or its licensees. These all represent revenue streams for Oracle, and conversely, it represents fees that users will need to pay to run Java software. Microsoft created a huge successful business around a runtime environment for applications — the Microsoft Windows operating system. Businesses have been paying that fee for decades. While Oracle will be collecting fees for its Java runtime environment (typically built into your hardware or operating system cost), I do not foresee Oracle imposing punitive licensing fees for the Java environment. Oracle is anything but stupid, and they will work hard to ensure that Java remains a useful development strategy. Building and deploying Java software is and will continue to be a very viable approach to enterprises. To further drive this point home, imagine if an enterprise chooses to "save costs" by avoiding the Java runtime costs. That implies a move to a different language (assuming that the majority of enterprises are using Java today). The cost of a move, in terms of training, hiring experts, rewriting entire application and tool suites, rounds of testing, and final deployment, will easily run higher than continuing to build and deploy Java applications. The right choice is to not worry about the state of Java's open or proprietary nature, despite some of the discussion occurring in the news today. It is not relevant to your business needs or the long term health of your enterprise software ecosystem. Blog post by Greg Stein Greg is a Board Member/Director, Vice Chairman, Vice President Apache Subversion, and former Chairman of The Apache Software Foundation. Widely recognised for his work on versioning systems including Subversion and WebDAV, Greg most recently was an engineering manager at Google, where he launched Google Project Hosting. He's currently focused on licensing, developer tools, and community development.