Max Cutler

Every­one seems to want to cre­ate the next pop­u­lar CMS. Whether it’s for blog­ging, brochure­ware, e-commerce, or news, there’s no short­age of peo­ple look­ing to build the next big thing. I admit to being one of those peo­ple. But as I’ve been doing mar­ket research and com­pet­i­tive analy­sis for the bet­ter part of 9 months now, one thing has struck me in par­tic­u­lar: most of these peo­ple do not truly under­stand why soft­ware like Word­Press and Dru­pal have suc­ceeded, and thus go down roads towards medi­oc­rity and obscurity.

(Note: This post is writ­ten from my per­spec­tive as the lead devel­oper at a news orga­ni­za­tion, and only sec­on­dar­ily from my posi­tion as one of the leads of a news CMS project.)

Per­haps the fun­da­men­tal prob­lem is that open source soft­ware is gen­er­ally built to scratch one’s own itch. The beauty of the OSS model is that it allows other peo­ple with the same itch to join your effort and not rein­vent the wheel.  The poten­tial down­side is that your itch is likely not exactly the same as my itch, and if I build the soft­ware just how I need it, it will likely not be as ideal for you as it is for me. There’s noth­ing wrong with me build­ing some­thing to scratch my own itch, that’s my pre­rog­a­tive as a soft­ware devel­oper. But if I want you and other peo­ple to use or con­tribute to my soft­ware project, I’m going to have to take your needs into consideration.

The Approaches

How is this achieved? One way is the low­est com­mon denom­i­na­tor (LCD) approach, where we fig­ure out what require­ments we both share, and then just build those. Maybe I need some extra things, and you need some dif­fer­ent set of extra things, but we build to the LCD and then we can pri­vately add the fea­tures that only we need. This is often achieved through a plug-in or exten­sion sys­tem, where the base soft­ware has a num­ber of hooks and entry points for exter­nal code to plug into. Word­Press works on a model like this, and it has devel­oped an enor­mous plug-in ecosys­tem where peo­ple share their exten­sions for the ben­e­fit of the community.

Another way is to build a sys­tem around a set of generic tools, upon which you can build what­ever func­tion­al­ity you need. Sys­tems like Dru­pal with its CCK fall into this cat­e­gory, where you have a few basic generic con­tent types upon which all the other mod­ules can be built. This can be an extra­or­di­nar­ily pow­er­ful sys­tem, allow­ing users to build almost what­ever they want from these basic build­ing blocks. Sure, it might take some more effort than if every­thing was pre-assembled like in Word­Press, but once it’s all set up it, it is exactly what you want it to be.

Yet another approach is to build “opin­ion­ated” soft­ware. The lead­ers of the project devise some phi­los­o­phy or vision around which the prod­uct is built, and if that vision doesn’t align with a par­tic­u­lar user’s, then that user can live with it or go find another piece of soft­ware that does. Such soft­ware is often of excel­lent qual­ity and does exactly what the lead­ers envi­sion, but at the expense of build­ing some­thing that is applic­a­ble to a much wider audience.

The Prob­lem

Each of these approaches have their own pros and cons, which have been dis­cussed to death else­where and which I don’t wish to rehash here.  Instead, I want to look at how I feel cre­ators of var­i­ous news CMSes are fail­ing their audi­ences, or at least not liv­ing up to their potential.

I have no desire to pub­licly bash any one project in par­tic­u­lar, because I do not think that that helps any­one, and there are hon­estly too many projects for me to cover in a sin­gle blog post. But there are a num­ber of projects with siz­able teams behind them, and with either fund­ing or pro­fes­sional back­ing, and it sad­dens me to see them fol­low the tra­jec­to­ries they are on.

I under­stand that news orga­ni­za­tions come in all shapes and sizes. There are daily and weekly papers, mag­a­zines, online-only, blogs, etc, etc. Each of these has slightly dif­fer­ent needs and work­flows. Per­haps each of them needs their own toolsets, or per­haps they sim­ply need to adapt.

My prob­lem is that I think it is myopic and bor­der­line arro­gant for teams to build a piece of soft­ware for their par­tic­u­lar orga­ni­za­tion and then mar­ket it to the rest of the world as a generic prod­uct. Some projects even delude them­selves into believ­ing they are build­ing a generic prod­uct, only to con­tinue build­ing it to their own set of needs. There’s noth­ing wrong with build­ing a CMS for your news orga­ni­za­tion; tons of col­lege news orga­ni­za­tions have done so, and are more than happy with the results.

