What I learned from Lineo's failure

Lineo (later renamed Embedix) was an embedded Linux vendor that rose to prominence in 1999 to 2000, and then cratered into obsolescence in 2002. I joined in 2000, the day that the acquisition of six (yes, six) different companies was announced. My first day of work was the approximately 400-person company get-together designed to build a team out of a mass of new bodies. Up until that day the total employee base was approximately 40 people.

I learned a tremendous amount about business and open source and the intersection of the two during my two years with Lineo. These lessons heavily influence how I see open-source opportunities today.

In the interest of sharing, here's what I learned:

1. You must own something. Lineo's business model was to provide developer tools to facilitate the development of software stacks for mobile/embedded devices. The tools business is a very difficult business and so the company sought to expand on this to create software stacks to power things like mobile phones and PDAs. The Sharp Zaurus was an example of the company's success with this model, but also its failure.
   Lineo didn't own the stack that it sold to Sharp. It was an aggregator of other's IP/open source (Trolltech's Qtopia, for example). Our model was to sell the stack on a royalty basis for something like $5 per unit, of which we'd take $1 or so. However, because we didn't actually own anything we were always in a dependent position to those who comprised the stack. Trolltech or Esmertec, for example, both had more control of the stack than we did because they owned IP within that stack. We had our distribution of Linux but it wasn't a solid differentiator, not with MontaVista and others creating essentially the same thing.
   In open source it doesn't matter if you license your IP freely. This, to my mind, is a positive thing. But you must own something. You must have control of something that you sell in order to convince customers to pay. Red Hat is responsible for 14 percent or more of the Linux kernel, which gives it soft control of the Linux kernel, but it's real value differentiator is in its Red Hat Network and other ancillary services.


2. A business that appeals only to developers is likely a good project, but probably not a good business. Lineo, as I noted above, made developer tools. In the open-source world developers are a gateway to those with money, but they ultimately don't control much money themselves. They are a hugely important constituency to woo, but they are not the group to which you want to sell products. Why? Because they can probably build your product better than you can, and so will have a disincentive to pay for it. They are your influencers. They're not the ones to put your children through college.


3. Grow slowly, profit quickly. I mentioned that Lineo went from 40 employees to more than 400 in one day. The company spent the next two years trying to recover from that too-rapid growth. There were many compelling reasons for this growth--the primary one being, I believe, the bankers belief that without revenue the best way for Lineo to justify a strong IPO was with headcount (which seems ludicrous in the extreme in retrospect but those were ludicrous days). But they all led to an over-investment in sales and marketing on the back of a product that couldn't support them.
   Open-source companies are first and foremost engineering companies. If the product stinks, the community will stink, the company will stink, the investors will stink, and so on. An open-source company must religiously focus on product excellence. Marketing and sales are important, but they come later and extend naturally from the excellence of the product. In a proprietary company, good marketing can make up for weak products (Witness some of Microsoft's success). In an open-source company, marketing that is better than the product deserves leads to corporate suicide. Eventually, customers look at the code and realize they were fed rubbish.

There are more lessons to be learned from Lineo (like how not to manage outsourced professional services resources, how to manage distributed development, etc.), but these three are enough. If today's open-source companies would pay heed to just these three things, we'd be a much stronger force in the market than we already are.