Bringing new products to market is always a challenge, especially when it requires competing with well-established players. I have experienced this challenge again and again as an entrepreneur, and it’s never easy. Fortunately, it’s as hard for the big guys to stay on top as it is for me to break in. Many well-run companies fail to maintain their market position, giving startups the opportunity to take advantage of their inability to innovate. I learned this for the first time when I worked on NetBeans. When Ian Formanek, Yarda Tulach and I started NetBeans in Prague in the summer of 1997, our chances of success were extremely low. There were hugely popular and well established Java development tool vendors in the market already: Sun, Symantec, Borland, IBM, Metrowerks among others.
While we were unaware of Clayton M. Christensen’s book The Innovator’s Dilemma when we started NetBeans (it was published the same year), his “failure framework” for why incumbents fail to innovate explains why NetBeans had a chance to succeed, and it’s still surprisingly applicable to today’s Java tools market and Good Data as well. Let’s look at a few of Clayton Christensen’s main ideas in the context of Java:
1. Sustaining versus Disruptive Technologies
– sustaining technologies improve performance of established products
– disruptive technologies underperform established products in mainstream markets
– they have other features that a few fringe customers value
– products based on disruptive technologies are typically cheaper, simpler, smaller, and, frequently, more convenient to use
The IDEs in the mid-90s were closed systems — there was no notion of a tools platform or of extensibility. The most advanced way how to integrate a third-party tool such as a debugger was to add an item to a menu system. This barrier was much too high for most to attempt. We decided to take the advantage of dynamic features of the Java language and build a fully extensible tools platform – to make it as easy to extend the IDE as it is to extend Java itself. Our vision was a platform that would allow third parties to dynamically add new features and functionality, and our design center was good set of Java APIs for platform extensibility. “It is difficult to draw the line between the tool and code” was our motto.
Unfortunately, leveraging Java meant writing the entire product in Java. Almost all Java-producing development tools were written in C/C++ back then in order to make them as fast as possible. Keep in mind that Java was notoriously slow in those days; so slow that it took the first versions of Netbeans several minutes just to boot. Clearly, building an IDE in Java was a loser. The singlemost important mainstream feature of development tools was speed, and that’s where we failed miserably.
On the other hand, we offered an IDE that was easy to download, install and extend. And in the early days of Java, many developers wanted simply to experiment with the language and were not building sophisticated applications. Much to our surprise, within several months after we launched Netbeans, and with no marketing money spent, we had over 100,000 downloads.
2. Trajectories of Market Need versus Technology Improvement
– technologies can progress faster than market demand
– suppliers often “overshoot” their market: they give customers more than they need or are willing to pay for
– disruptive technologies may be fully performance-competitive in that same market tomorrow
Since mainstream customers were developing and deploying very large C++ projects, they did not want to compromise on speed. A crappy, limited and slow tool was a non-starter for the leading tool vendors. “Speed” was their brand. But the early Java customers did not really need speed. They wanted simplicity and extensibility.
Plus, the slow nature of Java in the early days did not bother us. We knew speed improvements were coming in two important directions, from two dominant vendors. Sun was getting better at Java optimization (HotSpot was released in April 1999,), and more importantly Intel kept producing faster and faster CPUs.
In fact, by the time Java became an established mainstream language, NetBeans performance problems were history. A few Java old timers would laugh about how slow the language used to be, but now most developers did not even consider speed a factor in choosing Java over C++ or any other language.
3. Disruptive Technologies versus Rational Investment
– disruptive products are simpler and cheaper
– disruptive technologies are first commercialized in emerging or insignificant markets
– most profitable customers of leading firms don’t want and initially can’t use products based on disruptive technologies
– disruptive products promise lower margins and not greater profits
– disruptive technology is initially embraced by the least profitable customers in a market
At the time when first-generation Java products ruled the market, it was impossible to predict the main advantages of the language.
Most assumed portability was the primary benefit of Java, especially from customers tiring of the never-ending battles among technology heavyweights and their proprietary systems. Since the mainstream developers used almost exclusively Windows, it was not worthwhile for the tools vendors to invest in rewriting their existing tools in Java. The cost and complexity of transition was prohibitive. But portability was a secondary benefit for us. We were looking for extensibility, so it made a lot of sense to compromise our speed and build a Java-based tool. Plus, starting from a scratch was a real advantage.
We realized very quickly that our initial market were predominantly students learning Java, since our early downloads came from technical universities. And our business model was not to sell the platform to these users. Our long term plan was to open source the platform and make money from more valuable plug-ins.
We did not have the time to execute on this plan as NetBeans was acquired by Sun Microsystems in the fall of 1999 – a little over two years after we started. By that time it was obvious what advantages Java brings and it had a profound effect on the market: Borland had just released their first version of Java based JBuilder, but it was probably too late. Symantec Cafe never made the transition, Metrowerks was acquired by Motorola and the product died.
In 2001 IBM decided to eclipse Sun tools: they dumped their VisualAge and released an open-source, pluggable, Java based tool platform called Eclipse. Why Sun allowed IBM to catch up is another question and it’s well outside the failure framework.