But if you aren’t build­ing in con­sid­er­a­tions for how other orga­ni­za­tions oper­ate and might need to cus­tomize your sys­tem, then you are on the wrong road. When I see HTML snip­pets for ren­der­ing bits of con­tent buried in code, it makes me want to weep. Because I know that if I tried to use that sys­tem for my news orga­ni­za­tion, I would be unable to con­trol that aspect of the out­put with­out fork­ing the project and using a cus­tomized ver­sion of the code­base. When I see a hard-coded work­flow sys­tem, I won­der whether that can really fit the work­flow of my news orga­ni­za­tion; whether I will need to rip it apart to bend it to my will, or else force my edi­to­r­ial staff to change their ways. When I see the set of fields on the article/story con­tent type, and real­ize that they are miss­ing some­thing cru­cial to my news organization’s needs, I won­der how much work it will take to add what I need and whether that will break the rest of the system.

The Solu­tion

It is all too easy to start and design a project with noble inten­tions and then get derailed as you actu­ally build the prod­uct. Ide­ally, the team already con­sists of indi­vid­u­als from var­ied back­grounds, who can explain how orga­ni­za­tions they have worked with/for would want to use the soft­ware. This is a great start, and can lead to a healthy design process.

When you actu­ally start writ­ing code, you need to be build­ing mul­ti­ple projects that use it simul­ta­ne­ously. Only by actu­ally using the code to cre­ate some­thing can you dis­cover the short­com­ings and prob­lems. And by build­ing mul­ti­ple, dif­fer­ent projects on top of your plat­form, you begin to see how dif­fer­ent orga­ni­za­tions have dif­fer­ent needs and how you can adapt your plat­form to meet these var­ied require­ments. The same per­son shouldn’t be doing mul­ti­ple projects, how­ever, you need mul­ti­ple peo­ple with var­ied back­grounds mak­ing dif­fer­ent projects across the full spec­trum of your tar­get mar­ket. Oth­er­wise, you can too eas­ily fall into the trap of cre­at­ing opin­ion­ated soft­ware that meets the needs of that sin­gle sam­ple project.

If you really want a generic plat­form with a solid com­mu­nity, there has to be con­sid­er­a­tion given to extend­ing your prod­uct and using it in con­junc­tion with other soft­ware. Many news CMSes are being built on Django, which is appro­pri­ate given its gen­e­sis, and which also has a strong move­ment for “reusable apps.” There’s quite a large col­lec­tion 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 orthog­o­nal “plug-ins” of sorts, but can also act as a way for users to cus­tomize a CMS by over­rid­ing or enhanc­ing cer­tain bits of built-in func­tion­al­ity. If your arti­cle han­dling isn’t quite what I need, allow me to write my own and have your code use my exten­sion. That’s fric­tion­less soft­ware, and that lets me do my job. Sen­si­ble, com­pre­hen­sive ways to build on your plat­form are a must. Ulti­mately your CMS should be act­ing as a plat­form or frame­work for me to build my news site on, so give me the power to build it to my requirements.

Con­clu­sion

There’s cer­tainly a place for opin­ion­ated soft­ware in the news CMS domain, and some orga­ni­za­tions may want or need to cre­ate their own solu­tions. But if your aim is to build a plat­form for other orga­ni­za­tions to adopt, and you haven’t thought about how they can bend it to their will with­out fork­ing the project, then you’ve failed at your task in a pretty fun­da­men­tal way. If I can’t get what I need from your soft­ware with min­i­mal fric­tion, I’ll move on and find some­thing else. News orga­ni­za­tions need to focus on the news and the jour­nal­ism, and per­haps on exper­i­ment­ing with new tech­nol­ogy. Your soft­ware shouldn’t be get­ting in their way at all, and should actu­ally be mak­ing it even eas­ier to do their job as they want to do it.

All I’m ask­ing is for you to have an open mind. Find some­one at another orga­ni­za­tion and have them look at your project and see how well it would fit their needs. See all the lit­tle things that don’t quite align, and find ways to remove such fric­tion. Because all the lit­tle details mat­ter as much as (if not more than) the high-level con­cep­tual ones. CMSes should be enablers, please get them out of my way and let me do what my news orga­ni­za­tions wants it to do.