Randall Kennedy’s blog at InfoWorld writes:

“Matthew Paul Thomas – a long-time critic of FOSS user interfaces in general, and Linux in particular – lamenting the lack of usability in FOSS projects.”

Here’s Matthew’s list of 15 reasons why FOSS projects lack usability:

  1. Weak incentives for usability
  2. Few good designers
  3. Design suggestions often aren’t invited or welcomed
  4. Usability is hard to measure
  5. Coding before design
  6. Too many cooks
  7. Chasing tail-lights
  8. Scratching their own itch
  9. Leaving little things broken
  10. Placating people with options
  11. Fifteen pixels of fame
  12. Design is high-bandwidth, the Net is low-bandwidth
  13. Release early, release often, get stuck
  14. Mediocrity through modularity
  15. Gated development communities

I’d urge you to read Matthew’s original post as it offers ideas on how to address the usability issues he raises.

For the set of open source projects that are truly developer driven, and don’t rely on a vendor with profit motives, some, or all of Matthew’s list could apply.  But how many of us truly interact with software from this category?  However, even in this case, examples such as Mozilla, as Matthew points out, make use of usability and design experts.

For the vast majority of open source products that you and I use, there is a vendor or group of vendors behind the related open source project.  As such, usability and design experts employed by the vendor behind the open source product are able to impact the final product.  Scratching an itch, placating people with options and leaving little things broken aren’t encouraged when there is revenue on the table and you’re being paid to work on a product.  In a vendor sponsored open source project, the 15 reasons that Matthew lists could probably be applied equally for closed source and open source products.

However, some vendor-backed open source projects started out as a group of developers scratching an itch.  Could these projects suffer from Matthew’s list of 15?  Adding vendor backing to the project could address future design issues, but some issues would simply be carried forward with every release.  Maybe this is more relevant to established open source products/vendors.  Vendors behind new (i.e. past 2-5 yrs?) OSS products simply leveraged the open source business model but employed designers etc from day one.

I’m torn. I could argue that Matthew is wholly off the mark for vendor-backed projects, or that he may be on to something (because of how these projects were first created).

What do you think?