Are you using the best website platform or technology for your business?
Well you’d have to be, right? You asked lots of web professionals and most came back with the same answer. And that’s the one you went with.
Because the web professionals know their stuff, right?
Well, so they would have you believe.
Get daily business news.
The latest stories, funding information, and expert advice. Free to sign up.
Impartiality remains a pipe-dream
As this blog has highlighted time and time again, the problem with the website development industry is that it continues to be almost impossible to get truly impartial, accurate advice on the best website platforms for the various requirements of smaller business.
The reason for this is that there are two main website creation methods—a ‘developed’ or hand-created website, or an ‘off the shelf’ or proprietary system.
The problem is that the proponents of either approach are mortal enemies. No self respecting web developer or designer would ever recommend an off the shelf solution, just as makers of proprietary websites would rarely recommend the developed option.
The other problem is that the smaller business operator usually has no idea of these vastly different approaches or what they mean for their business.
To understand the thinking of either party you really need to understand the history of website platforms.
Developers vs systems
Way back in the beginning of websites some 23 years back, websites were ‘hand-coded’. What this means is that web developers had to manually write or assemble the html code that forms the basis of the world wide web.
It was essentially a software development environment.
As is the case with any software though, the more entrepreneurial developers realised that if they could make it easier for others to make websites, they could make money on website building software instead of their labour. This is a common occurrence when it comes to software development.
Some of these website building software brands included Dreamweaver and Hotdog.
This immediately led to a split in the way websites were built.
Two schools of thought
Skilled web developers continued to hand-code website functionality, while more basic websites started to be built by those with less development skill and usually more graphic design skill.
However, even with this kind of software, it was still relatively difficult for the ordinary business owner to alter the content of the website without doing a web design course.
Enter the content management system, or CMS. These systems allowed ordinary computer users to be able to edit the content of their website without affecting the overall design of the website. The content areas were essentially separated from the design areas to allow this to occur.
Fast forward just a few years and this approach was revolutionised further with the introduction of cloud-hosted CMS. Now you didn’t even need software on your computer. You simply logged into the secure administration area of the website and made the changes you needed.
The systems also allowed designers to create and even code the look of these websites, ensuring they were not left out of the picture.
Developer platforms emerge
But in the background, web developers were creating their own tools to fight these ‘proprietary’ (company owned) systems. Having already been cut out of much smaller scale web development due to these systems, ‘open source’ systems like Joomla, Drupal and later WordPress provided them with basic building blocks of websites.
Before long, developers started building their own ‘plug-in’ features that would allow new functionality without building it from scratch. These could be for anything from secure shopping carts to flashy image galleries.
And so business customers were able to choose from either open source ‘assembled’ websites or ready built proprietary systems. These approaches borrowed from the real-estate term, to allow customers to ‘build or buy’ a website platform.
However both also had their issues.
Syncing disparate plugins
The fundamental problem with the open source (build) option was keeping so much technology technically in synch with the base platform (increasingly WordPress) and with each other. A simple alteration and upgrade to a plug-in could literally bring an entire website down by conflicting with another plug-in or piece of ‘code’ the developer had written.
This meant open source websites had to be vigilantly monitored for any change to any part of the system so the developer could make the appropriate technical adjustments to accommodate it.
And typically, the customer paid for the labour required to make these changes.
The other issue was around security. While WordPress was provided by a substantial San Francisco based company in Automattic, its plugins could be provided by pretty much anyone who knew how to write code for it.
Unfortunately not all of these creators were scrupulous or overly secure with their plugins, allowing often gaping security holes that were capable of not only bringing websites down, but other nasty occurrences like stealing customer data.
Because the web development industry is pretty much unregulated, the chances of plugins being insecure in some way were pretty high.
But at least the open source approach allowed you the freedom to move your website to another developer if required and to replace plugins that failed you.
On the other hand, the fundamental problem with proprietary systems (that businesses buy, or more accurately, rent) was inflexibility around making alterations to a website’s functionality. Once you were on the system you were pretty much stuck with the way it did things.
However, for most smaller business, this ‘lock-in’ was rarely an issue because, provided a good system was chosen in the first place, the provider would typically improve the system before they had a chance to recognise a functionality shortfall.
Best of all these systems were almost completely free of maintenance and security issues because they had teams of staff employed to ensure all hummed along smoothly. Hosting the websites themselves made this much easier than hosting with yet another third party.
And so two camps emerged. The open source community, which continues to advocate the developer (hourly rate) model, and the proprietary community, which choses the appropriate off the shelf (monthly fee) platform and focuses on design and content issues instead.
But because small business operators typically aren’t educated about website development—and often don’t want to be—most would be unaware the two camps even exist, and are simply taking the advice of the professional that most appealed to them.
Which is right for me?
So which camp is best for your business?
It really depends how unique your specific functionality requirements are.
If you require a functionality that is different to most websites you have seen, chances are you need an open source website. This will allow your developer to create that specific functionality you require and keep it maintained to allow for the various browser and other changes that occur over time.
However, with that approach comes considerable upfront and ongoing expense.
The reality is that very few smaller businesses have a unique functionality requirement.
Which means that in what I would think to be about 98% of cases, a well chosen proprietary system is going to be far more cost effective and less problematic than its open source equivalent.
This in turn means that most smaller businesses may likely be on the wrong platform.
In addition to being a leading eBusiness educator to the smaller business sector, Craig Reardon is the founder and director of independent web services firm The E Team, which was established to address the special website and web marketing needs of SMEs in Melbourne and beyond.