On Mon, Apr 19, 2004 at 02:18:26AM -0400, Chris wrote: > Briefly stated, in my professional opinion, J2EE is currently the > best tool around for writing business software. In turn, this means > that it is also the best tool around for writing Free Software for > non-profit organizations. 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. 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. > I have chosen J2EE for the future of InfoCentral and thus it too > will sadly be inaccessible to Debian-NP. It is fully understandable > why -- Debian is a freedom-purist distro and I commend it for taking > this stance. > > But a solution is needed. Debian NP will be worthless if the > software that non-profits's need is not available. 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. 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. > The solution is this: We need to support the GNU ClassPath and the > various JVM projects like Kaffe and SableVM to help bring them to > modern Java standards compliance. Once they are, Java/J2EE will be > a completely Debian-friendly platform. 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; 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; 3) Write your software using existing tools and write the functionality you need as part of your application; In all cases, you're going to be doing a lot of hacking that you wouldn't have to if your software had proprietary dependencies. 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. 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. Regards, Mako -- Benjamin Mako Hill mako@debian.org http://mako.yukidoke.org/
Attachment:
signature.asc
Description: Digital signature