Fork in the Open Source Java world

For quite some time there have been a number of open source Java virtual machines implementations, it could be easily understood that each project was trying out different ways of implementing the virtual machine or had different goals, milestones or requirements.

All of these JVM efforts at least shared the class libraries (which is a large component of a Java VM) in the form of the GNU Classpath, and this certainly helped these communities collaborate.

The Apache Foundation is now starting up a new effort (Harmony) to put together a virtual machine and its class libraries under the Apache License. The FAQ posted is a bit short on the motivations for this effort. I can only speculate that this was done to avoid the side effects of class libraries licensed under the GPL-with-exceptions or the LGPL which make people nervous.

Depending on how this process is managed, this could either become a big delay in bringing a full free software/open source Java implementation (as people take sides on the licensing debate) or if managed properly could make open source java more viable.

The challenge that the Harmony project faces now is significant. They need to convince enough of the existing open source Java developers that they should abandon the current GNU classpath effort and either relicense their code to be Apache-license compatible, or that they should rewrite their code to assist this new effort on the grounds that the Apache License is better. This last point does not seem to be very well articulated in the FAQ which merely dances around the issue. The FAQ at this point seems to mostly focus on spinning things positively while not explaining the rationale for this split, as can be seen by the first follow ups.

If they are not able to bring these existing contributors over they are going to have to grow this codebase from scratch and depend on member companies to contribute code to the effort. IBM might be interested in donating parts of their code (assuming they are allowed to) and might even be behind this split.

We have been working on the open source Mono for almost four years now and it has helped me put things a bit into perspective. I can not blame the Apache folks for going down this path. This should have been sorted out a long time ago in GNU Classpath land, but am fairly skeptic about the viability of Harmony's class libraries.

It is hard to tell what will happen, but without the endorsement of the majority of the GNU Classpath developers this is a major setback for open source/free software Java. It might be a necessary step, but am skeptical of its success possibilities.

In the meantime, gentlemen, you can start using Mono with its lax license today! Get it while its fresh!

Mhm, sorry about that. I just felt like plugging Mono again. Lets move on.

Class Library Licensing

Licensing wise, we went through a similar issue in the early days of Mono. Our class libraries used to be under the LGPL license. We switched the class libraries license from it to the MIT X11 license in response to comments from our potential users and contributors. Of course the MIT X11 license has pros and cons. On the pro side, it imposes very few restrictions on the users and its very easy to mix and match, and in general people feel comfortable with adopting it. On the downside, it is possible for companies to "appropriate" the code and never contribute anything back.

Certainly people have copied the Mono class libraries into their proprietary products and not given changes back (mostly people find Mono components easy to reuse on the Compact Framework that lacks plenty of functionality), but even the GPL and LGPL would not have changed things dramatically in this case (only the receiving end would have the right to the source, and for Compact Framework users, even more irrelevant than desktop users).

When it comes to large users of the Mono class libraries, Mainsoft is probably the largest consumer of it. Mainsoft has a product that turns CIL bytecodes into JVM bytecodes and allows users to port their C#/.NET code to a Java VM. Mainsoft could have chosen to make a proprietary copy of the class libraries, improve their copy and ship that to costumers. But instead Mainsoft has chosen to become an active contributor to the project, and is relicensing its own code under the same terms, the MIT X11.

There are a number of reasons: it is simpler to get new improvements from the community into your own code base, you can drive the direction of the project, and they have created a great aura around their company in the community: they are not only socially responsible contributors, but the world can see that their contributions are top-notch. In addition, their customers get access to the code and can benefit from the shared knowledge pool of the resulting code.

I mention this because a common reason to use the GPL and the LGPL, as opposed to a more lax license like the MIT X11, was that third-parties would tend to keep their improvements to themselves and that only a license with stronger terms could get them to contribute back. A few examples are usually mentioned: the X11's own failure in the 80's to get vendors to share their improvements and the success of GCC in forcing the C++ front-end to be released.

Maybe those examples did apply in a poorly connected world and much smaller ecosystem of the 80's, but none of the two previous scenarios necessarily apply today for horizontal software. The Mono class libraries have demonstrated that companies are willing to contribute to the class libraries and that collaboration will help them reduce the cost of development.

I am now less convinced that forcing people is the best way of achieving collaboration. The GPL has certainly played a role in educating people about free software, but for the most part people who contribute to nascent open source/free software projects have done so do for a plurality of reasons that have nothing to do with being forced by the license, including shared R&D costs, joy, need, curiosity, challenge, sense of community, social responsibility, or fame.

Brilliant Ideas

This must be obvious to every Firefox user now, but am still amazed at the simplicity and the beauty of Firefox's search design.

Ever since I can remember GUI applications, searching has been implemented as a popup box that pops in the middle of your document covering the text you want to search. Descriptions on how to float these dialog boxes and the discussion about how to create these non-modal dialog boxes is present in most GUI programming books that taught these principles to developers.

The beauty of placing the search at the bottom as opposed to using a sidebar is that the document is almost never reformatted.

I find myself missing this interface on my applications. Evolution for example still has the old-school search dialogs:

The new Adobe Acrobat pops up a small enough window with only the basics: the text to search for, backwards and forwards button, and configuration options are done from a button on the left:

An improvement, but not as good as Firefox.

That being said, the places where I miss search the most in my applications are:

• GAIM: At some points during the day there are too many people logged on, and I would like to search for specific users online by typing on an incremental search box.
  Update: I know that I can select the list and start typing on the treeview, but the search is only done on the visible strings, not on other elements. So for example, someone's nick name might be "Arturo", and extra information from the messenger service might be that his full name is "Arturo Espinosa", and I have aliased him to "Pupilo". I can only search on the "Pupilo" string, not on the "Arturo" or "Espinosa" strings. Hence the need for a search feature on GAIM.
• Evolution: the filters dialog box and the folders list. Like in the case before, I do not want to only search on the text string shown to me, but in any other strings that might be part of the filter criteria:
  

  It should be noted that this dialog probably needs some love anyways.