Everyone seems to want to create the next popular CMS. Whether it’s for blogging, brochureware, e-commerce, or news, there’s no shortage of people looking to build the next big thing. I admit to being one of those people. But as I’ve been doing market research and competitive analysis for the better part of 9 months now, one thing has struck me in particular: most of these people do not truly understand why software like WordPress and Drupal have succeeded, and thus go down roads towards mediocrity and obscurity.
(Note: This post is written from my perspective as the lead developer at a news organization, and only secondarily from my position as one of the leads of a news CMS project.)
Perhaps the fundamental problem is that open source software is generally built to scratch one’s own itch. The beauty of the OSS model is that it allows other people with the same itch to join your effort and not reinvent the wheel. The potential downside is that your itch is likely not exactly the same as my itch, and if I build the software just how I need it, it will likely not be as ideal for you as it is for me. There’s nothing wrong with me building something to scratch my own itch, that’s my prerogative as a software developer. But if I want you and other people to use or contribute to my software project, I’m going to have to take your needs into consideration.
How is this achieved? One way is the lowest common denominator (LCD) approach, where we figure out what requirements we both share, and then just build those. Maybe I need some extra things, and you need some different set of extra things, but we build to the LCD and then we can privately add the features that only we need. This is often achieved through a plug-in or extension system, where the base software has a number of hooks and entry points for external code to plug into. WordPress works on a model like this, and it has developed an enormous plug-in ecosystem where people share their extensions for the benefit of the community.
Another way is to build a system around a set of generic tools, upon which you can build whatever functionality you need. Systems like Drupal with its CCK fall into this category, where you have a few basic generic content types upon which all the other modules can be built. This can be an extraordinarily powerful system, allowing users to build almost whatever they want from these basic building blocks. Sure, it might take some more effort than if everything was pre-assembled like in WordPress, but once it’s all set up it, it is exactly what you want it to be.
Yet another approach is to build “opinionated” software. The leaders of the project devise some philosophy or vision around which the product is built, and if that vision doesn’t align with a particular user’s, then that user can live with it or go find another piece of software that does. Such software is often of excellent quality and does exactly what the leaders envision, but at the expense of building something that is applicable to a much wider audience.
Each of these approaches have their own pros and cons, which have been discussed to death elsewhere and which I don’t wish to rehash here. Instead, I want to look at how I feel creators of various news CMSes are failing their audiences, or at least not living up to their potential.
I have no desire to publicly bash any one project in particular, because I do not think that that helps anyone, and there are honestly too many projects for me to cover in a single blog post. But there are a number of projects with sizable teams behind them, and with either funding or professional backing, and it saddens me to see them follow the trajectories they are on.
I understand that news organizations come in all shapes and sizes. There are daily and weekly papers, magazines, online-only, blogs, etc, etc. Each of these has slightly different needs and workflows. Perhaps each of them needs their own toolsets, or perhaps they simply need to adapt.
My problem is that I think it is myopic and borderline arrogant for teams to build a piece of software for their particular organization and then market it to the rest of the world as a generic product. Some projects even delude themselves into believing they are building a generic product, only to continue building it to their own set of needs. There’s nothing wrong with building a CMS for your news organization; tons of college news organizations have done so, and are more than happy with the results.
But if you aren’t building in considerations for how other organizations operate and might need to customize your system, then you are on the wrong road. When I see HTML snippets for rendering bits of content buried in code, it makes me want to weep. Because I know that if I tried to use that system for my news organization, I would be unable to control that aspect of the output without forking the project and using a customized version of the codebase. When I see a hard-coded workflow system, I wonder whether that can really fit the workflow of my news organization; whether I will need to rip it apart to bend it to my will, or else force my editorial staff to change their ways. When I see the set of fields on the article/story content type, and realize that they are missing something crucial to my news organization’s needs, I wonder how much work it will take to add what I need and whether that will break the rest of the system.
It is all too easy to start and design a project with noble intentions and then get derailed as you actually build the product. Ideally, the team already consists of individuals from varied backgrounds, who can explain how organizations they have worked with/for would want to use the software. This is a great start, and can lead to a healthy design process.
When you actually start writing code, you need to be building multiple projects that use it simultaneously. Only by actually using the code to create something can you discover the shortcomings and problems. And by building multiple, different projects on top of your platform, you begin to see how different organizations have different needs and how you can adapt your platform to meet these varied requirements. The same person shouldn’t be doing multiple projects, however, you need multiple people with varied backgrounds making different projects across the full spectrum of your target market. Otherwise, you can too easily fall into the trap of creating opinionated software that meets the needs of that single sample project.
If you really want a generic platform with a solid community, there has to be consideration given to extending your product and using it in conjunction with other software. Many news CMSes are being built on Django, which is appropriate given its genesis, and which also has a strong movement for “reusable apps.” There’s quite a large collection of 3rd party reusable Django apps out on Google Code, Github, and other sites, and any CMS should be built so as to allow for use of 3rd party apps. They can act as orthogonal “plug-ins” of sorts, but can also act as a way for users to customize a CMS by overriding or enhancing certain bits of built-in functionality. If your article handling isn’t quite what I need, allow me to write my own and have your code use my extension. That’s frictionless software, and that lets me do my job. Sensible, comprehensive ways to build on your platform are a must. Ultimately your CMS should be acting as a platform or framework for me to build my news site on, so give me the power to build it to my requirements.
There’s certainly a place for opinionated software in the news CMS domain, and some organizations may want or need to create their own solutions. But if your aim is to build a platform for other organizations to adopt, and you haven’t thought about how they can bend it to their will without forking the project, then you’ve failed at your task in a pretty fundamental way. If I can’t get what I need from your software with minimal friction, I’ll move on and find something else. News organizations need to focus on the news and the journalism, and perhaps on experimenting with new technology. Your software shouldn’t be getting in their way at all, and should actually be making it even easier to do their job as they want to do it.
All I’m asking is for you to have an open mind. Find someone at another organization and have them look at your project and see how well it would fit their needs. See all the little things that don’t quite align, and find ways to remove such friction. Because all the little details matter as much as (if not more than) the high-level conceptual ones. CMSes should be enablers, please get them out of my way and let me do what my news organizations wants it to do.