Usability, a question of (open source) leadership
Open source has a chance to beat Microsoft and the proprietary world at the usability game, but today it is not. What needs to change to make that a reality.
At today's Open Source Business Conference Jim Zemlin, president of the Linux Foundation, said something interesting (and hope-inducing) about open-source development. The session was on what the open source world can learn from Microsoft.
Surely, there are many things to not learn from Microsoft. Usability, however, is not one of them. Say what you want about Microsoft, but it has led the industry in lowering the bar to computing for average people. When I was in law school Microsoft used to give me free software so that it could come by my house to watch how I work. Microsoft spends considerable resources in the field to determine how people use, or could use, software.
I asked Jim to comment on how open source can match that, given that open-source communities (as opposed to open-source commercial projects) tend to be comprised of developers who may or may not have a feel for what non-developers want.
Jim suggested that it's a question of leadership. That is, within open-source projects that place a premium on usability, this trickles down within that project and eventually expands beyond to adjacent projects. He noted Ubuntu as a classic example of a project that is making usability a top priority, which is having an effect on other desktop and server Linux distributions.
I suppose this isn't all that different from the proprietary world. Microsoft is good at usability, but many of its proprietary peers are not. There is nothing inherent in proprietary software that is better than open source when it comes to usability. Rather, it's either a core cultural priority or it's not.
Importantly, there is something inherent in open source that can be better about usability than proprietary software: The users write the software for other users. There is no intermediary that processes product requirement documents to translate use cases to engineers. There are just engineers.
The trick for open source will be finding ways to bring non-developers into the conversation. I'm not sure how to accomplish this, despite spending five or six years thinking about it.