Richard Monson-Haefel's Blog

Open Source Archives

9 of Clubs Seeks a new Deck of Cards

Recently I had the honor of being named one of the 53 most influential people in the Java industry by The Middleware Company. My card was the 9 of Clubs – I have no idea how to interpret that distinction. Obviously, it’s a nice complement especially considering that the votes came from developers who subscribe to TheServerSide.com mailing list – a resource I consult regularly even if the threads are frequently hijacked.

You would think that a guy in this deck of cards is probably making gross amounts of money and living a leisurely life. I can't speak for the other people on the list, but that doesn't describe my life at all. I work really freaking hard – as hard as anyone reading this blog – and I don't own a yacht or drive a Lamborghini. I'm not poor by any stretch of the imagination, but I'm not going to make the Forbs list anytime soon.

The truth is being an independent is hard work. I've been at it now for about five years and its never been a cake walk – ok occasionally it's been easy, but most of the time its not. For the most part I'm busting my butt trying to convince companies that I'm worth what I'm worth even if John and Jane Doe charge a faction of the price. The truth is, I'm usually over qualified for most consulting gigs so the spectrum of opportunities available to me is actually less than the average developer.

I heard once that winning an Oscar in Hollywood is a double edge sword. Actors who win are recognized for the quality of their work, but subsequently find it hard to find work. I even heard it descried as the Oscar "Death Knell": Its great to win, but its better to get nominated. This is probably a bit of hyperbola and I don't mean to compare my meager success to winning an Oscar, but the truth is: Success is measured in many ways and peer recognition – while wonderful – doesn't always translate into big bucks and loads of free time.

After more than five years of going-it-alone, I finally asked for help. This Monday I decided to try my luck for the first time with the grape vine. Although I have frequently helped others find work, I've rarely asked for help myself. Why? Well I guess I felt that I should be able to find my own work. Also it’s a matter of pride. I don’t like to ask for help. I don't want my peers to know that its hard for me to find work that fits my skills and pays well – everyone seems to assume that if your well known you automatically make tones of money. Its not always true.

I've been very involved in the Java industry. Two months after I started learning Java I started the Wisconsin Java User's group – that was back in the spring of 1996. Since than I've volunteered for all sorts of things from open source projects to JSRs and I'm proud of what I've accomplished. The culmination of all this altruism was being voted into the JCP Executive Committee last fall – an honor I've take very seriously.

I've done good things for our industry, but I feel its time to step back and let others have the glory. I have a family now. My boy, Henry is about 2 1/2, and my daughter, Olivia, is just 9 months. I need to look inward toward my family and put them first. That means I need to find a stable job with some longevity and hopefully something with a lot less travel. I think I was honored with the 9 of clubs because I've donated so much of my time to the Java community – people will probably laugh at that, but I can't think of any other reason. Working on expert groups, open source, and the JCP consume enormous amounts of time, but pays nothing, zip, zilch. That's ok, I knew that going into these endeavors and its expected that I should be able to leverage my contacts and name recognition into a living. I have done that to some extent, but it hasn't been easy. You still have to find work that fits your credentials and sell yourself at rates that are affordable – these are usually contradictory objectives after a certain point.

OK, so why this blog? Well, I'm hoping that someone will read it and say "Hey, I got just the job for this guy! What's his e-mail address?" (btw it is Richard@Monson-Haefel.com). Head hunters and other professional placement guys should not bother to contact me - you guys are evil.

There is another reason: On occasion I've had people ask me how they can manage their career to become more successful – to be more like me. This always makes me wince. I've been fortunate – no doubt about it – but I wouldn't recommend my life style to anyone. It’s a lot of work with very little pay. As I said, peer recognition is great – its probably the best recognition you can have – but making a living is not a bad thing either. I'm honored to be counted in that deck of cards with the likes of James Gosling, Rod Johnson, Gavin King and others – but its time to join a new deck – one that gives me more time with my family and actually pays a salary.

JSR-241: Groovy – A New Standard Programming Language for the Java Platform

