John Reynolds's Blog

Community: Java Communications Archives

Open software pragmatism - Free (as in beer) isn't the point

Back in the mid-90's I was working on the user interface for a Windows desktop application that included a fairly sophisticated cross between a table and a tree component. We wanted to display a multi-column table of assets where each row was actually a summary of information; for example one column was the total value of the asset. Each row of the table could be "expanded" to list the details of all the transactions that were "rolled up" into the summary. You see similar components all over the place today.

Fortunately, even in the 90's we did not have to write this component from scratch. A commercial table/tree component was available (for a reasonable price), and we were able to purchase a source-code version that allowed us to modify the code to our hearts content. One huge advantage to having the source code of the table/tree component was our abilitiy to debug problems, and if the problem turned out to be in the table/tree component itself, we could actually fix the bug instead of having to work-around it.

The downside to having the source code came whenever an updated version of the table/tree was released. If there was a feature in the new version that we wanted to use, we'd have to reapply all of the enhancements that we'd made to the previouse version, and more annoyingly we would have to figure out if the bugs that we'd found in the older versions had been fixed (if not, we'd have to hope that our old fixes could be applied to the newer code base).

As I mentioned before, this was in the mid-90's. The Free Software Foundation was alive and well, but very focused on Gnu's Not Unix. I was working in the Wonderful World of Windows, where Open Source was yet to gain a foothold, and everything cost money: You paid for development tools, you paid for libraries and components, and you certainly paid for source code. Perhaps because of my youth and enthusiasm, paying for stuff didn't bother me very much. I remember that I would often buy a development tool*** that I wanted to use ... usually from Borland because they had great tools for a reasonable price... and then talk my boss into letting me use these tools at work. If I was lucky, I would get reimbursed, but that didn't very happen often, and I usually didn't mind. (*** Note that free development tools such as the Gnu C++ compiler and Emacs were available on Window at the time, but they just didn't have the polish of the tools that you paid for)

Paying For Stuff wasn't annoying; Persistently Unfixed Bugs were annoying. I remember being really pissed with the vendor of the commercial table/tree component because there was not an effective process for submitting bug fixes to the vendor (It was understandable that a reported bug might not make it into the next release... but not when you had sent them the fix). My colleagues and I became very intimate with the internal details of this component, because we were stressing its functionality a bit farther than it could go... and we often found (and fixed) bugs in the component long before the vendor knew they existed. Applying these patches over and over again to subsequent releases of the code base really "chapped my hide".

Life here in the 21st Century has certainly changed with respect to Paying For Stuff, especially with respect to source code. I've done no real survey, but I would be willing to bet that the source code for most of the frameworks, libraries and components that developers rely on today are readily available. We simply don't tolerate hidden code anymore: If I can't see your code, I'll use somebody else's code that I can see (whether or not I have any intention at all of actually looking at the code).

As the last bastions of "closed code" fall, such as Sun ovecoming its earlier reluctance to "Open Source" Java, I want to shout out a reminder:

Free (as in beer) isn't the point

Go back with me to the mid-90's and revisit the issues that we had with that table/tree code that we'd purchased: We were pissed that bugs that we had fixed ourselves never made it back into the official code base, and that we'd sometimes have to significantly mangle the code to add in our own enhancements. If there had been an effective process for getting bug fixes back into the code base, and if there had been an effective process for refactoring the code base to enable end-user enhancements, we'd have been tickled pink.

The same is true today. Allow us to get our fixes back into the code base, and pay attention to our requests for refactoring and API changes, or it's not going to make much difference that the code is now "Open Source".

Thoughts on "The Modular JRE" and Open Sourcing Java

David Herron posted a clarification of "what it means to be Java" on his blog, and the examples that he used got me thinking...

David made it clear that anyone can add whatever they like to their version of the JRE (Java Runtime Environment) and still call it Java... but if they leave anything out then it is most certainly not Java. The example he sited was the hypothetical incusion of SWT (the windowing toolkit used by Eclipse) in a version of the JRE. This version could still label itself as Java as long as AWT and Swing (the windowing toolkits in the Java specifications) are not excluded.

This makes sense to me... but I'm hoping that the folks who are opening Java also take another look at the basic definition of what must be in the JRE. Let me explain my concern...

Many Java applications (maybe even most) have no desktop-based user interface at all (they are browser-based web applications)... and if the adoption of Web Services and SOA continue we'll see more and more "headless" Java-implemented Services (Services that have no user interface at all). In a world where it is quite legitimate to have a large percentage of Java applications with zero need for any windowing toolkit, why carry around those toolkits in the JRE?

I know that code that isn't used doesn't really "cost" much, but let's assume that you are really into Grid computing, and you have thousands of nodes in your cluster... and each node has a JRE with unused windowing toolkits on it. Seems wasteful.

Windowing toolkits in the base JRE are fairly easy to throw stones at, but there are many other components that really should be optional. For an example, just take a look at the recent "discussions" on whether or not JavaDB should be included in the Java Developer Kit (I shudder to think of the threads that would be spawned if JavaDB is ever packed into the JRE).

My impression is that there is a large consensus that the JRE should be more modular, broken into logical chunks that are installed based on need. A modular JRE does pose some rather interesting technical challenges (to get the code that you need when you need it), but I had overlooked the challenge posed by the current definition of Java itself.

If I'm reading David right... a modular JRE wouldn't quite meet the current definition for "Java"... it's all or none. If I never install the "windowing-toolkit" chunk on my application servers, then they aren't really "Java" application servers.

Just something to think about...

This work is licensed under a Creative Commons License.