« The end of IT in small and medium businesses | Main | Vishy's Vonderful Vitticism #7: Social grease in India and America »
October 19, 2006
How open source has benefited software tools
Good software tools are an essential part of any productive software engineer's arsenal. They deliver key insights into enterprise-grade code and highlight issues that engineers may have missed upon an initial review. Software tools are highly appropriate for code instrumentation and tuning, although they perform essential functions in build and release management as well. We will compare these two kinds of tools separately on open source and proprietary platforms to infer the effects open source has had on software tools.
Code instrumentation tools
Proprietary platforms like Microsoft Windows have had excellent instrumentation features for a while now because they are the only way of introspecting into a system that does not come with source code. There is strong support at the programmatic level for building high quality software instrumentation tools. Perhaps to keep from stepping on Microsoft's toes, not many tool vendors have exploited this support to the fullest extent possible. Microsoft itself, being a software behemoth, focuses on a number of business priorities other than software tools. Barring a few excellent offerings from Compuware and SciTech, software engineers are limited to offerings from Microsoft itself. Thankfully, drawing from the strong client side tradition on Windows, these tools are heavily visual and greatly boost developer productivity. To sum up, proprietary platforms offer a few high-quality tools for code instrumentation.
Open source platforms have the opposite problem: a wide selection of tools that are sometimes lacking in quality. To their credit, most open source platforms permit highly granular examination of how a process behaves, down to the system calls it generates. The trace family of tools on Linux and the truss tools on OpenSolaris enable this kind of deep examination. Unfortunately, because of their checkered history on the client side, there aren't many visually impressive performance tuning tools. True to the Unix tradition, however, the statistics these tools produce can be integrated into larger reports relatively easily. Another factor that might impede the development of high quality code instrumentation tools on open source platforms is the pervasive availability of source code. A software engineer does not need sophisticated instrumentation tools if merely examining the underlying source is enough to diagnose a performance problem.
Build and release management tools
Open source has been highly beneficial for build and release management tools. New ideas have debuted successfully in open source settings and have later been emulated on proprietary platforms.
After decades of build tools hailing from the make tradition, the Apache Foundation's XML-based build system, Ant, took a brave new approach to the problem of generating ready-to-deploy software builds. The prolific Apache community refined this approach into the network-ready Maven. Maven can intelligently compute the right versions of a project's dependencies and download them from a central repository. The key differentiator in Maven's approach is that it confers first class status on a software project using its Project Object Model. The excellent Eclipse development platform and its flexible plugin architecture have been instrumental in integrating these tools into the software engineering experience.
For some time now, Microsoft's Visual Studio IDE has been the primary gateway to development for the Microsoft platform. The Microsoft developer population of old was fragmented: the technically savvy minority of Visual C++ developers had different needs from the Visual Basic developers that formed the majority. Visual Studio's build system was opaque and command line alternatives like nmake were available but not very well supported. The arrival of Microsoft .NET alleviated the first problem but not the second. The proliferation of XML-based build and release tools on Java led to analogous open source efforts like NAnt for Microsoft .NET. Unfortunately, Microsoft hasn't taken to the open source projects around its platform as well as Sun has around Java. It took Microsoft some time before they picked up on the importance of XML build systems; they announced their own take on an XML build system, MSBuild rather than embracing and extending NAnt, which had accumulated a conspicuous user base.
MSBuild offers tight integration with Visual Studio and as such, offers a better software development experience than NAnt. NAnt continues to thrive, but will probably be driven underground as MSBuild continues to gain traction on Microsoft's official build environment. Although Microsoft has considered open source models fundamentally antithetical to its own business model, its recent overhaul of Visual Studio's plugin architecture to make it easier to develop for might stimulate the development of tools outside Microsoft. Microsoft also supports command-line use of MSBuild, which is an unorthodox measure for a company that has heavily favored Visual Studio as a gateway for platform development in the past. Perhaps build and release management outside the Visual Studio IDE will come into its own after PowerShell, Microsoft's first fully scriptable commandline is released. However, unless Microsoft truly supports software development outside Visual Studio and encourages open source projects, the Microsoft developer community will be limited to Microsoft's offerings alone.
Conclusion
Different classes of software tools have benefited to different degrees from open source. Nonetheless, it is fair to say that open source has been and will be a boon to the software tools business.
Posted by Vishy at October 19, 2006 08:34 PM