Until now the Java programming language has reigned supreme as the standard programming language for the Java Platform. It has served us well for close to nine years, but it cannot be all things to all people. And it shouldn't. The Java Programming language, like C++ and C#, is a strongly and statically typed programming language. While this type of language, sometimes called a "conventional" language, is useful for solving many problems, it is not a panacea. Conventional programming languages are very exacting, meaning that you have to dot every 'i' and cross every 't' in order for the program to compile. This orthography of statically defining all the types may result in more predictable code, but it also tends to slow developers down.

An alternative to conventional programming languages are agile programming languages like Python, Ruby and Perl among others. These agile languages have long been called "scripting" languages, but that term is not, IMO, sufficient. Many in IT perceive scripting languages as layman languages that sacrifice technical sophistication for easy of use. This may be true of some scripting languages, but it's certainly not the case with Python, Ruby or Perl. These are dynamic and powerful programming languages that happen to use less syntax to accomplish more.

To be perfectly honest, although I'm listed on the JSR as a co-spec lead, I'm a Johnny-come-lately to the Groovy bandwagon. Groovy already has a grass roots following and all the credit for the development of Groovy goes James Strachan and other contributors to the Groovy open source project. I'm not a language designer, but I understand the power that languages like Python and Ruby offer developers and I believe it is time for the Java Platform to include an agile programming language. It's this personal conviction that led me to initiate and co-develop JSR-241 with James Strachan and Gier Magnusson of Apache. My role as a specification lead is to manage the progression of this JSR through the JCP and author the Groovy Language Specification – two tasks that can be terribly distracting to those doing the really hard work of developing the JSR itself.

Groovy represents the beginning of a new era in the Java platform, one in which the Java community embraces language diversification and harnesses the full potential of the Java platform. It’s the recognition that the Java is more than a programming language; it’s a robust platform upon which multiple languages can operate and co-exist. To me this has always been the unrealized promise of the Java Platform.

The Java programming language is, simply put, a convenient abstraction for the real language of the Java platform: byte code. As a user-friendly abstraction for byte code the Java programming language is powerful, but it's not omnipotent. There are circumstances in which a different language, an agile programming language, is more expressive and productive.

So why Groovy? Why not Jython or JRuby? Why not one of the dozens of other programming languages that are designed to run on the Java Virtual Machine? It's my opinion, and I believe the opinion of those who support this JSR, that Groovy is the best choice because it was built from the ground up for the Java Platform and uses syntax that is familiar to Java developers, while leveraging some of best features that Python, Ruby and Smalltalk have to offer. Jython and JRuby are excellent examples of how existing languages can be ported to the Java platform, but they are, after all, ports. They use syntax that is not designed with Java developers in mind and they are founded on a completely different set of code libraries. Groovy is designed for Java developers and its foundation is the standard APIs of the Java Platform.

Open Source Developer: Will Work for Food!

UPDATED: January 23rd, 2004

I've received a lot of mail and seen a lot of postings about this blog entry. Some of it has been supportive and some of it has been …. Well, not. The one thing that is common to all but a few of the responses is that people have misunderstood my point. This is good evidence that I did a poor job of articulating it – something writers struggle to avoid. Anyway, I offer the following as a clarification.

Here is the point of the blog:

The majority of open source developers are not paid for their contributions. I'm not talking about high profile core contributors; I'm talking about all the other people who make open source a success. What pains me is that some of the few who make a living doing "professional open source" try to paint the picture that everyone is making money. That's not true, and its not why open source works.

Open source works because it gives developers freedom of choice and expression. Developers get to choose which projects they work on and therefore the direction of their own technical growth. Developers get to choose what to contribute and how much. It's about freedom of choice.

People give all kinds of reasons for doing open source that are simply variations of the freedom of choice theme. For example, developers feel a need to "give back" to their community. Well open source makes that possible because it gives you the freedom to contribute code, bug fixes and documentation. Another reason given, is that people get involved in open source to "build their resume", which is just another freedom of choice. Open source lets you build practical experience in just about any area of software you are interested in – ask your employer if you can start doing game development on their time and see what they say.

