Why make a free runtime for Java?

I was at my monthly Java (TM) user group meeting tonight, and during the pre-meeting discussion our president Burr Sutter asked a question he usually asks: "So, anybody working on anything exciting?" This typically is taken as "does anyone have a really cool Java (TM) project that they are working on right now that would be neat for us to hear about?"

I usually sit there, not saying anything. But tonight, nobody had anything much, and I finally spoke up about free runtimes for Java (TM). I told them that great progress is being made in the free runtimes for Java (TM) arena, particularly in GNU Classpath and Kaffe. After my update, Burr asked a very good question: "Why would you work on a free, open runtime for Java (TM) programming language?" My answer follows.

You would work on it in order to have a free alternative to a platform governed by the SCSL.

You work on a free runtime for Java (TM) because a free alternative would be better than what we have now; a closely-guarded and largely ingrown platform. You work on improving a free alternative because you are free to participate without that project demanding (via a legally-binding license) that you can only work with them from here on out, and that nothing you learn while devoting your time and energy to them (without compensation) can be used elsewhere. If you do share it elsewhere, and that project finds out, their legal team will make an example out of your ass.

You prefer a free alternative runtime for the same reason that you prefer the free alternatives to the non-free frameworks and platforms available for use on Java(TM). Why is Hibernate so popular? Why is Spring so popular? Why is EJB not? Because innovation by committee, while better than a ruthless, unaccountable corporate entity concerned solely with its own betterment, is still not as good as free, open cooperation and collaboration.

Is this idea so new? Don't we try to teach kids that sharing and honesty is the Right Thing (TM) to do? I will probably flesh this out as an article at some point, but I wanted to get something written down tonight, while it's still fresh in my mind.

Book Review of Learning GNU Emacs, 3rd Edition

I finally got my review of Learning GNU Emacs, 3rd Edition from O'Reilly out the door last night. For those like myself who are coming into the Linux and Free/Open Source Software game later in life, books like this really help to backfill your knowledge/skill sets in a timely manner. I would recommend it to anyone who wants to move beyond the basic Gnome and KDE text editors into a more serious text editing tool that has both a GUI and console modes. That is, if you are considering Emacs.

And no, this is not an invitation to an Emacs vs. vi flamefest. I use both. 8^)

The longer I manage a technical team, the more I am in awe of the Debian Release Team

Just finished a checkpoint of my current development project at work. There are only six developers, and we only have about 18 dependencies on 3rd-party libraries. Even on something that simple, getting the bugs and unresolved issues (after developers had performed their final check-ins of code) cleared up in order to get a 100% pass on the suite of unit tests ended up taking 14 hours over two days. Coordinating changes to the persistence, business, and presentation layers and being able to see the big picture in order to isolate bugs requires intense concentration on my part.

On my way out of the office at 20:35, I was thinking about the some 10,000 source packages in Debian and the coordination and effort required to get a release out the door. I am awed. Debian Release Team, you rock. Thanks for Sarge, and I look forward to the Etch release.

java-package 0.26 uploaded

The latest version of java-package has been uploaded this evening. In addition to support for the latest security-updated Sun and Blackdown 1.4.2 JREs and JDKs, we have added a couple of features from the wishlist department:

  • The username and email inputs for make-jpkg are no longer required; they default to Debian Java Maintainers and the project's email address.
  • Support for packaging Sun's API Javadoc for 1.3, 1.4, and 1.5 JDKs (woohoo!), integrated with the Debian Documentation Menu for easy access.

Hope you like it. Just think, one day when the free runtimes for Java(TM) take over this will be packaging with a level of kitsch akin to vintage clothing. 8^)

Extended benefit from the Debconf5 videos

It would an understatement to say that I have enjoyed the Debconf5 videos; as a New Maintainer who had no chance of being able to attend, the videos have both informed me and helped me feel more connected to the Debian community. Who knew all these hackergotchis on Planet Debian had bodies attached to them?

I received an email from the New Maintainer Front Desk today stating that they could see no evidence of me having contributed to Debian recently, and therefore I would not be assigned an Application Manager. For the first 90 seconds after I read it, I could feel the heat in my face and how rapidly my heart had begun beating. But right away I remembered the video of Hannah Wallach, Dafydd Harries, and Moray Allan's presentation on the New Maintainer Process. I remembered them saying how understaffed the process was and what a large workload existed. They also explained how sometimes you might need to provide more information during the process via email conversations. Since most of my work is in the Debian Java Packaging project, I am less visible as an individual. Almost immediately this otherwise upsetting message made sense. I provided a writeup of my activity with links and mailed it back, ego a bit bruised but not too shaken 8^).

So thanks once more to the video team and to all the presenters from Debconf; your labor has paid off long after the conference and I can personally say it has made a positive and encouraging impact in my life.

Surprise encounter with Mako and company

So it' s been a 60-hour week on-site in Manhattan with the client, and I never got around to calling Mako to try and hook up. I had popped in at Vol de Nuit with a coworker and her friend to relax over a Belgian beer, when I noticed someone who looked familiar out of the corner of my eye as they walked past. It turned out to be Mako, hanging out with Miko, Micah, Biella, and Greg Pomerantz (apologies all around as this is a mixture of folks that I know either by name or IRC nick, and not always both). Clint was apparently there earlier, so my trend of being at the same place as Clint but missing him by less than an hour seems to continue. It was good to get to talk with some more Debian people in person; it's always funny to learn who belongs to a particular nick. I had "hacim" pegged for a Persian guy. I complimented Miko on her haircut, only to learn that Mako was the stylist. That' s right, in addition to developer, open source advocate, Debian and Ubuntu community builder, and renowned desktop wallpaper model, amateur stylist can now be added to his list of credits.

