The Open Road

Walk the halls of any open-source conference and you'll see a large percentage of attendees with ironically un-open-source Apple laptops and iPhones. I've commented on the reasons for this before, but a new thought sprung to mind while reading Matthew Thomas' excellent (and old) "Why free software usability tends to suck."

Open-source advocates like good design as much as anyone, but the open-source development process is often not the best way to achieve it.

Thomas now works for Canonical, the company behind Ubuntu, which arguably offers the industry's best Linux experience for personal computers. I got a sneak peek at a future Ubuntu release while at dinner with Canonical founder Mark Shuttleworth Wednesday night, and it was gorgeous. Mac freak I may be, but the day Canonical releases that version of Ubuntu is the day my devotion to Apple will be severely tested.

Yes, it's that good.

But it's "that good" because there's a company behind it, a company dedicated to making Linux usable for average consumers. As Thomas writes,

Every contributor to the [open-source] project tries to take part in the interface design, regardless of how little they know about the subject. And once you have more than one designer, you get inconsistency, both in vision and in detail. The quality of an interface design is inversely proportional to the number of designers.

This, coupled with the fact that experienced interface designers tend to be rare in open-source projects and, even when present, "they are not heeded as much as they would be in professional projects precisely because they're dedicated designers and don't have patches to implement their suggestions," as Thomas writes, means that many open-source projects are technically brilliant...and abysmal to look at.

In the short term, proprietary products are generally going to win because they can more tightly control inputs and output and, intriguingly, it is likely that the most proprietary products will win. Why? Because in new markets, control is crucial to delivering a complete experience. Clayton Christensen, the Harvard Business School professor and author, notes:

Companies must be integrated across whatever interface drives performance along the dimension that customers value. In an industry's early days, integration typically needs to occur across interfaces that drive raw performance--for example, design and assembly. Once a product's basic performance is more than good enough, competition forces firms to compete on convenience or customization. In these situations, specialist firms emerge and the necessary locus of integration typically shifts to the interface with the customer.

Hence, Apple reigns in smartphones because it's a comparatively new market and Apple can control the complete design of the product. Microsoft and Google, on the other hand, will struggle to compete because they are only delivering software, and depend heavily on the device manufacturer. (It's likely that Apple is also exercising significant influence over AT&T and the other wireless carriers, influence that Apple's competitors likely lack.)

Against this backdrop, I wouldn't expect open source to win in new markets unless a company or other committed organization (e.g., Mozilla with Firefox) is dedicated to making it succeed. But in the long run, it's fair to expect open systems to win. As Mozilla CEO John Lilly articulated to me in response to my post "Is Apple 'open enough' to rule the next decade of mobile?":

In the long term (10 years +), I think that open systems will almost always win, because the systems will be better understood from end to end, there will be more places for individual innovations to happen, more commoditization, and [more need for] the diversity and variety of an open ecosystem.

I agree. The key, however, is learning to tweak open systems in the short term to be competitive, too, and that, I believe, requires a "cathedral+bazaar" approach to open source. It's great, for example, that Red Hat has successfully helped to commoditize the Unix operating system market, but many of us don't want to have to sit around for decades waiting for an industry to tire out, thus ripening for open-source commoditization.

We want to innovate. We want to compete. And we want it now.

For that, you need a little more than open source, it seems, to make products usable. You need control, and control doesn't always jibe well with open-source development. This is one reason that we're seeing the emergence of the Open Core licensing model for open source.

It's why I think we need a lot more such activity if we want open source to dominate new markets, and not merely clean up the scraps of old markets.

Follow me on Twitter @mjasay.

For the past few years, we've talked about the "consumerization of IT," which was a polite way of saying, "Enterprise software stinks and should be made easier to use."

I've rarely seen as concise an explanation of why enterprise software is so bad as this one by Michael Nygard on his Wide Awake Developers blog.

Nygard points to a troubling intermediation between the users of software and developers of software, offering four ways in which this is expressed:

1. "They serve their corporate overlords, not their users." This is one of the problems I have with IBM software: it seems to be written for the CIO, not the people that actually work at the CIO's company. In other words, powerful central administration with end-user ease of use is forgotten. (Not that IBM is alone in this--it's just that I'm having flashbacks right now to when I was forced to use Lotus Notes.)
2. "They only do gray-suited, stolidly conservative things." Simply put, enterprises too often get stuck in the mind-set that they employ a bunch of drones whose work consists of filling out expense reports. The real work is the creative interaction between employees, but it's the consumer Internet that has been tackling this problem, even though enterprise IT could most benefit from it.
3. "They have captive audiences." Nygard doesn't offer much explanation here, but I take it to mean that enterprise software developers can get away with foisting lame software on the world because the competitive bar is so low. "Our piece-of-junk ERP system is not quite as junky as our competition's" seems to be the winning argument.
4. "They lack 'give-a-xxxxness' ". Nygard identifies this as the most important characteristic: the love a developer has for her software and its application, and thus the time she spends making it sing. This hearkens back to the previous principles, however, in that it captures the apathy enterprise software developers may have for their products because they're writing for CIOs and cash, not users and public plaudits.

