interGen loves Joomla! We of course hear about Wordpress all the time. We have been supporting a large number of Wordpress sites for years. There is a lot to like about Wordpress, mostly its marketshare. From time to time it is helpful to talk a little about why we love Joomla so much.
Before we get to the really good stuff, it is helpful to acknowledge what Jooma is not.
Joomla is NOT:
One of my least favorite things in the whole world is "vendor lock in." If I am not happy with one of our service providers I want to be able to leave without losing the hard work that our team has put into creating and maintaining our information. If you are "locked in," you not only have pain of bad solutions, you also have to give up all the time and energy you invested in a proprietary solution that someone else owns. You usually have to just start over.
The idea of vendor lock-in is why some of the biggest names in technology like Microsoft, Adobe, and Apple have struggled (more or less) to compete against open source solutions (discussed below) in the website development space. Microsoft and Adobe still have offerings for website creation, but they represent a tiny sliver of online web sites. The world is getting smarter.
Is there any reason to think that websites created with Adobe Muse (update Muse is EOL) and Microsoft Sharepoint won't end up the same way that those created with Adobe Flash, Microsoft Frontpage, and Apple's iWeb did?
These companies change their minds and abandon their products with little thought to the impact on existing customers. So not only are you locked in, but you are left without support when the company changes course. Ask any organization with a web application built in Microsoft's ActiveX how things are going. These online applications were only ever accessible through Internet Explorer. It is the only browser that supports these applications and even Microsoft has replaced that with its newer Edge Browser. Of course even Edge can't access ActiveX web applications. Any project built in ActiveX is a lost cause. You get to start over.
When you want to share information and move it between platforms, standards matter. Private companies cooking up their own tools and then hiding the code that makes those tools work is a recipe for disappointment.
There are a host of new companies providing Web Development as a Service (WDaaS?). They include companies like Wix and Squarespace. We could also include the sitebuilders from Godaddy and other web hosts. The idea is to provide easy to use tools to create your own site without having to know any code. For some organizations this might be a good solution with several important caveats.
- If and when you outgrow the solution you will have to leave a lot of your work behind. Some of these platforms have basic export tools or you can copy and paste text and grab images. Beyond that everything else that makes up your site in these solutions is locked behind their special software to which there is no direct access. You will have to recreate everything in whatever new solution you choose.
- If you want some feature or function that these build-it-yourself tools don't provide, you are out of luck. At best you can link to some other third party tool that won't be part of your website. Again, the code for how the tools work is not available to you. So if the tool doesn't provide the features you want, there is no way to add them. When you reach this realization refer to point #1 above.
- It can be difficult finding web developers to support these solutions. Because of the limitations above, developers are often reluctant to support these solutions. Too soon they will have to start saying "no" to questions about why your website can't do X or Y. If they recommended the solution, they look bad for backing you into this corner. In addtion, the tools are supposed to be so easy to use that you don't need a professional. For many this is a huge feature. When you hit a problem that you aren't sure how to fix, it feels like a liabilty pretty quickly.
There are some incredibly talented developers working for small independant firms. They are often aware of the liabilites of the proprietary closed solutions menitoned above. In response they will develop their own custom, open solution. For those developers this can solve some important problems. They have access to all the code. Changes and features are only limited by the skill of the developer and the resources (time and money) available.
From the client's perspective, even if the code is openly available (it often is) it can be hard finding someone else to support it. If you aren't happy using a custom solution only supported by one company it can create just as much lock-in as the solutions mentioned above. Also the number of sites deployed on the homecooked solution is limited by the total number of clients that a particular company has. It creates a very small user base against which to address security issues. A smaller firm may not have the resources to identify and address significant security concerns. Larger open platforms also deal with security issues, but there are tens of thousands of developers invested in securing millions of websites against these threats. A small firm might have a handful of developers that might not be well versed in staying up to date on the latest ways a site could be exploited.