January 2009

"Together they would travel on a boat with billowed sail,
Jackie kept a lookout perched on puffs gigantic tail,
Noble kings and princes would bow whene'er they came,
Pirate ships would lower their flag when puff roared out his name."

Puff the Magic Dragon

Selling software to consumers is tough as they want perfection and expect to pay nothing. Consumers are fickle and the competition can be fierce. By comparison, large enterprises have big problems and buckets of money to spend on solutions, allowing you to focus your marketing on a small target. While large enterprises sound like ideal customers, the small independent software vendor (ISV) selling to a large enterprise faces long sales cycles, extreme quality expectations, challenges integrating into a complex jungle of pre-existing systems, and the need to partner with others to create a complete solution.

At Fanfare, we believe that there are a variety of successful software business models that employ open source strategies. One such strategy is to sell closed source solutions constructed on top of an open source platform. In fact, the Eclipse Foundation considers enabling this kind of business model as one of its mandates. We sell a complete system test automation solution that is built on top of Eclipse and sold to customers as a turnkey solution using Eclipse's Rich Client Platform (RCP) technology.

In this article, we examine six benefits of selling closed source solutions built on top of an open source platform. Some of these benefits apply to any ISV, but many apply to ISVs selling to large enterprises.

Benefit 1: Platforms Instead of SDKs

The days of selling a completely standalone software product are long gone. Enterprise customers need software customized to integrate into their systems. However, customizing software is a distraction for the ISV. Customers demand integration between products from different vendors. Yet, bilateral integration between vendors is time-consuming. Worse, when a small vendor requires integration with a larger vendor, it may be difficult to attract the attention of the larger vendor.

In short, the integration answer is no longer the software development kit (SDK). A small vendor can create an SDK, but it is going to be difficult to get others to use it. Enterprise customers seeking customization are likely to just ask the vendor to do the work themselves.

Today, the answer is the platform itself. With the right extensibility model, a small ISV can succeed by translating its domain expertise into an open source set of domain-specific APIs and extension points that are available to anyone to use and build on. For example, we recently proposed a new Test Automation Platform (TAP) project to the Eclipse Foundation. What started as an SDK for Fanfare's iTest product may become a new set of APIs that Fanfare's partners, customers and competitors can use. Because it will be part of Eclipse, the API will have a much better chance of forming a vibrant community that extends beyond Fanfare. It also means that Fanfare's enterprise customers can develop internal proprietary components on top of this platform with some comfort that they are not specific only to Fanfare's products. Several of the companies that have expressed interest in this project are the large enterprise customers themselves such as British Telecom, Cisco, and HP ProCurve.

How does an SDK differ from an API? The significant difference is that an SDK is specific to one vendor and is "one-sided", meaning that the vendor is exposing an interface that others can use to implement some extension that will only work on top of that one vendor's solution. By defining an API in an open platform, it becomes a "two-sided" interface, meaning that any implementation on top of the API will work with any implementation providing that API. The implementation might be provided as open source within something like Eclipse, or it could be implemented through a services extensibility model, allowing multiple vendors to contribute competing solutions.

Why would an ISV contribute an API and potentially expose itself to alternative solutions from their competitors? In short, small ISVs thrive when communities develop. Trying to build a community around a closed SDK is very difficult. But by opening the APIs to potential competition, they also create a climate in which a community is more likely to flourish. Moreover, the ISV's customers are more likely to encourage other suppliers to support these APIs because they are not vendor-specific.

Benefit 2: Collaboration

Arguably, one of the most difficult challenges for ISVs selling into large enterprises is in defining the requirements. It is not uncommon to deliver a product to a large customer only to hear about the features that they need that were not included. Even with a thorough product management strategy, minor miscommunications can result in major delays as these missing requirements are addressed. And that usually means a delay in revenue.

Does open source change this? Not always. But many large enterprises have their own internal development teams which are tasked with integrating your solution with their proprietary systems, and this is often the source of the most complex requirements. Rather than waiting until you are ready to deliver your final, tested software to your customers, open source allows collaboration with your customers and partners. There is much less room for ambiguity when you are exchanging requirements using actual software. Even better, your customer can be developing their integrations at the same time that you are developing your implementations. By the time you are ready to deliver, they are ready to deploy.

