Open source is a lot like sex: everything works so much better when all the participants aren’t passive.
I’ve worked on a variety of projects in the last twenty years that ranged in size from the second largest computer system in the world, to small applications used by only a few people. In this time I’ve learned that the biggest mistake you can make as a developer is to not listen to what your customers want.
However, the second biggest mistake you can make is to give your customers everything they ask for.
Marius Coomans, from a new weblog he shares with Jonathon Delacour, and which I assume is live since Marius pinged me this morning, refers to a post written by Jeffrey Veen a while back, which starts with:
Open source content management software sucks. It sucks really badly. The only things worse is every commercial CMS I’ve used. But it really doesn’t have to be that way.
Marius added the following comment:
Also interesting are the 104 comments to Jeff’s post from all the usual suspects. To me, it re-confirms that a lack of product management is a major hurdle for most open source projects. Unless an open source project simply mimics another system, it will fail either because software developers are not good judges of which features should or should not be included, while in larger projects, “too many cooks spoil the broth”.
And unlike Shelley, we don’t all have the luxury of being able to build-in the features we think we need.
(I have to say before I address either Veen’s comments, or Marius’ that I don’t agree with lumping weblogs into the same category of software as something like Blue Martini or Vignette. Doing so is like putting watermelons and cherries into the same bin and selling them as strawberries, because they all happen to have something red about them. Enterprise portal systems, large community systems, and weblogs share some similar characteristics, true; but the purpose and requirements for each differs so drastically, as to make comparison meaningless. Yes, you can use Blue Martini to write a weblog. And you can use WordPress to provide CMS capability for Boeing. However, both would be acts of a mad man,)
Focusing purely on weblogs, I’ll address Veen’s recommendations, one by one; then I’ll return to Marius comment:
Make it easy to install. Focusing on open source, the weblog tools that I’ve installed are WordPress, b2evolution, Textpattern, Nucleus, and both Blosxom and pBlosxom.
The tools for the most part were easy to install. Grab a file, unzip it, put the application where you want on your server, make sure you have a database already created, or have root permission to be able to create the database on the fly, tweak a couple of directory file permissions, and run an installation script. It’s very straightforward.
Now, let’s look at the sub-components of the installation, and see where a non-tech would run into problems.
Place the application files on the server. Most weblogs run on Linux. This is become a de facto environment, though I know there is still a lot of support for Windows products. When a software installation program talks about placing the application files into the directory where the application will reside, there is an assumption that people understand how the Linux file system works. If they don’t, this could start the worry and tension that makes the installation more difficult seeming then it is.
However, tool developers have to make some assumptions about the end users ability or the installation documents will read as follows: You need to place these files into the directory where you’ll want the application to run. If you’re server is using the Linux operating system, here’s how the file system works….
In other words, most tool developers, and rightfully so, assume that the person using their product has a minimum knowledge about how the Linux file/directory system works, including permissions, structure, and the tools to move files back and forth, such as FTP. This isn’t an excessive burden on the user–this is the part where the end user has to actively participate in the process (open source or not), by taking some time to understand some fundamentals about the environment in which they’re going to operate. Though the fundamentals are technical in nature, the understanding doesn’t require a technologist’s background: only willingness on the part of the user to make this effort.
If a weblogger wants to run their own weblogging software, this means they want to run outside the box, even if its only a tiny bit outside the box. They are, then, going to have to assume responsibility to gain a minimum amount of knowledge about their environment in order to install software and operate the software safely.
I’ve provided writings in the past, focused at the non-technologists, as has several others, about how these fundamental aspects of the environment work. In some cases, the writing has helped individuals; in others, the feedback I get is, “It’s all too complicated, and I don’t want to have to deal with it.”
Well, that’s about like lying like a lump and thinking of England during sex, isn’t it? You can’t blame your partner in the process if the act isn’t as fun as it could be, if you’re not willing to meet halfway in the effort involved.
Veen writes on this requirement:
Ask me a few questions, and then you go set up the database tables and write the conf.php or whatever. Set constraints for yourself as you design this experience: 10 minutes from download to running, never send a user to the command line, never force open a text editor. It will be hard, but you’re good at solving hard problems, and this is time very well spent.
Here are some facts of life for Mr. Veen, who assumes that open source developers could do all of this if they only tried.
First, as to writing configuration files or changing file permissions. Because of safety protocols, a tool run from a web browser cannot write to a directory unless you change the permissions of that directory first. If it could, there wouldn’t be a non-hacked site left within weblogging.
Most tools give you a choice: either change the directory permissions, or copy the following text (which they provide) into a file, name it so, and upload it using FTP to this location. This will never change! To try and work around this is to defeat the very security of the server you’re running on.
If you don’t want to take the time to figure out how to use an FTP tool, use the FTP tool’s file and directory permission changing features, and/or how to open a text editor and copy some text, perhaps you really should either look at using Blogger, Typepad, or hire someone.
Create a database first, and have the database information handy. As for the database, most of these can be created by the tools during installation, if the system is configured to allow databases to be created from the command line (which is how applications work). Most hosts disable this as a safety precaution, and ask that you use whatever control panel you’re given to create the database. So tools account for this and for the most part ask that you create the empty database first, and then the tool will create the tables and populate then with whatever data is needed. Again, this is a safety measure to keep your system from being exploited and hacked.
Bluntly, To meet Veen’s requirements would require a system that is, to all intents and purposes, completely open to any 17 year old with a malicious bent.
(Going higher, into the realm of the larger enterprise portal systems and large community systems, these should never be installed and configured by anyone less that a system administrator or someone else proficient in the underlying technology. These are large, complex, multi-purpose tools that are meant to separate the end user from the technology, yes; but they aren’t meant, for the most part, to be installed, run, and maintained by the same neophyte users. Different purposes. Different tools. Different requirements.)
Make it easy to get started. What do you mean, get started? This is different things to different people. Some people would say that they want to immediately be able to configure their profile; others want to write a post right away; and still others want to look at designs and templates and configure the look and feel of their system right away.
Most weblogging tools provide tabs or links to each of these separate areas, and let the person click through to the area and do as they wish. WordPress, when it installs, takes you to the login screen so you can login, and then takes you to the Write page, which has a form you use to write the post. The form has a space for a title, a selection of one or more categories, and then the larger space for the actual post itself. Below this is the buttons to save or publish the post, and a space to put in trackback entries.
Now, I will grant Veen that this interface brings in jargon that may intimidate the new user. For instance, what is “trackback”. However, if you click on the link to the label for this field, it takes you to a bit of documentation about trackbacks (which, unfortunately, hasn’t been documented yet in the WordPress software).
Most weblogging software, in fact, usually open with this same type of functionality, more or less. Then it’s a matter of writing something in the title, and in the text box and then pushing the button to publish the material.
Now, by default, most weblogging tools use a built-in formatting process that handles the default white space. If you want to insert special formatting characters, such as italics and bolding, you have to either use the HTML for this, or use whatever formatting tags the tools provides. But you know, if you open Word and look at how it manages italics and bolding, and then compare this to something like WordPress, you’ll find that the two operate almost exactly the same. So I am puzzled as to why Veen and others would have such trouble with this.
(As anyone who writes ‘outside the box’ with Word can tell you – it takes time to learn how to use the more sophisticated functionality in this application, as with most applications.)
This is where the activity on the part of the user comes in: if you don’t like how the default user interface of a tool operates, do you provide feedback to the tool developers? For instance, with WordPress there is a Requests and Feedback support forum for you to put in feature requests, or to provide criticism of the product. And the same applies to most of the other tools I’ve used.
I do believe that from comments associated with this requirement, that Veen is specifically addressing larger-scale CMS systems with this issue. It’s true, most of these are extremely complex to figure out how to use right out of the box. However, a rule of thumb for software, open source or not, is that the more complex the needs, the more time it takes to ramp up to speed on using the software, and the more time you need to put into reading the documentation before you use it.
So this is a second requirement on the part of the user – read the documentation. Which leads us to…
Write task-based documentation first. You’ll not get disagreement out of me on this one. I agree with this completely. In fact, most problems with applications, open source or not, could be prevented with well written and easily accessible documentation.
In fact, in some projects I’ve been on, the user documentation was written first, as part of the requirements. Needless to say, these systems also were some of the most efficiently developed and had the least problems after installation – all because the project built in time for documentation, first.
But let’s take a look at documentation in the open source world.
Those who provide documentation for open source technology rarely get commended for their efforts when the documentation is present and well organized and easily accessible. Usually the only time they get any feedback is when people say, ‘the documentation sucks”. Do users know how demoralizing this can be for technical writers?
The developer of open source software gets all sorts of kudos for providing code. They get jobs at C/Net, or get brought to the US to work at Six Apart. They’re tipped for their software, and patted on the back. Heck they even get oodles of VC money.
However, the open source documentation people rarely get a thank you from the developers, much less the users. Most people don’t know their names, and any tips they get will probably be enough to buy them a pack of chewing gum; they rarely get job offers because they documented the code.
They rarely get cooperation from the developers, either. In fact, if the documentors ask that the open source team give them a heads up on what to expect for a tool release, or how something works, they’re told, “We don’t have time to deal with this now. We’re writing code.”
This applies to every piece of open source software I have used or seen, except for some of the languages such as Perl and PHP and Python–and even they aren’t as complete as they could be (as witness hundreds of books on same).
I agree with Veen that the documentation should exist to cover all the tasks. I also ask if when he’s seen this in an open source application, whether he’s made an attempt to thank the person or persons who created the documentation. Or has the only time he’s mentioned documentation is to say it sucks.
Well, let me respond back with saying: it sucks to write open source documentation. And that’s probably why the documentation, which Veen considers so critical, doesn’t exist or only exists sporadically.
Separate the administration of the CMS from the editing and managing of content. I would say that Veen is really targeting the larger systems now, the true CMS, not weblogs. And again, from my knowledge of these systems, and their purpose, the creation of roles is to ensure that the tool is not screwed up by someone having permissions they don’t have. There is a reason to separate tasks and roles, and it’s usually to protect the users, not punish them.
I am curious about his statement:
Remember: 98 percent of your audience will be using the CMS to manage their Web sites, not manage the system. Yet most systems are optimized for the other 2 percent.
I would have to see specifics in order to understand what Veen means by ’system’ as compared to ’site’. However, in most cases of larger-purpose CMS, the system is the site, and web pages that don’t have the proper infrastructure in place to support them, don’t work.
Users of a public web site should never – never – be presented with a way to log into the CMS.
Now this is just plain silly. To say what should never exist or not is to assume that Veen can speak for all users in all circumstances, and he should never–never– do this.
In my WordPress powered installation at Burningbird, I’ve removed the line from the template that allows a person to log into the weblog. However, at the Kitchen, I’ve left this in because the system is open to all, and it makes it easy for each person to find the entry into the administrative pages.
By including this link by default, it makes it very easy for a user to decide if they want this and to remove it if they don’t. By not including it by default, then the user has to discover if this functionality exists, and then how to embed it in the template, and then how is it used.
In other words, including this in the template, as long as it’s easy to remove, is probably more user friendly than not having it.
Now, one approach I am looking at with my adaption of WordPress to Wordform is to provide a function that embeds the Login and Registration into the sidebar only if this is turned on in the administrative pages. With this, the user wouldn’t have to touch the template if they don’t want to.
However, this then requires the processing of a function call in PHP everytime the page is accessed. Though the overhead is trivial, it is overhead. I have to balance the ease to the end user (and the difficulty in removing the links), with the impact on the overall page performance. This is a case where the developer has to balance what they know of the technology and performance against what the end user wants, and make a decision about whether to meeting this requirement is truly of benefit to the end user in the long term.
These decisions don’t, unfortunately, show in an application wants it’s released–leading to people like Mr. Veen saying, (paraphrasing): open source sucks because they don’t listen to the end users.
Stop it with the jargon already. Yeah, we open source people do use jargon, such as the term ‘trackback’ mentioned earlier. And we need to learn to either provide links to definitions of the jargon, or to minimize its use when dealing with the neophyte user. Not the non-technologists, the new user. (Most non-tech webloggers know what a trackback is now.)
However, as one person commented in Veen’s post, you have to use some kind of term when referencing objects, and sometimes this term is unfamiliar to the end user.
I could use “sending a link from your weblog to another weblog, either when you write something that is tangentially to the topic, or that references the weblog entry itself, or both” instead of ‘trackback’, but this is going to make my writing quite tedious over time.
However, pushing back at the open source folks, they use jargon too much at times, and almost as a way of pushing the end user to the outside, rather than inviting them in. And I agree that this is self-defeating an arrogant.
I think in this case the end user is going to have to learn to start pushing back, by asking the developers to define terms they, the users, don’t understand. If they do this enough, the developers will probably learn how to communicate more effectively with the end users. But if the end user doesn’t make an effort to provide feedback, we’ll never know when we’ve resorted to the technical, too much. This is another case where the users can’t be passive when it comes to being the recipient, in this case of communication.
Returning to Veen again, then, if he doesn’t understand what a portlet is, he should ask. And make a statement to the developer that it would help to have a glossary of these terms with easy access, and focused at the end users and not other developers.
Why do you insist Web sites have “columns”
What does Veen suggest, then, as the default standard? Because he sees himself as the arbiter of style design, should we then follow his standards when it comes to default designs?
He mentions that he doesn’t use columns, (we assume other than his weblog, which uses columns) but most commercial store fronts use columns. Most weblog users use columns, or want columns.
However, I agree, and a hundred percent with him when he talks about design too heavily baked into the guts of the application, making it very difficult to modify. I found this with applications like Blue Martini and OsCommerce. In fact, this is the biggest complaint I’ve had with larger commercial or open source ‘one size fits all’ applications.
Not with most weblog tools, though. Weblog tools, for the most part now, use CSS and don’t use HTML tables, and have a very open template architecture. True, you have to learn the tags or function calls, but the design itself is usually fairly easy to modify–if you understand HTML and CSS.
But can the tools work beyond the person having to learn HTML and CSS? I imagine they could but there will be a cost: the more you box the capability, the harder it will be to work outside the box. In other words, if you design the application so that the user doesn’t have to touch HTML and CSS, you sacrifice how easy it is for the user to customize the site to what they want. In other words, you bake the design in, which is what Veen is bemoaning.
Bottom Line
Bottom line, Veen wants open source CMS developers to be more responsive to users, but throughout his essay, he never talks about the responsibilities of the users. Open source developers (and documenters) can’t place their heads against the screen and determine what people want and don’t want. They’re dependent on feedback, positive as well as negative, in addition to bug reporting and suggestions for enhancements in the future.
And that positive feedback is a real kicker – if the only time a developer or documenter hears from the users is when something isn’t working, eventually the people, most of whom do the effort for free, are going to get tired of working in such a ‘bad energy’ space and move on to something else–like indulging in political punditry.
Bottom line, there wasn’t anything in Veen’s ‘requirements’ that a tool developer could extract any real, useful requirement from, because those stated were too broad, and one couldn’t even determine which type of CMS, and what audience, each requirement was derived from. It becomes, then, nothing more than a rant.
Back to you Marius
Returning to Marius’ comment:
To me, it re-confirms that a lack of product management is a major hurdle for most open source projects. Unless an open source project simply mimics another system, it will fail either because software developers are not good judges of which features should or should not be included, while in larger projects, “too many cooks spoil the broth”.
And unlike Shelley, we don’t all have the luxury of being able to build-in the features we think we need.
To me, much of what Veen discusses does demonstrate a lack of formal product management; however, in the case of his requirements, I assume that much of what is missing is that the users aren’t participating equally and actively in the development process. This could very well be the fault of the developers, and if the developer is so arrogant as to disregard the users, then the software users should consider alternative software. The developer then will either adapt, or lose all their clients, and hopefully learn from the process.
However, from what I’ve seen in weblogging the last almost four years, end users themselves have to share the responsibility when it comes to lack of communication, primarily because they see themselves as only passive recipients of the software; they balk at being more actively drawn into understanding the concepts of the technology, and the constraints placed on the tool environment. “I just want to write”, they say. I can understand this and sympathize. I would also suggest using Blogger, Typepad, Bloghorn, JournURL, Live Journal, or other hosted tool. Or go with a host that installs and maintains your weblogging tool, such TextDrive, which will install and manage your Textpattern or WordPress weblog.
(In most cases, though, you still have to use either packaged templates, or learn the basics of page design to have your own custom look.)
If you want to ‘just write’ in your own hosted environment, and have your own custom look, you have to spend some time understanding this environment (or hire someone who does)–you can’t have your chocolate bar and eat it, too.
As for me having the ability to modify the WordPress application and fork into my new project, Wordform–yup, it is handy having the background to be able to do this. And when I release it for others to use (if they want to, considering that I’m just doing this for fun and to answer those critics who tell me “if you don’t like the way [fill in the blank works] write your own tool”) I hope to get lots of feedback, positive and negative, from the users, as well as feature requests and suggestions. I hope other developers, and documenters, and theme creators, might also want to contribute to the application, though I’m not actively recruiting same.
In the end though, just as with WordPress and every other open source application there is, we’ll have to balance which requests are ‘nice to have’ and which are critical to the working of the tool. We’ll have to assess the impact to the code (and how difficult it could be to maintain) of new user ‘requirements’, especially when the ‘requirements’ contradict each other. We’ll try to document how the tool works, but will need feedback from the users when the documentation is good in addition to when it ’sucks’–people are kind of funny that way.
We’ll have to assume that those installing the tool know enough about the environment to install it safely, without we developers having to create tools that leave possible security openings big enough to drive small cars through. Yes we’ll have to have a good understanding of the audience of the tool and what they need; but then the audience will have to make sure they’re using the right tool for the job.
In other words, we’re all in this bed together. If you, the end user, are not getting satisfaction, perhaps your partner isn’t the one to blame.