The Linux Desktop is Dead

ESR's rant is, surprise, surprise, making waves. Mostly unhappy ones that can be best summerized as STFU.

However, ESR is right.

I switched over to Windows as my primary desktop operating system in 2001 when I moved over to marketing. There were simply too many tools that I needed to use which weren't available under FreeBSD (desktop de jour at the time) or Linux. It was the first time that I had seriously used a non-Unix desktop since 1993 and I had to admit - I was surprised. Windows 2000 was stable, things just worked, and life was all around good. After a few weeks I noticed that I spent a lot less time managing my desktop and that above all else made me change my home machine over to Windows as well.

I still use Linux and FreeBSD. I just use them as servers and ssh into them as necessary. From time to time I take a peak at what the folks over at GNOME and KDE are up to, but to date I just haven't been all that impressed. As far as I'm concerned, the Linux on the Desktop effort is dead. Anyone that hungry for a Unix machine with a usable GUI environment is now buying a Mac.

In early editions of my book, Linux Administration: A Beginners Guide, I wrote something along the lines of "one of the great things about Linux is that it gives you the choice." I've since spent a lot of time caring about end user interfaces, being a user, and watching customers use my products, and I've come to the conclusion that unless you care about the technology itself, you really don't care about the choice. What the user cares about is the choice in whatever task they are trying to accomplish and if the action is passive (e.g., seeing a silly video on Youtube), then a choice doesn't matter. It just has to work. My dad is the perfect example of this: he just wants to see CNN's web site. He can click on the Firefox logo and he can click on the the Internet Explorer logo. But that choice doesn't matter to him -- he wants to choose what news he reads instead of sitting through 30 minutes of CBS.

If the Linux community wants to revive its effort for the desktop, it has to come to terms with the reality that my dad doesn't care he can choose between KDE and GNOME, or Firefox and Konqueror, or KWord and OpenOffice. He just wants to click on the 'W' logo and have something pop up that lets him get the job done.

Random Aside: No, I'm Not Linux!

Most of the Mac vs. PC parodies going around are ho-hum. This series has proven to be pretty funny. This video in particular sums up the Mac, PC, Linux, BSD relationship quite well. (Audio is not safe for work.)

Free Coffee