I have worked as a professional open source developer, and sometimes I've been paid for my work. Today, I'm not paid to work on open source but I continue to contribute as best I can because it gives me the freedom to work on those things I find interesting.

Open source does offer the potential to make money - No doubt about it - but that's not why open source is successful. It's simply a benefit of the freedoms open source offers us as individuals. It's not about ego; it's about choice. It's about fulfillment and creative expression. Money is great. I'm all for it, but its not why I work on open source. I could make a lot more money working for a vendor, but then I wouldn't be able to choose what and when and how I do my work.

The simile that I gave of a "fine artist" was meant to illustrate the motivation of the average open source developer. I have a few friends that are artists. Some are commercial artists and others are non-commercial artists, sometimes called "Fine artists". My commercial artist friend has never had a lot of choice in the medium he works in or the subject of his work or even the creative direction. He does what the customer wants, which is how most successful business work. My non-commercial artist friends, the "fine artists", work in any medium they please, on any subject, in any way they want. The motivations of the fine artist are intrinsically the same as those of the open source developer – freedom of choice and expression.

Paradoxically, freedom always comes at a cost. You must give something up, usually something tangible like money, lives, comfort, and such things to have freedom. Most open source developers do not make money doing open source work (contributing patches, bug reports, helping others on the mailing list, etc.), but they do benefit. They have freedom.

*************************************************************************************************
Oringinal Blog Entry: Janaury 22nd, 2004

I have a friend who works in commercial software and makes a pretty good living – actually a real good living. He finds the "whole open source thing" quite incomprehensible. Why on earth would you waste hours of your own time creating software without pay? My wife wonders the same thing.

The truth is: The difference between open source developers and commercial developers is the pretty much the same as the difference between a starving fine artist and a fat and happy commercial artist. The commercial artist, if she is any good, is probably paid a decent amount for creating logos, advertising, album covers and such things for someone else. A person who creates fine art, on the other hand, isn't likely to make more than a pittance even if they are lucky enough to get a show. While it's true that that some fine artists make it big, this is relatively rare when you look at the whole population. So why do people choose to create fine art, rather than commercial art? Freedom. Fine artists get to work when they want, create what they want, take credit for their work, and in the end enjoy the public scrutiny of their peers.

The same is true of open source developers. While a few make really good money selling consulting and training and other services, the vast majority of open source developers don't make anything. But they do have freedom. Open source developers can choose which projects they will work on and how and when they'll do the work. In the open source world no one will tell you what projects you must work on, or when you should work, or how much you should do. That's up to you. For the most part you are free to be as creative with your code as you like – if your code is good it will be adopted. If its sucks it won't.

So the price of freedom of expression for most, if not all, open source developers is … well poverty. Ok, that's a bit of an exaggeration since a lot of open source developers have a day job, but that's just as telling. To do open source, you have to have a day job. You can't expect open source to feed your family or even your cat for that matter. As I said there are exceptions, but most open source developers do it for the love of writing software. While commercial software developers do a great job of feeding their families, open source developers do a better job of feeding their minds. In the end, you have to ask yourself which is more important: The things you own or freedoms you have.

Groovy, Baby!

Groovy combines features of Python and Ruby (two popular scripting languages) into a Java friendly syntax. It makes working with object graphs (e.g. a bunch of business objects that have complex relationships) really easy – it's great for working with collections, XML and HTML. There is also support for regexp, SQL and scripting of Ant tasks.

Groovy saw its first release last December 2003, but its still very much a language with room to grow. If you are interested in getting in on the ground floor of what I believe will be an important new scripting language, than please visit the Groovy web site and see what you can do – testing code is always a big help. Personally, I hope to help with the documentation of this language.

The bottom line is that Groovy is not a replacement for Java – it’s a tool you can use to be more productive with Java. Groovy's not a silver bullet either. I can imagine lots of scenarios where I would prefer to work with the Java programming language, but its very useful in certain circumstances especially when organizing and filtering object graphs or text data – for example text files or XML or what have you.

