Avoiding the Fourth Kind

by Cord Blomquist on March 3, 2010 · View Comments

in Web-Based Applications

Software can be intuitive and blessedly easy or it can require expertise and training. Software can be free or can be sold at a price. If you were to categorize the entire world of software by these two dimensions—easy vs. hard and free vs. paid—you’d notice that all the software you’ve grown to hate is at the nexus of difficult and expensive.  That type of software is the dreaded fourth kind.

What are the four kinds of software according to this model?  Here’s how they shake out:

Free Services (1st kind) - This group includes Google Docs, Flickr, WordPress.com, Blogger, SquareSpace, and even things we take for granted like YouTube, Facebook, Twitter, Google itself.  Free and easy-to-use services have massive communities, often numbering into the tens of millions of users.  Because these services rely usually rely on advertising revenue and therefore seek the largest user-base possible they drift toward open standards and free flow of data in order to attract increasingly large audiences.

Paid Services (2nd kind) - This group includes premium versions of the former group like Google Apps, WordPress VIP Hosting, SalesForce, BaseCamp, and HighRise.  These services often benefits from the large user base of their free counterparts.  Companies embracing a “Freemium” model leverage the rapid feedback and massive test-bed provided by their free service’s audience to quickly improve their paid offering.  Customers pay for these otherwise free services because the paid version offers more features, more storage, more contacts, more emails, more projects, or more of something else.  Open standards are embraced here as well as customers are reluctant to send their data down any “one-way streets.”

Free Open-Source Software (3rd kind) - This group includes CMS systems like WordPress’s self-hosted version, Drupal, Joomla as well as desktop software like HandBrake or Audacity.  These software titles are free, but the technical expertise required to use them means that users will still be investing a great deal of their time.  Users typically move down from the easy/free square to the hard/free square because they’re looking for more control and ability to customize their software.  Open standards rule here as well as customers are also the creators/coders of this software, removing the incentive to create lock-ins.  Most successful open-source communities begin with open standards, as it’s easier to attract users to system that don’t trap data—again, avoiding any “one-way streets.”

Paid, Proprietary Software (4th kind) – This group includes Microsoft Exchange email, Microsoft Access, or that proprietary CMS system your company uses that no one else seems to use.  Though some of these products are widely used—namely those that grew-up during the PC era—those that face well-organized open-source rivals often have comparatively smaller user-bases as barriers to entry are very high here.  Though these products are often marketed as highly powerful and customizable, their comparatively tiny user-bases and closed code limit their extendability.  These products tend not to favor open standards and are reluctant to make data transfers easy as data lock-in remains a cornerstone of their business model.

This analysis shows that free isn’t always better than paid and easy isn’t always better than difficult to use—trade-offs can be made to find better overall products.  However, when products are both difficult to use and expensive the same trade-off logic often ceases to apply.  These hard/paid applications limit their user bases and therefore suffer from a lack of feedback, outside contribution, and innovation.

This thinking is counter-intuitive to many who believe that expensive and complex things are always superior despite the reverse often being true.  For example, my father once owned a Rolls Royce, an expensive and very convoluted  automobile. One of its supposed luxury features was an hydraulic leveling system that kept the car perfectly level even if a heavy package (or person) occupied one of the seats.  The system shifted fluid around the leveling system providing more pressure to the weighed-down corner, keeping the car level.  Unfortunately, the same system that ran the leveler also provided hydraulic pressure to the brakes, meaning that when the leveler stopped working, the brakes often stopped working as well.  This is when a Honda begins to seem appealing.

Software applications can be a lot like the Rolls Royce, seemingly luxurious, but also incredibly convoluted and prone to system-wide failure.  Simple software is less prone to these sorts of drawbacks and is often better in terms of its user experience and overall effectiveness at doing its jobs, much like how Honda’s are actually much more pleasant to drive than a Rolls Royce—think “school bus.”

So, avoid the dreaded fourth kind and keep your software straight-forward, open, and effective.

Share Print Email This Post

blog comments powered by Disqus

Previous post:

Next post: