the elusive open source business model

In some cases, dominant technology companies have used open-source projects as pawns. Google, for example, has needled Microsoft by providing financial support to the nonprofit Mozilla Foundation, which oversees of the development of Firefox. I.B.M. has been a major backer of Linux, helping to raise it as a competitor to Microsoft’s Windows and other proprietary operating systems.

Many of the top open-source developers are anything but volunteers tinkering in their spare time. Companies like I.B.M., Google, Oracle and Intel pay these developers top salaries to work on open-source projects and further the companies’ strategic objectives. – New York Times.

There are four important views of open source:

  1. stallmanThe views of big companies like IBM and Oracle that make money from open source – as a tool for diverting money from competitors and evading anti-trust rules
  2. The views of companies like Sun that lose money from open source -  as a key part of the underwear gnome business model.
  3. The views of programmers who embrace open source as a substitute for a coherent political point of view or a union or something.
  4. The views of some engineers who see it as a way of getting low cost marketing of their work.

multicore and multiprocessor performance

Here’s two  interesting tables

Percentage of lock acquisitions for global TCP/IP locks that do not succeed

OS Type 6 conns 192 conns 16384 conns

89 100 100

60 56 52

51 30 26

49 18 14

41 10 7

37 6 4

33 5 2

L2 Data cache misses per KB of transmitted data.

OS Type 6 conns 192 conns 16384 conns

1.83 4.08 18.49

37.29 28.39 40.45

52.25 50.38 51.39

28.91 26.18 40.36

The ridiculous GPL-only tagging of Linux

Imagine that you release software under a license that is primarily concerned with making sure that modifiable source code is available to all and that no restrictions should ever be placed on derived works. Now imagine that someone takes a huge body of code like this and starts marking interfaces as limited to specific uses and claims that removing those markings is not permitted. How can the code be free for modification and not free for modification at the same time? It’s clear that some of the developers of GPL Linux kernel code discovered that it was difficult doing business under the GPL, but rather than finding a different license more to their liking, they have attempted to add additional conditions to the GPL  – something that the GPL specifically prohibits.

10th anniversary of the RTLinux Manifesto paper

The RTLinux* Manifesto was published a little over 10 years ago at the 5th Linux Expo in Raleigh North Carolina which was really the first one with a bunch of suits wandering around.  As a kind of celebration/experiment , I’m publishing an annotated version.

Here is a related discussion


* RTLnux is a  trademark now belonging to WindRiver/Intel.

Software Design and time synchronization

I have a blog post up at about our TimeKeeper software for time synchronization. TimeKeeper is currently aimed at financial trading markets, but we also hope to market it to electric power  distribution and transmission engineers who have a similar need for precise time synchronization within substations and for instrumentation. There are also applications in data bases for someone with a little interest in innovation.

TimeKeeper really builds on what our experience with RTLinux taught us about barriers to use. TimeKeeper installs simply – no developer needed, it’s just an app; it requires nearly no configuration; and it is invisible to application code except that it makes sure they get accurate time when they ask for the time.

More petty

The ALMA team has released ACS 8.0 on Red Hat 4.4, downgrading the Linux version from the foreseen 5.2 version. This choice, with the consequent back-porting of the code to the older OS version, had to be taken because of major problems encountered by the Control and Correlator teams in porting RTAI real time code to Red Hat 5.2. As soon as these problems will be solved, ACS 8.0 will be released also for Red Hat 5.2. Report

These folks deliberately chose to base their work on a  version of  software we developed that had somehow been transformed to have none of our copyright notices, ignored our complaints about their lack of interest in scientific integrity, and refused to even discuss a commercial solution with the inventors, and have by now invested untold amounts of public money trying to keep the mess working.

Montavista thoughts

Bill “Linux Pundit” Weinberg explains:

Business Model and Execution:  Many MontaVista watchers have argued that the company’s business model was essentially flawed. […]  Such a model based on building with and for open source can devolve into less attractive high-overhead packaged service business in the face of a rising value line.

[…] The model did not fail the company, but rather the company failed to execute on that model.