What's Richard Monson-Haefel up to in 2004?

So what's next? I've wanted to write a book on J2SE for a couple of years, but since this space is already crowded I've put it off. Recently, however, I've decided to test out some material for such a book - I may post it on the Internet. The purpose of the book, tentatively titled This is Java, is to explain how Java works under the hood. If all goes well, the material will be easy to read and accessible to intermediate developers and Über-wonks alike.

In addition to working on This is Java I'm going to be very involved in the JCP Executive Committee this coming year. There are a lot of specs going through the process now and probably a lot more to come, so this will take up a fare amount of my time. I'm also working on JSR-220 (EJB 3.0) and the Apache Geronimo and the OpenEJB projects. Of course all these efforts are more or less philanthropic since they don't pay cash. To earn a living I'll be spending about 20 hours a week consulting and/or doing some training – nothing solid to report on that end yet.

The Rebel Alliance: Apache / ObjectWeb Join Forces

ObjectWeb, if you haven't heard of it, is an organization similar in purpose to the Apache Software Foundation (ASF). They have a fairly large offering of their own, but until recently they have predominantly used a LGPL license, which is simply incompatible with the Apache's BSD-style license. When Geronimo was announced back in August, some of the engineers from ObjectWeb approached us (I'm a Geronimo team member) about collaborating on some projects. Their JOnAS and JOTM development teams are also working toward J2EE Certification so they are creating a lot of the same components (EJB container, Transaction Monitor, Messaging, etc.) that the Geronimo folks are working on. The ObjectWeb engineers suggested that we collaborate on facilities common to both projects. The Geronimo team was very interested and agreed to meet with ObjectWeb at ApacheCon. That meeting took place last night.

The synergy, other than licensing, between ObjectWeb JOnAS/JOTM and Apache Geronimo appears to be excellent. Our development cultures are admittedly different but the differences actually strengthen our alliance rather than weaken it. The JOnAS/JOTM folks are, on average, older and more experienced in big-iron (mainframe kind-of stuff). Their depth of knowledge is really incredible – David Egolf of ObjectWeb kept Geronimo developers mesmerized for hours after the BOF talking about mainframe transaction processing. It was, for me at least, like finding my own Obi-Wan Kenobi. Given the chance I would have spoken to him all night.

While the depth of knowledge exhibited by the JOnAS/JOTM teams is extraordinary, the ObjectWeb folks tend to be slower out the gate than Geronimo. This is because they are more methodical. They are, in essence, the old men of the sea. The Geronimo team, on the other hand, is younger. These young-upstarts tend to develop solutions quickly and redesign often. But the output form the Geronimo folks is staggering. For example, the Gerionimo team is close to having an alpha release of the J2EE Geronimo platform four months after starting development. The technical expertise of the Geronimo folks is nothing to sneeze at either – almost everyone I've been working with has developed at least one successful open source container system before Geronimo.

So how will these teams work together? We will leverage each other's unique cultures and experience to co-develop common components for our J2EE container systems. The best, and first, example of this is JOTM. JOTM is ObjectWeb's transaction processing monitor. Transaction processing monitors are notoriously tricky critters to get right, and being able to plug in an existing and – according to Dain Sundstrom – excellent implementation like JOTM is a huge win for Geronimo. In addition, the JOTM people will go on to develop journaling and recovery, which is perhaps the most difficult and most critical aspects of a enterprise transaction manager – it's what makes transaction managers truly reliable. No open source project today offers a real journaling and recovery system. JOTM will be the first. Since the JOnAS/JOTM folks have more depth in this area, the Geronimo team is happy to endorse and support their development efforts. From this point forward, Geronimo and JoNAS will co-develop, maintain, and utilize JOTM for their transaction processing monitors. Of course, this would not have been possible if the JOnAS team had not agreed to change the license of JOTM from LGPL to BSD-style at the meeting last night. That was the last barrier to collaboration between the groups, and it turned out not to be a barrier at all.

For their part, ObjectWeb is thrilled to have the support of the Geronimo team and just as importantly, they are excited about the prospect that their software will be reused outside of ObjectWeb. This is open source after all; we believe in sharing software, exchanging ideas, and cross development. Geronimo will be contributing resources and unparalleled expertise in the Java platform – no one leverages byte code complication like the Geronimo team.

It's been an interesting turn of events. Before the BOF with ObjectWeb last night, the Geronimo folks worked together 16 hours a day at ApacheCon and were inseparable. As of today all that has changed. Now it’s the Geronoimo and ObjectWeb folks that are inseparable: The old men of the sea share their decades of hard-won big-iron wisdom; the young Geronimo upstarts share their passion, container development experience, and Java platform expertise. The feeling of camaraderie is sincere and an unadulterated. This is the start of a powerful alliance and the beginning of many new friendships.

The State of Geronimo

What does that mean? Well, it means that Geronimo, when it's ready, can be tested against Sun's Technology Compatibility Kit (TCK). An application server has to pass the tests in TCK in order to be called "J2EE Compliant". The fact that Sun has extended this license to Apache, is a huge vote of confidence in the Geronimo project. It says that Sun believes that Geronimo is a legitimate application server that may, provided it passes the TCK, be called "J2EE Compliant." Although, ObjectWeb (another open source organization) was given the TCK scholarship (something Geronimo still needs), Geronimo is the first open source project to receive the license. The license gives you permission to run tests against the TCK, but it normally costs a butt-load of money to label an application server as compliant – that licensing fee is one of the ways that Sun realizes income on J2EE. The scholarship, on the other hand, is designed to support non-profit organizations. It basically waves the costs that commercial vendors are required to pay in order to use the "J2EE Computable" branding.

But wait! That's not all … it was also announced that Geronimo will be using OpenEJB as it EJB container system. Actually, several of the Geronimo folks have been hard at work on a new OpenEJB branch that can be used by Geronimo and the established OpenEJB community. This is an item close to my heart, as I co-founded the OpenEJB project with David Blevins four years ago. It's been a blast working with the OpenEJB code base again. My hat is off to David and the rest of the OpenEJB community – the fact that the Geronimo folks chose to use OpenEJB, rather than develop their own EJB container system is a huge endorsement of that project.

There is more to this, specifically about Geronimo collaborating with ObjectWeb, but I'll cover that tomorrow …

ApacheCon Hackathon: Rediscovering my religion.

Fortunately, I was saved here at ApacheCon in Las Vegas. I rediscovered my religion, programming. For the past 36 hours I've been working along side some of the smartest people I've met. Hanging out at the ApacheCon Hackathon (an informal communion of Apache committers) with the likes of David Blevins, Dain Sundstrom, Jeremy Boynes, James Strachan, David Jencks, Bruce Snyder, Hiram Chirino (in no particular order) and many others. These guys have been banging away on their keyboards for the past 48 hours working furiously for the shear pleasure of it. Watching them work together from early morning until ... well early morning, was incredible. I've never seen a more motley crew (the dirty half dozen) come together in such perfect harmony. This is what team work is supposed to be. These are the guys every recruiter dreams about. I'm surrounded by the hardest working, most intelligent and personable people I've met in years. Geek took on new meaning for me this past weekend. Its not about all those geek stereo types, its about passion. These developers are passionate about writing really good software and they are probably most capable people you will ever meet.

It was exhilarating to work along side these people. It was also humbling, but in a good way. I learned that you can still be excited about your work. That coding is an end in-and-of itself. That open source software is to commercial development what fine art is to commercial art. It's pure. It's free from business managers and sales people and apathy. If you've lost your love for programming, then get involved in open source.

I've rediscovered why I became a developer in the first place. I had forgotten what its like to work with great software engineers and to be excited about solving technical problems. I had forgotten my religion. Well, I'm back.

Note: I don't know why people would be interested in this sort of thing, but the folks at java.net seem to think someone will. If you feel like you just wasted the last three minutes of your life, then I apologize. If, however, this blog starts even a single person on a pilgrimage similar to mine, it will be well worth it.

This work is licensed under a Creative Commons License.