Whats been the impact of open source on the build environment biz?
Huge! Over the past 11 years, our only competition has been with open-source solutions such as Gnu Make and Ant. It has only been in the last few years that IT organizations have begun to look more seriously at the build process. When they look closely, they begin to recognize the extraordinary hidden cost associated with ad hoc scripts written in these many open-source scripting languages.
Similar to SCM [software configuration management] tools evolving from RCS [Revision Control System, an open-source tool], the build process is evolving from its open-source lineage.
Whos your primary competition?
Ant and Make still remain our primary competition. Many people perceive BuildForge [as competing] with us, but I do not see it that way. BuildForge has a nice name, but it is actually a job-scheduling tool that executes the build scripts written by developers using Ant and Make.
BuildForges solution manages ad hoc scripts, but it cannot manage or report on build dependencies such as SOA [service-oriented architecture] and J2EE [Java 2 Platform, Enterprise Edition] objects. It does not enforce the location of source libraries during the compile process or even help control if the debug compile flags are turned off when a production build executes.
These are the core areas that we address by creating a reusable build framework and centralizing all of the critical control points. What we do well is Build Configuration Management. Our commercial competitors run from truly managing the builds, and instead they just manage the ad hoc scripts written in the open-source languages. Managing the scripts is simply not build management.
Why is Eclipse the place to be for your company?
Openmake supports a large variety of compilers, from the mainframe to windows. In 2000, we supported three main IDEs, Borland, IBM and Microsoft, with a few others in the mix. When Eclipse came along we were very interested in participating because we saw the advantages of having a standardized IDE. Now we support Eclipse and Microsoft with the few others having moved over to the Eclipse platform.
Because we integrate with IDEs at the project level, having an IDE standard has saved us from many point-to-point integrations. We are hopeful that the Eclipse ALF project will have a similar consequence.
Whats your story for Microsoft developers?
We have supported the Microsoft platform since our early days in 1995. As Visual Studio has changed and evolved, we have continued to address the Microsoft developers main issues. The big one is circular dependencies. Because of our dependency-mining capabilities, these large .Net and VS shops use Openmake to keep track of how objects and projects are dependent upon one another. Also, in the .Net release, Microsoft stopped supporting Nmake and moved to a build.xml format, which in turn created the Nant open-source solution. Not all Microsoft developers wanted to quickly turn to writing Nant scripts. Openmake solved this problem as well.
What must we do to get more women in the exec ranks of tech companies?
I read an article recently in a business magazine about how only recently VCs [venture capitalists] were willing to invest in women-owned technology companies. I know from my own experience working with partners that there is a preconceived notion that women are not technical; therefore they cannot possibly be running a "bleeding-edge" technology firm. Breaking this misconception will be difficult, as it seems to run very consistent and deep within this male-oriented business. Most VCs look for young men who are writing "really cool" software.
The article focused on women-owned VC firms who were helping women-owned technology companies. I can tell you, I would love to meet one of those VCs! I believe that women will need to continue to encourage other women in this field. I have survived because I am a bit naive and very resilient. Not all women have both of these traits.
How did you break in?
Do you recall the movie "Forrest Gump"? Well, that was me when I first started. This is what I mean by being naïve. Had I known what I would be put through, I might have turned and run the other way. In the late 1980s, I was working on the East Coast as a developer when I noticed job advertisements for programmers starting at $50 an hour. I went and talked to a few "head hunters" and before I knew it, I had my own company and was pushing the consulting rate up to $75 an hour.
I met many women project managers along the way that wanted me on their teams because I was honest and gave a clear picture of the issues at hand. I began to transfer these skills to working with more senior members, mostly men. I learned that when working on a development team, honesty and the ability to clearly explain the issues was a valuable asset. This took me a very long way. When I started Catalyst Systems Corporation, I applied the same principals.
What I have learned, however, is that when it comes to selling software, honesty does not work so well. I am sure that Catalyst Systems Corporation and Openmake would have grown more quickly if I had spent more time developing buzz words and marketing spin that over-represented what Openmake does. Instead, we have always turned to investing in the technology instead of the hype.
Over time, this professional consistent message has served Catalyst and me well. We are a respected company with a strong and loyal customer base. It has taken us 11 years, but it has been worth the journey.
Research Assistant