At one point in time, my Dad had more than a handful of people reporting to him. (Let's put some scope on this... he led project management for multi-billion dollar construction projects.) As a result, he managed non-trivial budgets.

An auditor once gave him a hard time about some of his line items. Free coffee for his floor? A copy machine with auditing turned off? No reports for fax machine usage? My word! My Dad is bleeding money! On a public project no less!

My Dad asked the auditor how much he thought was spent over 1 year of these frills. "Guess," he asked. "At least a few thousand dollars a year," the auditor responded. "Single digit thousands?" my Dad asked back. "Year. Probably."

At this point my Dad showed his staff turnover rate. "Compare this to the other departments and their corresponding HR chargebacks," my Dad challenged. The auditor had admit, my Dad’s chargebacks were considerably lower than other departments. "That's me not paying for recruiting fees," my Dad explained.

My Dad continued: "Now, would you say that telling my employees that I trust them enough with free coffee and audit-free copy machines is a much better deal for the state than paying for HR chargebacks? My team is happy with the place they work and the state saves money. Seems like a win-win to me. What do you thing?"

My Dad passed his audit. And the coffee remained free.

Not too long ago, I was looking into published numbers on stolen laptops. Usually, there is some degree of variability in things like this depending on who gets asked, when they are asked, and how they are expected to count the numbers. What struck me about the numbers around stolen laptops was the remarkable amount of consistency. It was almost like they were all citing the same source...

Following the trail, I found the source. A press release by a major end point security vendor for a study they commissioned by a one man research company. Yup, an entire industry forming around one person's unverified commissioned research. It was like the same group of bad ideas were circulating around and everyone just started writing about it.

Absurd, but at least the outcome pushed for better security of laptops. For a person making a business decision, check the numbers twice. For a person trying to advocate getting appropriate security for laptops (that should be there anyway) done, cite away.

Unfortunately, this same trend made its way around to recommendations for reimbursing mobile devices: don't pay for it all, those end users are making personal calls with it! I saw this recommendation in no less than three publications and my previous employer instituted the policy last year.

This is absurd. In case you're wondering why your employees hang Dilbert comic strips up, own calendars from Despair, Inc., and know all the lines from the movie Office Space, it's because of short sighted policies like this.

We ask our teams to be on call off hours. We want them to be on 5am conference calls in order to facilitate a global market. We want them to answer email in the evening. We want them to go above the call of duty. But we can't fork over an extra $30 a month for an employee's phone bill? The phone that they mostly use so they can do 5am conference calls and jump on weekend emergencies? Please.

"But the budget," I hear, "we can't be going around wasting money on calls that aren't work related!"

Fine. Can't stand to go above the call of duty for your employees when they go above the call of duty for you? Why not just hire another employee so you don't have to make employees go above the call of duty in the first place? They don't owe you. You don't owe them.

Oh right... That's because coughing up another headcount is far more expensive then coughing up a few bucks for a cell phone. So please... To all the CFOs out there – quit being a cheap ass and pay for the bill. Really. In the grand scheme of things, you're coming out ahead.

IM-Speech in Writing

With another post getting a bit long in the tooth, I thought I'd at least get this off my mind...

Students using IM-chat lingo in schoolwork is becoming increasingly common. I'm not entirely surprised as I was guilty of BBS-speak leaking into my schoolwork many moons ago. Fortunately, my teachers killed that problem early, quickly, and with a ferocity that took me years to appreciate.

What surprises me are the number of college educated adults that use IM-speak in emails. This trend isn't limited to techno-heads (programmers, etc.) that could argue Hungarian notation made them do it, but from executives that make their living by being communicators! The resulting emails are often painful to read, full of ambiguous statements ("ur"), and all around unprofessional.

So a call to the small handful of readers that I do have -- help me squash this trend. Really, I don't think Wyeth (the makers of Advil) produce enough pain relievers in a year to read many more of these emails.

Skunk Works and Startups

I had an argument.

Not the logical kind, mind you. No, no, no... Those take thought and require that I actually care about the outcome. Rather, this was the irrational kind where you know you're not going to change the other person's mind. You see, those are fun from a cheap thrills point of view.

Topic de jour? The GPL, one of my favorites.

Now you have to understand something about baiting a good GPL argument. The key is citing industry norms, experiences, and trends. This works well because the "industry" premise is simply invalid in the eyes of a GPL fellow and the flailing that is the result is amusing.

(For the record, I happen to be on level terms with the GPLv2, disagree with the GPLv3, and believe that a developer is welcome to license his software as he pleases. If the license a developer chooses happens to be GPL, so be it. For users and extenders of the software, the rule is simple: if you use GPL software, it stays open. If you need something closed, don't use GPL software. Now quit posting to comp.os.linux.advocacy and do something productive with your life.)

Does this make me a bad person? Probably. But in all fairness, it takes a GPL diehard on a warpath to initiate the argument with me before my evil side is provoked.

One of the benefits of these arguments is that they are an opportunity to revisit memory lane and cite examples of things that worked while making a conscious effort to avoid the things that didn't. During this particular argument, we took a tour of development teams, their size, and their impact...

Accepted belief: Small teams are significantly faster and more effective at building new products than large teams. Corollary: Large teams are slow and ineffective at building new products.

There are a few well known proof points to this argument:

The Skunk Works was (is?) a highly autonomous team created in the late 1930s and led by Kelly Johnson. Under Kelly's leadership, the group created some of the best known military aircraft in the 20th century. His well known Kelly's Rules included the rule that teams are to be kept small "in an almost vicious manner." The F117 Stealth Fighter was a disappointment for Kelly in many ways because he felt that the team had grown too large which led to troublesome development and a late project. By contrast, all of his earlier projects were small, on time, and under budget. (Recommended read: Skunk Works: A Personal Memoir of My Years at Lockheed by Kelly Johnson)

Apple's best known products were created in a similar way. The original Apple II was almost completely the design of Steve Wozniak, all the way down to the board layout and ROM software. The original Macintosh Team had only a small handful of people. The Macintosh products of the mid-90s were created by much larger teams and lacked the "ooph" that gave the original 1984 Mac the edge it had. The number of models also reflected a "design by committee" approach in their product marketing ranks.

The best example of the corollary is the IBM 360 project from the 60s. The project spanned well over 1000 software developers and generated multi-inch binders of documentation on a daily basis. Fred Brooks, the 360's project manager, went on to write The Mythical Man Month which is a must read for any project/program/product marketing/manager, regardless of industry. The project had gone so awry that Brooks created the now famous "Brooks Law": Adding people to a late software project makes it later.

The conclusions drawn out of these examples is that large teams in large companies are ineffective. This is often, but not always true. What ends up getting tagged along for the ride is the belief that large teams cannot innovate because bureaucracy gets in the way. Given enough layers of indirection within a single chain of management and innovation dies.

But is it really bureaucracy that kills innovation? Are there not examples of innovation with large teams large companies?

Actually, there are. A lot of them really. The IBM 360 project is an excellent example of this. A large team in a large company that defined what multi-user operating systems should be capable of. MULTICS, Unix, VMS, and their kids all came later. For as challenging and expensive as the 360 project was, it set a high bar for others to follow and was a key reason so many industries stuck with big iron all the way through to the 90s.

What really kills innovation is a company's culture. A company need not be large for this culture to form. I've seen it in mid-sized companies and even some small companies. The defining aspect of these cultures is PIT'M: Prove It to Me. In PIT'M, innovation is pitted against proof points. Someone proposing an idea must do so with proof points based on established market data: analyst reports, past growth, customer interviews, etc. In other words, the market has to be on its path to being a billion dollar business. While it is still possible to innovate in billion dollar markets, typically most of the innovation has already happened. If a drastic change to technology happens, it typically happens outside of an established market (e.g., Application Firewalls vs. Classic Firewalls) or a "megatrend" emerges that gives new technology a chance (e.g., hybrid electric cars vs. traditional cars).

PIT'M based businesses aren't necessarily bad businesses. Cisco is a PIT'M business and they make no bones about it. Until a market has clearly shown its path to $1B, they don't bother making a play. When it's time to make a play, they don't hesitate to acquire the innovator. Smaller plays are either ignored or viewed for their potential to enable sales of their bigger brothers. E.g., NAC enabling sales of newer 802.1x capable switches.

The other end of the culture spectrum is one that supports Gut based decision making. Innovation thrives in these environments because individuals are allowed (if not outright encouraged) to read between the lines and seek new business opportunities. In these circumstances, there is often little in the way of proof points or market analysis available. The decision is based on a certain degree of market inputs, customer comments, and intuition. In other words, your gut. There is more risk here, but it's the only way to be on the front end of innovative ideas that gain traction.

Large companies use of small teams, like The Skunk Works, for localizing Gut based innovation not because small teams are inherently more innovative. They do so to foster a low overhead environment that in turn costs less to run. Translation: flesh out the idea with a lower risk profile. Smaller companies are often forced into this role because they don't have the resources to wait for $1B markets, the corresponding research, and someone else to cook up the idea before they can jump into the game. By their very nature, they need to be on the leading end of innovation in order for them to stand out and gain attention.

Bottom line: Are small teams more effective at building products? Yes. Are they necessarily more innovative? No. Innovation isn't a question of team size, it's a question of team culture.