If this rings a bell, then what are we to do about it? I don't know. So long as the first order of business is security and administration, often taken to wacky extremes, rather than creativity and user-friendliness, it's unclear how anything will change.

Perhaps this is a generational shift. Just as President Obama chafed at having his BlackBerry pulled, perhaps we're entering an age where a new crop of CIOs will arise that demand that ease of use be as important as security, for example. It's not a matter of scrapping the "enterprise" in "enterprise software," but rather of shifting the argument to insist on considering enterprises as agglomerations of people, not droids.

And perhaps, just perhaps, open source can make things better by blurring the lines between developer and vendor, and developer and user. We can hope.

Follow me on Twitter at mjasay.

As I've noted before, there is more to open-source development than lines of code written, important though that activity is. There is, for example, the critical work done by Canonical, the company behind the ubiquitous Ubuntu Linux distribution, which tends to involve more ease-of-use development than core kernel development.

Canonical CEO and Ubuntu founder Mark Shuttleworth highlights this "secondary" development in an Ubuntu Open Week interview, reported by Ars Technica. Arguing that "Ubuntu and Canonical are making a very big difference in free software, and that has little to do with how many patches in the kernel have an @canonical.com e-mail address associated with them," Shuttleworth points out two key areas in which his Canonical team is improving the Linux experience:

1. Launchpad, a Web-based collaborative development platform. Launchpad breaks new ground in open-source development, and is a valuable contribution to Linux;
2. Design and usability. Canonical has been hiring usability and design experts to feed improvements to the "upstream" Linux community. It is hard to overstate how important this work could prove to be to consumer Linux adoption.

We need more than just the Linux code jockeys to make it a viable, growing community and project. In fact, we're probably at the point where these "tertiary" contributions to Linux will make a bigger difference than core Linux engineering as we seek to make Linux mainstream for consumers.

I had a very frustrating experience this morning. I decided to start editing an internal team wiki and ran into a significant roadblock: To edit the wiki, I first needed to learn "wikiml." What is wikiml? I'm glad you asked. It's a wiki markup language so that wikis look more like Web pages/documents, and not like a stream of undifferentiated text.

There's just one problem: Wikiml. Who wants to learn a markup language just so you can collaborate with colleagues? It's not that the markup language is particularly difficult (here's a cheat sheet for reference), but requiring the learning of a new language is a step backward, not forward, in terms of ease of use.

Wikis may be more powerful than a Microsoft Word document, but if they're not at least as easy, then they're simply not going to get used. Period. Google gets this: Google Docs is actually easier to use than Microsoft Word.

The Bible has this great counsel in Mark 2:27:

The Sabbath was made for man, not man for the Sabbath.

The idea is that Biblical commandments were not designed to inhibit people, but to enable and improve them. Sometimes we let the letter of a law impede the spirit and end up cramping our capabilities. Is there a correlation to software?

I'm rereading Businessweek's excellent article, "The Mac in the Gray Flannel Suit," and it became very clear why Apple is succeeding in the enterprise despite not focusing on the enterprise.

Apple has made computing pleasant.

I love my Mac. I love its look and feel. I love the software. I actually look forward to using my Mac. It's not a Dell, dude. It has class.

Another (overused) way of saying this is that Apple has "consumerized" the computing experience. As it turns out, enterprises employ consumers. Lots of them.

But it's not just Apple.

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 see articles like this one--explaining the migration of one's mom, grandma, etc. to Linux--and I can't help but believe it's proof positive that the migration in question never should have happened. If it requires an article explaining the success (or failure) of the migration, it's too difficult to bother doing.

At least this author was honest:

So, is Ubuntu Linux ready for this type of installation? Yes, provided they have someone with some Linux expertise at hand to help them.

I'm an open-source believer, but that belief does not mean that I believe open source should be used where it is a less viable solution. At some point the desktop Linux crowd is going to realize that its goals (control, primarily) don't necessarily mesh well with those of the average user (usability, primarily). This is fine. It's not cause for alarm.