Today, more and more proprietary software vendors are choosing to go Open Source. Doing this enables them to leverage the community benefits of Open Source, shorten the sales cycle, and gain a competitive advantage over other proprietary products.

However, for those firms considering a switch to Open Source, there are some hard decisions to make with regard to their product architecture. Should they provide only a single Open Source product, and earn revenue from add-on services like support and consulting (RedHat)? Or should they adopt the Open Core model, offering their product under both Open Source and proprietary licenses (MySQL)? Or perhaps some hybrid of these two approaches?

In this post, I’ll consider two common architectures, which I’ll respectively call the “Open Core” and “Solutions” architectures.

Open Core Architecture

The term Open Core is used to describe business models where vendors offer both an Open Source “community edition” and a more fully featured, commercially licensed “enterprise edition”. MySQL is undoubtedly the most common example of this model, although it’s widely in use among other firms as well.

Typically, the enterprise edition product comes with vendor guarantees and support, thereby making it more attractive to larger enterprises. At the same time, it ensures that smaller firms and individuals, who may not require these attributes, are not excluded, as they can freely access and use the community edition of the product, albeit without any guarantees.

Solutions Architecture

Under the Solutions Architecture, a vendor offers separate packages or distributions of the same Open Source product, identified in terms of the functionality they add. Thus, rather than an “enterprise edition” and a “community edition”, the vendor might provide specialized offerings for different skill sets such as a “developer edition”, “database administrator edition”, “project manager edition”, and so on.

Typically, each solution comes with vendor guarantees and all the distributions are based on the same Open Source code base. This ensures interoperability and peace of mind. At the same time, this approach is economical for end-users, as they only pay for the product features that they need, and so it allows both individuals and large enterprises to participate in the product ecosystem.

Which is Better?

Given these two options, which should a firm choose? Here are some arguments to consider:

• Under the “Open Core” architecture, the vendor’s community edition may be perceived as “crippleware” lacking the more advanced features found in the enterprise edition. Users may accuse it of cynically providing a functionally limited Open Source version merely to drive sales of its commercial version. This can lead to a negative impression of the vendor, and may adversely affect its market positioning.
• At the same time, by using Open Core terminology such as “community edition” and “professional edition”, the vendor might be seen as implicitly categorizing some users as “non-professional”. Where these users are also contributing to the community, this will naturally cause friction and conflict. The Solutions Architecture, by contrast, makes no such claims and is less likely to produce an “us versus them” mindset.
• In a fragmented, highly competitive market, a vendor faces competition from multiple niche products, both proprietary and Open Source. In this situation, the Solutions approach allows the vendor to compete effectively against these specialist products, as each distribution is narrowly positioned to attract a distinct market segment.
• On the other hand, the Open Core approach is an easy sell to the enterprise market. The typical enterprise edition product will include technical support, warranties, SLAs and compatibility guarantees, all of which are critical to medium- and large-size enterprises. In general, it is also easier for a direct sales force to sell a single enterprise-focused product rather than a distribution-based product line.
• The Open Core model is already successfully in use by many firms. It therefore has the benefit of pre-existing market awareness and acceptance, and it is easy for customers to understand its nomenclature and business benefits. This simplifies the sales process, as there is less customer and salesperson education required.

Conclusion

As the above arguments make clear, there aren’t any hard and fast rules about which product architecture is “the best”. However, it’s possible to identify arguments for and against each approach, and thereby decide which one will be best suited to the firm’s specific goals and requirements. Needless to say, the final decision will have a far-reaching impact on the firm’s business model, competitive positioning and marketing strategy…and so, it should be taken after due consideration of all the relevant factors.