To give this piece some context, it was originally written for my company communications and intended for a non-technical audience. In it I discuss a number of factors that might influence decision making around the use of open source software and go into how the open source model works in practice. I'm imagining most of the readers here will be familiar with these points and so there is likely to be a bit of preaching to the converted going on! Nonetheless I thought it would have a useful, more public home here on Skrift as I suspect many of the issues raised come up in your own discussions with clients and stakeholders.
Recently I spent a day in Milan, attending the Web European Conference. The keynote was given by Scott Hanselman from Microsoft, who in an entertaining and wide-ranging talk, spoke about the changes at the company in their increased adoption of an open-source model for web platform software development. It's quite a turnaround from the Microsoft of old and, for most developers on the .Net platform, a very welcome one.
For many years at Zone, the development team has been a user and supporter of open-source software. In fact, if you were a client of ours through one of our design and build projects, there's a good chance that it underpins the website we produced, in the shape of the open-source content management system, Umbraco. We're gold partners with Umbraco, providing a financial commitment in part as it provides some direct benefits of credibility, support and software licences. Primarily though, as an agency, and also as individual developers earning our salaries of course, we do well in terms of delivering quality solutions to our clients from the Umbraco product and open-source software in general. So given we are in a position to "give something back" I’m very glad we’ve made the decision to do so. It benefits all who use Umbraco to have a well-funded HQ to push the product forward.
When it comes to selecting a product for use on a particular project though, it sometimes feels that the open-source option is evaluated purely on price. And that price, often being free for use, is clearly not a benefit to be discounted! When the licence costs of similar, proprietary products account for a significant percentage of the project budget, clearly the open-source option needs to be given significant consideration.
Of course though its value needs to be weighed against the features available with competing projects that may in areas look to be more complete or wide ranging. The argument can be made that the custom development required to bring the open-source solution up to the level of the proprietary one would negate the saving from avoiding the licence cost. Strictly speaking that's almost certainly true, but I'd suggest it can be a slightly misleading angle on the issue.
To take one example, A/B testing is something that if you ask any website stakeholder if it's something they'd like to have the option to use, the answer will almost certainly be yes. And given that it might make sense to consider only products that offer that feature out of the box. However, supporting these types of tests arguably isn't really a core feature for a content management system, and thus it could be the case that even if available, it may not be the best solution to meet the need - rather it's likely that other tools, dedicated to the service, might be better for this type of task.
It's also important to consider the detail of the requirements that look to have need of a particular feature. Whilst building out complete parity may well be a very costly task, it may be that the custom development work required to meet the precise needs of the project - perhaps also utilising other tools or third party extensions - is a much simpler undertaking.
In general though I would argue that the price factor is really only one of a number of variables to consider when making a choice such as this, particularly when it comes to the selection of the appropriate content management system for a website project.
Firstly, there's the actual nature of open-source itself - allowing anyone to view the source code that is built to produce the product. This means that developers when diagnosing a tricky problem don't necessarily hit a brick wall when the custom code calls into the APIs of the product and are instead able to trace the code right through to the underlying framework and beyond. More than that though, in encountering an issue or missing feature with the product, they have scope to do something about it themselves. We've had issues we've discovered with Umbraco, provided a fix and it's then been available within the product and ready for the next release sometimes within a matter of hours, which is an incredibly quick turnaround to a resolution.
A word on the process though, as from the above it may sound that open-source development is a bit of a free-for-all, which is far from the case. Instead what happens is a developer wanting to contribute a fix or feature to the core product takes a copy of the code - a process known as "forking". In that fork they are free to make whatever changes they would like. Rather than simply continuing with that copy of the primary source code though, they will generally submit their changes back to the core developers in the form of a "pull request". This is then evaluated, conversations around amends are carried out, and, if the code is considered of good standard and the new feature adheres to the planned road-map, the changes are pulled in to the main source code repository and built into the product.
An open-source option may be considered a slightly more risky option though when it comes to getting access to support for any issues that might be encountered. By paying a licence fee, it will likely come with some guarantees of assistance and fixes to any issues, often provided by a larger and better funded organisation. This is clearly an important consideration in product choice and the appetite for risk in this area needs to be something that is weighed into the decision.
There are a couple of ways open-source offerings, like Umbraco, close the gap in this area. One is around support contracts, which is where a fee is paid not for the product licence but for help with any issues found in using it. Working with a gold partner such as ourselves is another way to gain access to this benefit. Secondly though there's the community of developers and other Umbraco users that has grown up around the product. It never ceases to amaze me in meet-ups, conferences and online how willing people are to share their expertise and provide assistance to others, whether they are starting out with the product or are advanced users looking for help in trying out new scenarios. There's clearly something about the open-source nature of the product and the transparency of the work done by the core team that encourages and nurtures this.
A further point I'd like to consider is the nervousness people rightly have about taking a bet on a particular product to be the core of their website platform. It's likely a decision that will have repercussions for a number of years as starting over with a new content management system will be a costly undertaking. They want to know that the product they select is going to be around for the duration, continue to be supported and be developed in new areas so they can benefit via upgrades. Again, on an initial consideration, a well-funded organisation offering a proprietary product may well offer more reassurance in this area.
The other view though is that an open-source product with a long history, increasing adoption and continued development is also very likely to be around for the long-term. Because of its open nature, most of this is transparent and can be evaluated - you can see planned road-map, and the pace of progress in terms of development of new features and the effort made in responding to and fixing reported issues. And of course, if the worst really happened and the core developers and supporters moved onto other things, because of the open-source nature there's nothing to stop others stepping in to continue support and development.
Finally I'd just close with noting that whilst any decisions between open and proprietary options clearly have to be made with the considerations of the business in mind, there's one other factor that might also be weighed in. And that's by selecting and supporting an open-source solution, it helps it to grow. There are more users, and more developers, that gain familiarity with the product and can then get involved with helping to improve it. With the pace of change in digital, keeping up with the needs of users and website stakeholders is a considerable challenge. By supporting an open-source offering it helps it to thrive, allowing smaller organisations and charities that don't have large budgets for website developments to have access to a viable and valuable option for building and maintaining large scale and complex websites.
I hope that's provided a little insight into what goes on in the open-source software development world and given some more food for thought when it comes to product decisions.