I am currently languishing in New York's LaGuardia airport as the horrible subway delays this morning caused me to miss my original flight. Despite the insane work week and some hideous wireless connectivity and package upgrade issues, I managed to get pretty far on the next release of java-package; hoping to have it ready for upoad next week.

Male Geek Guide to Long Hair

There is no doubt in my mind that the Open Source crowd, and particularly the Linux subset, has one of the highest percentages of males with ponytails. Having had my hair long enough for a ponytail for a few months now, and having observed many a long-haired fellow Free/Open Source Software enthusiast, I have collected this handy set of guidelines for having long hair as a guy, tailored for the male geek audience:

  1. When it comes to shampoo, you get what you pay for.
  2. Conditioner is your friend; cultivate that relationship.
  3. Haircuts are still important; see guideline #1 for further direction.
  4. Sheer length is not the ultimate goal, no matter what your buddies say.
  5. Long hair does not imply maintenance-free hair, and often the opposite is true.


Perspective on software commoditization

Ian Murdock posted an essay on his blog yesterday titled Open source and the commoditization of software. It was a timely post for me, as I had been asked by someone at work for resources that provided insight on the use and viability of open source as part of an enterprise information technology strategy. For those who know that Ian is the founder of my Linux distribution of choice, Debian, you may be thinking that this is the manifesto of yet another wild-eyed wilderness prophet about Linux overtaking Windows. It is nothing of the sort - in fact, it is one of the most level-headed, well-informed, business-minded takes on hardware and software history and their impact on the current thrust of software commoditization that I have seen.

The essay starts all the way back (relatively speaking; after all, the computer era is rather brief from an historical perspective) at the fullness of mainframe prosperity and moves forward. The juxtaposition of the hardware and software markets is something I had not seen presented in such a clear fashion. The missteps of the UNIX market's fragmentation and the fortunate standardization of PC hardware (albeit not intentional on IBM's part) are laid out in an engaging short narrative, followed by Microsoft's staggeringly triumphant conquest of the then-vacant PC software market. The success of companies who chose to participate in commoditization rather than attempt to stem its tide is refreshing. Participation rather than domination is shown to be the way forward, and Murdock goes on to show that even in the Linux ecosystem, there are those who flirt dangerously with the temptation to control a market through manipulation.

If you're a fellow Debian or Free/Open Source Software advocate like myself, I encourage you to take a few mintues out to read the essay. You may find it gives a less-rabid voice to your zeal and provides an entry point into our cause for those less persuaded by the principles of the movement(s).

Fear, Uncertainty, and Doubt as Profit Retention Mechanisms

I think my vitriol filter is securely in place, but just in case, have your safety goggles on. Federal Computer Week is a periodical focused on government agency information technology in the United States. The magazine had a considerable portion of the April 2005 issue covering increasing adoption of Open Source applications in government, Linux migration, and the Firefox browser; I read several of the articles and found them surprisingly close to being balanced.

Apparently that open-mindedness needed to be countered with a dose of good old Fear, Uncertainty, and Doubt (FUD).

Where the buck stops: Accountability and risk in considering open source is an article that attempts to scare IT decision-makers in the U.S. government IT arena with the by-now-altogether-tired question of "who is going to support open source?" From the article:

In the case of open-source vendors, there is limited or no indemnification protection. CIOs must determine whether the low-cost solution they are considering might later become costly. If anything, indemnification and ongoing technical support for open-source solutions should be an important part of any discussion about risk assessment or licensing.

Brilliant! What keen-minded editor of this periodical has penned this fine work? Surely one of the balanced, fair-minded technology pundits has been hired to provide an insightful, unbiased take on assessing the risks assumed in using Open Source software?

Hm. Stuart McKee. Doesn't ring a bell? Yeah, me neither. Stuart is Microsoft's "National Technology Officer", and formerly served as the CIO for the state of Washington. So, the person writing an article on assessing the use of Open Source software immediately following an issue of this magazine largely focused on Open Source usage is the individual who heads "National Technology" for Microsoft, headquartered in the state where he formerly held the position of CIO? This scant, one-page article gets mentioned on the cover?

Who will support Open Source? The people who write it and use it, that's who. The free support offered on forums, mailing lists, and IRC outshines every experience I have had with scripted, ass-covering, mind-numbing support experiences I have had with any and all levels of support contracts. I cannot even number the times I have been in meetings where I have heard "[insert corporation here] has confirmed that this is an issue", sometimes followed by the equally-anemic "but it should be addressed in the next version". I have written about this before.

The article also attempts to distinguish Open Source from open standards:

Open standards should not be confused with open-source standards. And the movement toward open standards has led government interoperability efforts. For CIOs, the result has helped save increasingly scarce resources taking advantage of industry's investment in creating uniform technical specifications.

OK, right. Open Source standards are not the same thing as open standards. But, since Microsoft has had little to do with either of these things, this is kind on non-sequitur, is it not? If anything, Microsoft has an embarrassing track record of attempting to muck up open standards and ensure lock-in. Perhaps the open standards reference implies contributions by IBM in recent years.

The last paragraph is the clencher:

The market ultimately will determine a particular model's success or failure. If that model, however, fails to offer customers an integrated approach to innovation while ensuring that liability resides with the software maker, additional strains will be placed on government resources in the long run, increasing life cycle cost and impeding the interoperability agencies are demanding.

I agree, I think the market will decide; in fact, I think it is deciding. And one verdict is that closed software and standards have had more than enough time to squelch alternatives. But, apparently, there are a number of individuals and organizations who see open source as a quite desirable alternative.

Shame on you, Federal Computer Week, and shame on you, Stuart.