Here’s a story showing the extent of complications in getting a system going, so I’ll tell it simply.
It’s my non-geek experience of work for a community newspaper that aims to produce world-class code for community papers that is singing-dancing, super-portable and open-source.
The history started in the buzz around the World Summit on Information Society which helped to move OSS into the mental horizon of non-techies like me.
When the Rhodes journalism school where I work acquired Grocott’s Mail, the local newspaper in 2004, we had to install a load of new PCs to accommodate students who would now be learning the craft in situ.
We saved $100 a PC by installing Open Office, rather than Microsoft. It added up to significant economy in a cash-poor context. But the first two years were handicapped by a network that used desktop folders for copy flow and archiving. In separate studies, a colleague Brian Garman (see relevant chapter) and an MA student Habtamu Dogu noted it was a real mess.
But creeping up alongside the chaos of no version control and unintended triple sub-editing of identical stories, serious research was taking place into Content Management Systems in African newsrooms. This fact-finding, led by me, and carried out by 10 MA students, was published as What the newsroom knows. It was funded by the FreeVoice foundation, and the study identified a huge gap in cheap, efficient systems that would suit small-scale publications.
But there were hitches. The system had some bugs, was not fully OSS, and some users complained about having the wordprocessing functions and clumsy cut-and-paste components. The automated web-publishing side shovelled content online which really needed human intervention.
There was work to be done. Christened “Nika”, the isiXhosa verb “to give”, we began further work on a new version. First stop was the work flow system. Then we would work on the web side, and in mobile thereafter.
Later, these other two components were dubbed “Thatha” (meaning, “to take” – i.e. from the workflow onto the web), and “Thumela” (“to send”).
The vision was a generic suite that would be a CMS in a box, available free to small newspapers all over Africa. Grocott’s Mail would be a test bed.
So far, so good. I even understood some the many dimensions of a CMS in the expanded sense, and gave
on it in Kampala in 2008. Things looked excellent when we won a Knight Challenge which would cover the costs of a state-of-the-art package that would include incredible integration with mobile. Our project was called Iindaba Ziyafika – the news is coming.
But more learning was to take place. Not about sexy software, but about the complex people and processes who create it. Because from the first iteration in 2005 up till mid-2008, little progress was recorded. The development process seemed never-ending.
This is what I found:
- Geeky people can get bored very quickly. They don’t like to redo systems just to make them OS compliant.
- When you work with informal developers, you run the risk of having your server stolen (yes it happened!) and no back up available. This killed our 2nd version which was used to produce a follow-up to the xanni multiple-media site.
- A generic system (the idea of the “general” that can be applied to the “particular”) is less viable than a customised one (which could move from one “particular” version – which can then be re-particularised by others with a bit of tweaking).
- Trying to get the full Monty coding for a single big bang product does not work.
Enter Rhodes computing professor, Peter Wentworth, who came on board in 2008 to help us. He advocates iterative development. You do a bit, then implement, revise if need be; add a bit, implement; ad infinitum.
That’s exactly what he did – working slowly, but consistently, with Grocott’s. The result, the Nika workflow system finally got on the road in mid-2008. Documentation about this is available at: http://netserv.ict.ru.ac.za/tracs/nikatrac
It looked like this:
The lesson after all that time is: don’t try to build the perfect mega-system, because it likely will never happen. With tons of specs (and in a changing environment!), you are creating an infinite task where developers just keep adding and adding … and meanwhile you as client grow long in the teeth waiting for the product.
Instead, you get results by getting something small going, which you keep modifying and adding to.
Another advantage of the trickle-based model (ironically called Extreme Programming I am told!), is that it gives time for the users to absorb and implement. This is something that Dutch academic Peter Verweij wrote about regarding our work.
Even then, you can risk going too fast. An interface between Nika and Gallery software for photographs is still to be properly taken up by the busy people at the Grocott’s Mail. As a result, the picture archiving on the newspaper lags behind the funky Nika workflow.
Whether the paper actually goes for an integration of Scribus for page layout, is unclear. It might just make sense to keep on using Adobe InDesign as a proprietary software stand-alone next to Nika. (There is some discussion on articulation here at the Drupal site.)
Along with punting the iterative approach, Wentworth is an evangelist for development-by-story-telling. (Funny thing that – I thought journalists had a monopoly here!) According to this, you tell a programmer an anecdotal story about “what will happen when”, and the magician then conjures up the code to supply the “how”.
There’s another lesson Wentworth taught me too. Somewhat romantically, I had hoped that the drupal.org site with its many plug-ins would be of value. Why reinvent what global geeks have contributed to general knowledge stock? But the good prof reported that several of the relevant plug-ins on the site appeared to have either been abandoned, not been upgraded to Drupal 6, or were still in intermediate stages. The result was that we turned to Kannel for part of the mobile development.
A lot still remains to be done. We now have Thumela (in basic version) talking to Nika, meaning that we have software (two-way SMS) that integrates with workflow.
The Thatha system (the web component being completed by student Dale Tristram with support from Wentworth) is finally near implementation (est.launch April).
It should articulate nicely with its two sister dimensions. There are interesting lessons here in relation to developing Grocott’s digital strategy more broadly – that’s the subject of a future post!
From April, the vision is to take forward all three interacting legs (Nika, Thatha, Thumela) into holding hands with new Grocott’s realms – like a .mobi site and various downloadable applications for cellphones.
Come this September’s 13th Highway Africa conference, serving African journalists who get excited about ICT, there should be some great software to show off … and give out.