UPDATE: If you found this post worthwhile, check out Matt Asay’s latest post at CNET, “What open source could learn from proprietary platforms”, which includes a reference to our post.
Increasingly, savvy organizations are asking for web solutions built on open source content management systems. We’re all for it: we’ve built solutions on a variety of platforms, including WordPress and Drupal, both open source projects. We’ve even released a few open source plug-ins of our own.
Open source certainly offers benefits, including a transparency that we believe encourages better programming (“the best disinfectant is light”), the removal of the dependence on a single software vendor, and often times, incredibly low cost of ownership. All of that said, as advocates of custom solutions for clients with custom needs, we know that the open source solution isn’t always the right solution.
More importantly, we’ve found that savvy clients and prospects asking for open source are actually getting at something more essential: open platform solutions.
Before we dig into open platforms, let’s be clear that the only unique attribute of an open source project is, fundamentally, the openness of the entire code base. That single characteristic creates some unique potential advantages, all else being equal. But fundamentally, all this means is that anyone – including a third party developers – can look at, edit, and maintain the core code. Theoretically, because it’s open source, we can extend the 90% solution to do anything we need it to do. Right?
In reality, unless the open source solution is compact and simple (translation: not a mature content management system), it is rare for most third party developers to change core system source code; and for a good reason. Changes to base code make the process of patching and upgrading the platform riskier and considerably more costly (potentially extremely costly, depending on the scope of changes).
What these tech savvy clients are actually seeking are the following characteristics:
- An extensible, and well documented platform or “application programming interface” (API) open to third party developers
- A platform with some critical mass of adoption
An open and extensible platform / API allows third party developers to introduce customizations to the system without ever touching core source code. Any mature content management system includes fully supported methods for “skinning” (design customizing) and extending (plug-ins / add on modules) the system. Software updates will not break these extensions or, if they need to, will provide warning and support to developers who need to make an efficient transition.
Of course, it is important that the API be well documented, so that any developer can adapt to the system. Lack of developer lock-in (as opposed to software vendor lock in) ensures that the system can continue to be supported even if the client/developer relationship ends. Of course, open competition among developers potentially leads to better client value. Unless the selected CMS looks and behaves exactly as needed out of the box, these development costs are often far more relevant to long term costs of ownership than upfront licensing fees.
Consider the Windows and Mac operating systems: they are closed source platforms with excellent and well documented APIs, allowing anyone to develop software for them. A typical client asking for desktop application development would probably prefer a Windows solution to a Linux one. Really, of what quantifiable value is the open source nature of the Linux platform to this client? (Answer: potentially lower operating system licensing fees, perhaps at the expense of more costly support and development.)
In the web applications domain, Salesforce.com is an excellent example of a closed source application with an excellent API, developer tools, and mass adoption. It is far superior, in our exprience, to open source alternatives like SugarCRM.
A critical mass of adoption provides the advantages of economies of scale. Above all, platforms with mass adoption have a wealth of existing extensions and modules ready to be adapted to any site. Furthermore, more adoption tends to mean more developers and more experienced developers (again, cost of ownership implications). Mass adoption also offers a certain level of assurance that the platform is not going away (consider Windows on the desktop, again). As larger targets, there is also a greater certainty that mature versions are more secure, and that new vulnerabilities are patched quickly.
Let’s take an implicit point and make it explicit: open source solutions are not necessarily open platform solutions. There’s nothing that says a project with open source code has to offer a development platform on top of it.
Not surprisingly, as it happens, the dominant open source web content management systems (WordPress, Drupal, Joomla, etc) are also open platforms. In fact, it is the openness of those platforms, in conjunction with free licensing, that is the key to their success. There’s little doubt in my mind that if WordPress was closed source, but was still free to license and still offered open and well documented methods for extension, that it would still be a hit.
Here’s the message to take away: when considering the cost of ownership of a packaged software solution that needs to be customized or built upon, here are some key questions to ask (depending upon the use case):
- Does the system include an API? Can I add or change functionality without changing core code?
- Can I customize the look and feel without breaking upgrades?
- Can you provide me with a list of third party companies that can support or develop for your software?
- Can I see the developer’s documentation for your product?
- How many licenses of your product are currently in active use?
For most, it’s all about platform openness and adoption, not base code openness.