I have just finished reviewing the book Open Source Development Tools for Java, which provides excellent coverage of such topics as log4J, CVS, Ant, and JUnit. There is a chapter on UML tools though in which the author almost apologizes for the lack of good open source design tools. There is a plethora of projects on SourceForge.net from J2EE runtime frameworks to IDE plugins, yet there is almost nothing that encroaches upward into the arena of analysis and design tools.

One theory for this is that high-level design tools are the value-add that software vendors hold back from the open source community and sell in high-priced offerings. While this does occur to a certain extent, it can't be the real reason. Open source is a marketplace where useful things become free and commoditized, as witnessed by runtimes such as Tomcat and JBoss or tools such as Eclipse and NetBeans. An open source business model that certainly works is to give away a product and then charge for consultancy and help using it. Is it just a matter of time before a big vendor starts to give away modeling tools? They could benefit if their product became a de-facto standard for developers, potentially quashing the competition in the process and growing the marketplace for a specialized consultancy.

Another reason given by a colleague, whom I posed the question to, was that design tools just aren't that useful. His measure of worth is a product that creates something he can compile, touch, execute, and debug. There will always be those who subscribe to the opinion that high-level modeling is the realm of bluff and fluffware practiced by those who masquerade their inability to write code behind its numerous charts and methodology steps. It's an unfair view though that can be equally leveled at developers who drown themselves in worrying about obtuse coding techniques instead of just writing a program that lets users get their job done more efficiently. The best tools are those that bridge the gap between the high- and low-level software disciplines by seamlessly working with the same artifacts, presenting alternative views for disparate learning styles.

Visual learners prefer to think and work with charts and diagrams to analyze problems and communicate solutions, while I view coders as tactile or kinesthetic stylists who feel happiest with their IDE paused at a breakpoint showing them a stack trace from which they can explore and learn. There is a generation of tools that tended to be one way, where design charts generated code to be compiled and executed; these are probably the ones my colleague spoke about so scathingly. These changes to the source code don't get reflected back in the tool and the code is undoubtedly more bloated and less efficient than if it had been written by hand. The developer who has to debug problems in the spaghetti unfairly stores his or her frustration as a general disdain for all design tools. Such attitudes are unfair and often dated, however, as there are some excellent design tools available that happily round-trip between high-level diagrams and actual code. A good example of this is Sun's Visual Paradigm for Software Development Environment www.visual-paradigm.com/product/sde/nb/index.jsp for NetBeans or Rational Software's Rational Application Developer www-306.ibm.com/software/awdtools/developer/application/ that builds on an Eclipse codebase.

Returning to the plot line: Why then is the open source community starved of good, high-level tools? The reason I subscribe to is that the open source community just hasn't got around to creating them. The stack of open source software out there has been built from the bottom up, with small nimble runtimes and tight extensible IDEs. Such software is often built by those who use it themselves, providing a tight feedback loop between design and implementation that has resulted in the well-baked solutions that we take for granted as being freely available. For the most part, this space is well populated and there are a healthy number of offerings to chose from. I think that the future bodes well for a growth in open source tools that tackle and reach into the higher-level problem arena of software development. This could come about several ways. A tool such as ArgoUML (http://argouml.tigris.org/), a very solid open source UML product currently without an IDE home, might become more integrated with one of the major IDEs like NetBeans or Eclipse to piggyback a larger user base. The Eclipse Foundation has a tools project, Graphical Modeling Framework www.eclipse.org/gmf/, although this currently seems very focused on the Eclipse Modeling Framework as its high-level runtime rather than UML in general.

Another possibility is that a major vendor with a track record in open source tooling throws its product into the ring, or perhaps Borland will rediscover the mindshare it used to have with TogetherJ in one of its designer or architect products.

Whatever occurs with design tools and open source, I hope it's one that marries the best ideas from those with the knowledge of how a good high-level design tool should work with those who know how to code, implement, and manage a successful open source project. The outcome will be that we have a more productive suite of software development tools to choose from. Once this progression is complete, the problem arena will move even higher to open source tools that allow the end users to capture requirements in a form that communicates between their problem domain and the code. The sky's the limit.