This open source benefit can expand far beyond a particular deployment. Fanfare is working with one of its biggest customers on a project based on the same code that we expect to contribute to the upcoming TAP project described earlier. They can comment on the interfaces they need while they build the integrations into their existing proprietary tools. We gain confidence that what we are building is actually going to be used. Partners can see that this has momentum and will build complementary components that interoperate at the same interfaces. Win-win-win.

Benefit 3: Thinking Ahead

Small ISVs have a speed advantage when compared with large software suppliers. An ISV can compete by innovating faster and bringing new ideas to market sooner than their larger competitors. What often happens, though, is that this can quickly produce an intractable code base. Success in the early years of an ISV can be followed by a delay from the necessary regrouping as more sustainable development processes are put into place. While few ISVs will admit that they have this problem, we all do and it can happen at the worst time when you are selling to enterprise customers. You finally have adoption starting to happen after a long sales cycle. Now you're being asked for a whole set of new features. This is exactly the time when you don't want to experience a long delay as you re-architect your software.

How does open source help to address this problem? First, the more transparent the software, the better its quality. If software is going to be scrutinized by your peers, you are going to do more work to ensure that it is not only bug-free, but that it is also well-organized and highly extensible.

Second, one can build on a mature and successful model of modularization. By following Eclipse's natural extensibility model, our software designers are more inclined to build reusable components rather than a big monolithic codebase--even for the closed-source components in the final solution.

Third, one is faced with the decision "will we open-source this?" at the beginning of every project. If not, will our big customers or partners expect to be able to extend this functionality? If so, we need to define a part that is open and extensible.

Benefit 4: Cross-Platform

Fanfare's first generation product was built on top of Microsoft's .NET framework. At the time, the Microsoft development tools seemed like a good solution for getting a rich client application to market quickly. Customers quickly indicated that broad adoption would require product availability on all leading operating systems. Instead of moving to a closed-source Java solution, we recognized that being truly cross-platform means a lot more than just Java. Again, attempting a solution that works on multiple operating systems without an open source platform would be folly as the vision of "write once, run anywhere" is a pipe dream. Supporting a product on multiple platforms is a lot of extra work, and an open source platform like Eclipse is a huge advantage in this regard.

Benefit 5: More Credibility with Customers

We sell our products to some of the largest enterprise customers in the world who use these products for mission-critical purposes. Many of these customers are not active users of Eclipse. At the same time, virtually every customer is delighted to hear that Fanfare's solution is built on top of a solid open source foundation. This gives them confidence that the platform is solid and that they will be able to take advantage of other innovation coming from the Eclipse community.

Benefit 6: Less Code to Develop

Regardless of its target market, the last thing that an ISV can afford to do is to reinvent the wheel. Almost every software product requires a platform that provides modularity and common user interface components. One doesn't want to spend one's valuable development resources on a platform. Buying one might be possible. But it is nearly essential to have access to the source code for the platform because, as a commercial vendor, your corporate customers will expect you to troubleshoot and resolve all problems in your solution--including those in the platform. If you don't have the source, you are in a tough position.

One way in which this benefit is specific to ISVs selling to large enterprises is because of "solution selling". Enterprises typically don't want to assemble components themselves. They prefer to have a vendor provide them with a turnkey solution. For example, our customers use a variety of version control systems. Because our product is built on Eclipse, it can bundle a variety of source control client components that are available for Eclipse. Moreover, our customers can seek out their own preferred components and integrate these themselves using Eclipse's software management capabilities.

Conclusion

Selling software to large enterprise customers is difficult. These customers require high complexity, demand superlative quality, expect infinite extensibility, and don't want to be held hostage by a single vendor. At the same time, these customers are willing to pay for good solutions and will invest their own technical resources to ensure a great product that they can integrate into their workflows.

We believe that an open source platform strategy is the best way for ISVs to attach to these markets. Development can be focused solely on the pieces that are unique to the ISV's expertise. Enterprise customers now appreciate products built on open source platforms like Eclipse, especially when they can extend that platform themselves when needed. ISVs benefit from an open source development model, even for the portion of their software that remains closed source. At the same time, it takes more time to deliver open source software and ISVs need to be prepared for that.

Open source is a two-edged sword for small software vendors trying to sell into large enterprises. But that might be just the weapon Jack and Puff need to ward off those pirate ships.

Share this article:

Cite this article:

Rate This Content: 
No votes have been cast yet. Have your say!