Re: Java/J2EE and the future..

On Tuesday 20 April 2004 7:04, Benj. Mako Hill wrote:

> It depends on where you are putting the emphasis in that sentence.
> If you mean it's the best tool for writing *Free* Software, I doubt
> that you are correct. If you mean it's the best tool for writing
> Software for non-profits regardless of the effect on your users'
> freedom, you might be correct as well.

Let me be more to the point:  All other Open Source tools for writing 
large-scale, professional business software are entirely inadequate 
compared to J2EE -- inadequate as in "not even an option."  As far as 
freedom is concerned, this is really the same situation faced by RMS 
and other GNU folks in the days before Linux and gcc.  They had to 
use a proprietary Unix and C compiler as a crutch for a time because 
it was the only workable option.  I feel the same is true of Java 
today.

> My guess is that you are speaking in the terms of some sort of
> compromise. As developers, we each have to choose the role that our
> users freedom plays in the determination of the platform on which
> we chooses to write software. Developers clearly make different
> choices.

The choice to use Java today would only undermine users' freedom if 
there were not Open Source implementations in the works.  As it 
stands, the non-Free Java implementations are still free as in beer, 
so there's no financial disadvantage during the wait.

> Clearly, not all the software that non-profits need will be
> unavailable in Debian-NP -- only the software that depends on
> non-free software. Infocentral will not be the first piece of
> software that is Free Software but not in Debian-NP because of
> non-free dependencies. Ebase is another example.

Certainly.  Most other NP needs are already fully met by Free Software 
without non-free dependancies.  I see large-scale business software 
as kinda the last piece of the Open Source puzzle:  currently 
missing, but finally now in early development.

As for InfoCentral, I plan to create some Debian packages of the PHP 
version once 1.3.0 is ready.  (significantly improved, but not the 
scope that I envision for the J2EE-based overhaul)  So at least 
there'll be something in the meantime..

> Clearly, if we could (ethically and practically) distribute
> non-free software, we'd be able to offer non-profits a better
> distribute more quickly. If we could do that though, there wouldn't
> be much use for a Debian-NP project at all.

As I said, I fully agree with Debian's strict freedom policies.  It's 
more what to do to get from A to B fastest, where A = need for 
high-end business software and B = need for fully Open Source 
solution.

> That is one solution. I see at least three:
>
> 1) Write your software with proprietary dependencies and then try
> to re-implement (or join others working to do so) the proprietary
> Software's functionality in Free Software;

Which is what GNU did..

> 2) Write your software while expanding existing Free tools to
> include the functionality of the non-free software; This would mean
> either using Kaffe & GNU ClassPath instead of Sun J2EE or using
> another language and tools;

Some Java software is already runnable with Kaffe + ClassPath (some of 
the Apache project stuff, for instance).  This software is already in 
Debian, which I think is cool.  There are already complete Open 
Source J2EE implementations, JBoss and JOnAS, but they require Java 
1.4 and Kaffe/ClassPath are at 1.1 + partial 1.2.  I am, of course, 
using the Open Source J2EE software instead of Sun's.

> 3) Write your software using existing tools and write the
>    functionality you need as part of your application;

The amount of time and expertise required to re-invent J2EE is beyond 
the scope of most/all business app projects.  I fully considered this 
route and then realized I wasn't 20 full-time developers. (-:

> Because (1) involves the least work up front, many developers will
> choose this. However, I personally don't have confidence in my own
> ability or stamina to hack on the Java ClassPath to choose (1) with
> a good conscience -- I'm simply not confident in my own ability to
> contribute to that project to the degree that it would ensure its
> success and not willing to live with the consequences of non
> succeeding.

Sadly, I don't yet have the skills needed to help either.  My thought 
is that the Open Source community needs to get together, pool some 
money, find some sponsors, and see to it that Kaffe/ClassPath are 
brought up to Java 1.4 compliance sooner than later.

> Don't underestimate the importance of the second option. As I've
> heard the story, the GIMP project produced the first version of GTK
> in the process of writing their application because non adequate
> Free replacement existed. It took them longer than if they'd used a
> proprietary out-of-the-box toolkit but everyone who uses GNOME has
> them to thank as a result.

The difference in this case, of course, is that the proprietary 
out-of-the-box toolkit is an open specification just waiting to be 
re-implemented.

Of course, I do think it would be cool if there was also an "Open 
Source from day one" effort to build a competitor to J2EE.  There's 
always room for improvement! (-:  Hmm.. maybe that "D" language?

Chris