What open source can learn from Apple
As powerful as open source is, until it finds a way to include average users in its development processes, it will fail to crack a large number of markets that depend on usability design more than engineering design.
Open source's greatest strength may also be its Achilles' heel.
As a developer-driven phenomenon, much of the best open-source software ends up being written for other developers. For example, it's not surprising that Linux wins on the server (technical audience) but largely loses on the desktop (non-technical audience). Companies like Canonical and MindTouch can mitigate this by paying for usability design. But as an overall movement, it remains a weakness.
Apple has the opposite problem. It is religiously focused on usability, but struggles to open up to outside developers.
Even so, its attention to the user is something open source must emulate to reach the next level of adoption. Jason Snell of MacWorld writes:
Apple excels at creating products that the general public likes because the company is driven by design, not by engineering. Most tech products--heck, most products in general--aren't as good as they can be because they're put together by the people with the technical knowledge required to build them. And so the technical aspects of the product get pushed to the forefront.
The more complicated a product gets, the more technical acumen is required to put it together. Bad Web sites are built by people who know how to code HTML and JavaScript but don't understand how people use the Web. Bad software is written by people who are experts at knowing how a computer works and how to write code to make it do what they want, but no idea about how regular people behave and how those people expect to interact with that software.
Apple's the kind of company that makes decisions based on people, on users, and then challenges its engineers to find ways to fulfill those needs.
Why can't open source do this? Isn't there room in the open-source development process for the product manager, the focus group, and various other tools that software companies employ to determine what average users want and then to translate this into development plans?
The company (or project) that figures out how to do this will win.
Some projects already accomplish this to some extent. The strength of Mozilla, for example, is that it has figured out how to enable 40 percent of its development to be done by outside contributors, as BusinessWeek recently wrote. The downside is that these contributors are techies, but the upside is that they're techies who add language packs, accessibility features, and other "niche" areas that Mozilla might otherwise struggle to deliver.
This suggests a start: enable your open-source project to accept meaningful outside contributions that make the project reflective of a wider development community.
But the real goldmine is broadening the definition of "developer" to include lay users of your software. The day that I, as a nontechnical software user, can meaningfully participate in an open-source project is the day that open source will truly have won.
Until that day, don't be surprised to see Microsoft, Apple, and their ilk win most battles for the hearts and minds of common users. This is why Google comes across as naive in asking open-source developers to help it fight Microsoft on the "desktop." It's not a market developers are well-equipped to win because they're aren't reflective of the vast majority of end users.
Most people don't care how the software is written, and care even less for the supposed elegance of a given program's code. They just want the software to work in an easy-to-use manner, to look nice, and to fit their budget.
Open source does the last one better than most, but struggles at times with the first two. Fix that problem and open source will know no boundaries.
Follow me on Twitter @mjasay.