Failure to execute belies key assumptions about serving device OEMs with embedded Linux platforms and toolkits:

  • OEMs look to suppliers like MontaVista for productization of the latest Linux kernel technology, libaries, middleware and tools
  • OEMs expect frequent releases and deep expertise at many levels of the platform and tools
  • OEMs anticipate something “in the box” other than bits and bytes they can increasingly source directly from OSS project trees

While MontaVista made a strong start in all these areas, over time they reduced the  investments needed to meet these (not unreasonable) expectations

To me, MontaVista made a number of serious errors, but also faced a fundamentally hardhat-montavistadifficult situation caused by the massive underpricing of “board support” and the hostile nature of the business models of the semiconductor and device manufacturers on which it depended. The embedded industry is jam-packed with no-value added differentiators at the hardware level. Or to use English, the companies that make embedded devices choose to use a very large number of different hardware platforms that are very similar in terms of capability and cost, on the reasonable theory that a small difference in the sum of component costs  – the bill of materials (BOM) -  can lead to huge cost differences at large volumes. The result, however, is that these companies need a large amount of work performed to make their development and production boards run application software. They don’t start from working boards and software, they start from something new, although generally only new in being incompatible, not new in the sense of being better.  Making a board support package, the low level software is not easy and it is often very laborious.  But if you are committed to thinking in terms of saving $0.05 on a processor as a big deal, paying hundreds of thousands of dollars for software development – on invisible, low level, enabling software seems outrageous, particularly if it is “free” software. So Montavista’s business was doing something hard and time consuming for a customer base that insisted (with some justification ) that this was a low value product. And they entered the industry by selling the proposition that paying royalties for software was a terrible idea and that everyone else was overcharging.

So you sell something that (a) takes a lot of work to do and traditionally needs a lot of engineering time, (b) meets customer resistence on price  (c) is sold upfront – that is before the customer gets any revenue from selling devices, and (d) that you deliberately produce in a way that leaves you with zero leverage in terms of intellectual property limits. How could anyone make money from such a plan?

It’s not widely appreciated that software and hardware companies are competitors. Well, it’s appreciated by Google, Microsoft, Intel, Oracle, and other companies that have made a lot of money, but not by many other companies that continually are surprised by low profits. End users of computer based devices, especially embedded but increasingly in enterprise as well, pay for applications, not for bill of materials. It’s not like a cell phone user is willing to pay more for a nicer capacitor, a prettier battery, a better device driver, or a cleaned up browser. They pay for the working telephone.  So if the market price is $X for a phone, the big question is how those $X get shared among integrators, capacitor makers, battery producers, chip vendors, and application, middle-ware, and OS level software developers – there is a competition for who gets what share. And if you find yourself as the junior partner in the BOM scrum, one who is there primarily because you are advertised as undercutting your fellow vendors, you can expect to get squeezed hard. I bet that this is what MV experienced.

I should also note that MV had no happy allies either. It was not easy to collaborate with them and the idea that “if we do this together both of us will prosper” was not one that their management was enormously receptive to. The result was that their ability to act as an integrator was limited.

Montavista f-f-fades away

MOUNTAIN VIEW, CA–(Marketwire – 11/10/09) – Cavium Networks (NASDAQ:CAVMNews), a leading provider of highly integrated semiconductor products that enable intelligent processing for networking, wireless, storage and video applications, today announced that it is has signed a definitive agreement to acquire MontaVista Software for $50 million, comprised of approximately $16 million in cash and approximately $34 million in Cavium Networks common stock.

Not much of a return on $90 at least $90 million of investment – although to be fair, some of that investment was from semiconductor companies that took it out in services, so to speak.

Yodaiken’s Rule: Anyone can create a $50M/year break even embedded Linux services company given enough investment.

(Thanks to JK for the snotty punctuation remark. Feh).

Parallelism and multicore

The goal of modern processor chip design has changed from optimizing various speed/price/heat tradeoffs for applications to finding excuses for dumping more transistors into the device.  Heard an interesting talk from Krisztián Flautner of ARM at the ACISC conference and I have to admit that it’s not entirely the fault of the chip designers – since they design for operating systems that have stalled for 30 years or more.