After enjoying Ben Collins-Sussman and Brian Fitzpatrick's comments on the anti-patterns panel yesterday, I decided to peek into their "Do You Believe in the Users?" presentation. Ben and Fitz started the presentation with "Successful software requires more than just technical effort." as their premise and then went on to build on that premise.
Ben and Fitz used the analogy of meat as technical effort and sizzle as fluff or marketing around the project. Most engineers obsess about truth and use rigorous logic in their thinking, whereas marketing is slimy and to be distrusted. But, Ben and Fitz point out that it is ok to add sizzle without feeling dirty. In a lot of cases its required to have a successful open source project. They offered the example of analysts coming to the Apache Software Foundation to get the scoop on Apache software. The analysts asked the Apache folks to fill out a form about the software and they were swiftly rebuked: "Fill it out yourself!". Unlike classic organizations, which would be glad to fill out this form to have the analysts talk about their software, the Apache folks simply pointed the analysts to the documentation and said: RTFM! Obviously, if you want all walks of users to embrace your software you should make your software and your community more friendly to outsiders.
Next, they offered up the idiom of "Perception is 9/10s of the law". Perception is reality. I've personally witnessed this in open and closed source contexts and if the community thinks X about you, X is how its going to be. Even if X is wholly untrue. Open source projects must manage the perception of their project by adding the appropriate amount of sizzle. Ben and Fitz are both members of the subversion team and subversion "under promises and over delivers". This method presents a great way of managing the perception of the community, since you're not likely going to disappoint your users.
Next Ben and Fitz covered the customer service that a project must do in order to keep its users happy. While customer service is generally reviled and viewed as unprestigious, its necessary in order to keep your users happy. As the number of users of a project grows the complexity of your software grows as you add more features. Unfortunately as you attract a wider audience, the tech savviness of your users goes down. This conflict ends up in massive user frustration and must be countered with sizzle to keep your users happy.
Even if your users end up less tech savvy, don't condescend them. If you condescend your users you end up with horrible things like M$ Bob and the annoying paper clip that everyone loves to hate. Instead, let users participate in your project -- even beyond writing documentation users have found many places to participate. For instance, lots of non-coding people can help tend bug tracking systems to weed out duplicate bugs and to identify bugs that have a lot of community interest. Its obvious that fixing high community interest bugs will keep your community happy, right?
But, you can go overboard in making your users happy -- don't try to be everything to everyone. Instead, try to be most things to most people -- stay away from the edge of the bell curve to make everyone happy. Next, Ben and Fitz mentioned trust and how it takes quite a long time for a project to build trust with its community. However, one small misstep can squander the whole trust that you have built up. For instance, see my previous blog post that mentioned the XFree86 project that nearly all the Linux distros were using. Two years later, nearly no distro uses XFree86! And distros are not fast to change important things like X servers. It is all to easy to destroy your carefully earned trust, so be careful!
The last point that Ben and Fitz made about customer service is that you ought to delight your users. Google has the doodle images that change the Google logo for various occasions. These doodles elicit a lot of user response and many people are delighted and many people are dismayed by the doodles. Either way, Google engages its users quite skillfully. And on April Fools day, YouTube "Rick Rolled" all of their customers. This stunt may have cost YouTube some revenue (wait, what revenue? :-) ), but it delighted its users. Also, they mentioned another site that allows users to have user icons and in order to motivate people to change their icons, they used a picture of Dick Chaney as the default icon. They say that 95% of people immediately upload a better user picture.
The next section of their talk emphasised that projects should keep a strong user focus. Ben showed a graph of a bell curve that (jokingly) had Fitz's grandma on one end and Donald Knuth on the other and represented technical skills along the x axis. They rated the git version control system to the right (Knuth) side of the bell, saying that its users needed a fair amount of sophistication to use it. Mercurial, they felt, hit the right balance and came in at the center of the bell. Subversion was simpler and thus required even less sophistication as it came slightly to the left of the center. The key there is that the subversion team spends a fair amount of time discussing wether or not to add a top level command or to add various switches. Their overall point is that open source projects should consider their users and not continually increase the complexity of their software.
Ben and Fitz went on to talk about the speed of your software, especially in terms of web applications. Some open source applications find that user growth levels off after a while leaving the site operators puzzled as to why it leveled off. Their reasoning is that a site slows down as the number of users to the site grows, and as the site slows people start leaving. The site may have the same influx of users it did before, but with people leaving the site because of its speed the site appears to stagnate.
Finally, they spoke about hiding the complexity of software. To make their point they showed how Eudora has *29* configuration panels. An email program shouldn't really have *that* many configuration panels. They suggest hiding complexity behind abstraction layers so that most of the users are not befuddled with complexity. But, they warn that abstraction layers can be leaky, meaning that the complexity they hide can leak out from underneath the layer. The suggestion is to allow users to dive below the abstraction layer should they be inclined to do so. This saves simple users from complexity, while giving the advanced users power to get their jobs done.
A lot of the things that Ben and Fitz covered seem like they are obvious, but when you're entrenched in your open source application it can be hard to see these issues. But, in my experiences in open source software development, I see that all of their points are valid. Its really nice to have two experienced OSS hackers summarize these points -- thanks to both of you!
