The following quote from a recent post on Jeffrey Zeldman’s blog came to mind over the weekend, when a brief exchange on Facebook threw up an interesting point of view.
Evangelizing any tool, however much one personally loves it, is like trying to convince a carnivore to go vegan. It accomplishes nothing, and leaves everyone feeling hurt.
My future career is going to feature a great deal more focus on WordPress: the most popular content management system (CMS) on the internet. Any piece of software will gain fans as development progresses and WordPress has countless thousands – if not millions – of people supporting it in different ways. But as a piece of software becomes more and more popular, it will also, in parallel, draw a lot of critics.
I’ve been a fan, a user and a developer in the WordPress community since 2004, and my investment has increased a great deal since the first Swiss WordCamp in 2014. Along the way, I’ve seen WordPress grow from a comparatively simple blogging tool into a fully-fledged CMS. As it has grown, the responsibility for improvements and forward development has been continually laid in the hands of the community. Although Automattic – the company founded by an original developer of early versions of the software – has had a leading, collaborative role in development, the power of the software comes from the ability for any developer to write a Theme or Plugin to fulfil a particular need, or even to contribute to the development of the core system.
Evangelism of a product happens when someone is a real fan. But the danger of evangelism is that it can also lead to a degree of blindness: thinking that this product is the only good solution, and that all others are “rubbish”. I’ve worked with TYPO3 for the past six years and although I’m not really a fan – because of the much lesser community spirit and because of a comparatively high entry barrier for developers – I can see that it is a good product, which serves a purpose in certain sectors.
If someone asks me for an opinion on which piece of software is best for their website, I won’t just recommend WordPress off the bat. WordPress is a great solution, it’s extensible, development continues apace, and it hasn’t been “just a blogging tool” for over a decade. But other CMS are a better solution sometimes. A large installation running dozens of sub-sites in multiple languages can be difficult to manage in WordPress, although practice proves that it’s certainly possible. Running a data-based “backend” for a web app or native app has historically been better solved with a custom API solution, although WordPress’ introduction of a REST API in December 2015 provides much simpler and wider possibilities for data management.
According to the Facebook discussion I mentioned, regular updates and new versions of themes, plugins and even the WordPress core code can, surprisingly, be a negative aspect for some users. Perhaps a user has been “burned” in the past by updating a system, which then went wrong and caused a lot of issues. Perhaps the user or client has been poorly educated at the beginning of a project, and was expecting a “finished”, one-off solution which can then run for years. This may be outmoded thinking – fuelled by I.T. providers and developers in the 1990s and 2000s – but if the client isn’t ready for a more agile approach to site management, she or he will be surprised by the need to run minor updates a few weeks after a major development process. It’s down to the project manager to explain and discuss how the project will be managed: by doing so, the up-front costs will often be reduced, in favour of an agile, rolling and more modular project.
The point is that a piece of software – especially one which is continually being improved and refined for use in the evolving web – is never “finished”. In the same way, a website is never “finished”: it should live and breathe and be updated regularly, adapting to the needs and requirements of visitors and its users. The key is that the website – and the CMS which we use to make it work – should match the needs of the client and the needs of the website visitor. Forcing a client to use a piece of software just because you’re a fan isn’t the right decision. Be open to discussion, be open to the fact that your beloved CMS might not be the right one for the project at hand, and find the solution which works for everyone.
Leave a Reply