In my career as a software developer, I have worked in many diverse environments. Within a single company, software will often be developed in many different ways. When you consider the various challenges, people, and tools that make up a developer’s day-to-day world, you quickly realize just how diverse that world is. I never know what surprising challenges the next consulting project will bring, so I always keep a variety of tools in my toolbox. For a few years, iBATIS was just a little chunk of code that saved me some time when I would normally be handcoding JDBC.

So how did iBATIS go from being a tool in my toolbox to an Apache project used by thousands? I had never intended to make iBATIS a full-blown open source project. The source was out there, but I hadn’t marketed it or actively shared it with anyone. Enter JPetStore.

On July 1, 2002, I posted my response to the Pet Store story that was traveling the Internet. A large software company in Redmond was claiming that the C# language and the .NET platform were vastly more productive than Java, by several orders of magnitude. I’m a technology agnostic, and even though C# and .NET are pretty decent, I just couldn’t accept a claim like that. So I spent my evenings for a couple of weeks writing JPetStore in the shadow of the “monstrosities” that had been fashioned by the enterprise software vendors. JPetStore created much discussion in the Java community. The hottest issue was its lack of an Enterprise JavaBeans (EJB) persistence layer—replaced instead by a tiny little framework called iBATIS.

I’m often asked, “Why didn’t you use other open source tools?” At the time there were no other tools like iBATIS. There were plenty of code generators, but I’ll spare you my soapbox rant on development-time and build-time code generation. I’ll just say that anything that can be generated can also be generalized into a framework. And that’s what iBATIS essentially is: a generalized framework for quicker JDBC coding.

The next question often asked is, “Why not use an object/relational mapping tool?” An O/RM tool can be used in the right environment. It works very well when you have full control over your database and the object model: you can easily achieve ideal mappings and avoid nightmarish tweaking and jumping through hoops due to a mismatch between the two. However, no one would dream of mapping an object model to the kinds of databases that I usually work with. With a decent O/RM tool, like Hibernate or TopLink, you probably could. The question is, should you map it?

Someone once told me a story about a guy with a hammer who saw everything as a nail…you know the one. O/RM tools are frameworks. Frameworks are built on constraints and assumptions. Those constraints and assumptions are ideal in certain environments, but not in all environments…not everything is a nail. Our job as software developers is to match ideal solutions to the problems at hand—not to use the only solution we know or the most popular solution or the hottest solution on the Net—but the one that best solves the problem we are facing. For different environments, we need different tools—iBATIS is one of them.

Today iBATIS has been implemented in three languages: Java, C#, and Ruby. It is maintained by a team of more than a dozen developers and it has a community of thousands of developers. You can read about it in books and articles and blogs on the Web. While iBATIS isn’t the top dog of persistence, and it likely never will be, it is a success story. I realized that the day I stopped answering questions on the mailing list: the community had taken over.

A self-sustaining community is the true mark of success of an open source project. If you’ve read this far, I assume you’re part of that community. So let me join you in celebrating the success of our little framework.

Clinton Begin