Google recently sent a cease and desist order to a developer who was including the proprietary Google apps in his Android ROM. The developer, cyanogenmod seems to have no hard feelings about the situation and is willing to work with Google. But the broader community appears to be dissatisfied with the situation. I see a couple of interesting angles on this, Google’s need to own their applications, and Google’s desire to own as much as possible.

First, Google has the right to own their applications, but beyond that they also need to provide assurance to the public that Google-branded applications are safe and secure. This is nothing new, the Symbian Signed program was designed to provide this type of assurance to device makers, and network operators. It seems necessary and essential that Google protect the distribution channel of their applications.

On the other hand, Google also has a desire to exert control over the market to direct people to their web properties. The Android platform was sold to developers as an attractive, new open-source project, the next big thing. But ultimately Google wants to make sure their apps show up on whatever devices hit the market - All Your Internets Belong to Us. It’s my guess that this is just the reason that Apple rejected the Google Voice app from the iPhone. Google’s application strategy could have the effect of turning the iPhone into just-another-Google-device.

For the time being, device makers and network operators seem to be warm to the Android platform since it gives them time-to-market advantage for developing interesting devices. But will the market tolerate a Google strategy that effectively renders all players subservient to Google? And does this recent C&D Order represent the first Darth Vader move for Google?

As a Linux marketer I try to keep track of open source alternatives. For example, I occasionally meet engineers who prefer to use BSD for various reasons. Just the other day I came across the Haiku project, which is an open-source project to revive BeOS. I’d never used BeOS, but I remember a co-worker from NCSA going to work there many years back, so I decided to give the alpha a try and see what I’d been missing.

I downloaded an ISO which I booted into VMWare, and after just a few seconds I was asked whether I wanted to Install, or proceed to the Desktop. I liked that. Once I got to the desktop, I’ll admit I was a bit lost. I started clicking on icons to see if I could find anything interesting. I quickly found the documentation, which appeared to be aimed at developers, not users. The docs launched in a browser, with a link to Access at the bottom - I didn’t investigate that relationship any further. I then launched the Wonder Brush drawing app which performed fairly well IMHO for inside a virtual machine.

For now Haiku appears to be a novelty. I had fun spending 15 minutes playing with it, but it’s not immediately apparent how it can become relevant beyond a few enthusiasts or hobbyists. And if you’re working on an open-source implementation of OS/2 Warp 4, let me know.

Last week I celebrated my 5th anniversary at MontaVista, and was telling a co-worker a story about some previous engineering experiences.

At a previous employer I was on a small engineering team responsible for producing a commercial Linux distribution. Our “build system” was 1) a guy on the East Coast and, 2) some scripts on his workstation - the workstation could never be updated or modified lest we risk breaking the build.

A large conference was coming up and we needed to demo our latest software, so we crunched to get the latest bits checked in and our build guy produced some DVD images and FedEx’d them to San Francisco. We receieved the DVDs on a Friday afternoon, only to discover that upon booting the new OS the kernel panic’d.

With less than 2 days to get the system ready to ship over to the conference, and the East Coast build guy off for two weeks of vacation, the two West Coast engineers (myself and a co-worker) spent the weekend in the office pulling apart SRPMs, manually patching sources, and doing whatever we needed to cobble together something that would boot and demonstrate the applications we had ready for the show.

The products we shipped at that company were enterprise-oriented, and so the build system was really only critical to our internal process - our customers never ripped the system apart, even though it was Linux-based and they had every right to do that. Now that I’m out of Enterprise and in Embedded, I see that customers almost always want to take our products apart and put them back together to customize for the embedded devices they’re making. IMHO, this makes a build system a basic necessity of any embedded Linux product, and I’m glad MontaVista has been able to rally around the open-source build engine
bitbake and ship it in our latest product.