What Palm Inc's Linux OS might look like

[cervezas]

I couldn't resist working up a diagram that deduces what the Linux OS that Palm seems to be working on might look like, presuming it's being designed as an update of the Palm OS for the Treo line.

My conception in a nutshell: a system that is backward compatible with Palm OS Garnet via a Palm OS emulator, but with improved multi-tasking and 3G network support via a handful of built-in native Linux applications. Pretty modest compared to ALP. This is something that Palm could plausibly have developed for release in Hollywood and/or Lowrider assuming (a) they started working with Linux at least a year and a half ago on an R&D basis, as CNET reported back in Nov 2004, and (b) they decided to move into product-development mode around the time they lost the bid to acquire PalmSource last summer.

Here's the pretty picture:

And here's the article explaining it.

I apologize that I don't have a Treo I can saw the antenna off of and paint like a plastic model race car to show what the Hollywood and Lowrider handsets will look like when they arrive. I'm sure that would generate a lot more discussion than my box diagram.

[Antoine of MMM]

This looks like a less complicated version of what Access has already showed. What is the difference between this and the Access version besides MAX? How does this come to market faster and (seemingly to me) with the same functionality? You have my attention, I jut dont know exactly to what I am attending.

[surur]

There, David, I fixed it for you. One, there is no evidence that Palm has any focus on Java. They dont even ship a Java VM on the Treo. Secondarily, some of those Linux adverts specifically talk about rewriting the PIM's in Linux, so we have to assume they would be native too. Thirdly, the role of Palm 68k apps are under-emphasized in your diagram. Remember, for Palm, this will be all about continuity. Palm-Linux will look very much the same as POS Garnet. Lastly, Lowrider will be PalmOS and Hollywood WM. If these devices will ship in the next 6 months (which is generally assumed) Palm cant still be developing the OS now (which they obviously are, as they are hiring pretty low level developers)

Just a question, who's browser do you think they'll use? Will the license Access Netfront for Linux?

Surur

[doctorow]

It shouldn't be too hard to run a Java framework outside the OS (if you need Java). So I agree with Surur, Java shouldn't be hardwired into the system's core.

David stresses the importance of multitasking, and he is right. Palm OS needs to be fully multitasking-enabled to compete with the other modern systems of today. There was a great discussion with Dianne Hackborn, (former?) PalmSource employee, here at MobileRead, where she gave some more details on Cobalt's multithreading and process support. You can find the discussion here.

[TadW]

Originally Posted by cervezas

I apologize that I don't have a Treo I can saw the antenna off of and paint like a plastic model race car to show what the Hollywood and Lowrider handsets will look like when they arrive. I'm sure that would generate a lot more discussion than my box diagram.

LOL! I tell you what - take a Treo and find someone who can use Photoshop and you will have the same results without commiting this sacriliege of destroying your handheld. I am already starting to miss those Photoshop fakes that have been circulating around in the past.

Great diagram, David! I hope Palm will hurry up and surprise us soon with something other than Palm OS or Windows Mobile.

[cervezas]

Antoine:

The main two reasons this could come to market faster is that (1) Palm is rumored by a credible source to have been working on it even before PalmSource started working on Cobalt for Linux--some of which time has probably just been research, but still, they may have the jump on ACCESS; and (2) leaving out MAX, which is a public API, and having a native framework that is only for use internal to Palm saves a lot of time and effort. Public APIs are "contracts" with developers that you need to be able to keep for the long run. Private ones are still contracts you want to keep, but it's a lot easier to break them if the only clients are internal.

Surer:

You could be right about Palm developing the PIM apps as native applications. If we did find out they are doing that I would lean more toward the opinion that they are developing this framework as a public API for the long haul. I can't see a reason to make native PIM apps if the native API isn't going to be the new Palm OS SDK since PIM apps don't really benefit from having better multitasking nearly as much as the other apps I listed.

If Palm is trying to build an open Linux platform rather than a temporary life support system for Garnet it would mean we'd be a lot less likely to see that platform in any of the Treos coming out this year. And it would also mean that Palm is less likely to migrate to ALP in the future: their platform would truly be the new Palm OS for Linux, a project on the same order as ALP. The platform you outline is a lot less desperate than the one I outlined (at least if we amend it with the idea that the native API will be a published SDK for 3rd party developers). Perhaps Palm has done another magnificent hack on Garnet to make it comply with UMTS and thereby bought themselves enough time to do this platform right. If so, hats off to them and whoever they're partnering with to do it (it wouldn't happen without a major Linux partner like MontaVista, Trolltech or Wind River.)

As for Java, I generally agree that it's not a priority for Palm to have it on every device so, yes, the Java environment might not ship with the platform. But the Treos do support Java ME using IBM's Websphere Everyplace environment and I'd expect that to continue to be the case. Actually, with a Linux environment I'd say IBM might take a much closer look at partnering with Palm (or just some open source contributors) for an Eclipse eSWT and eRCP port. That's the cutting edge in mobile Java these days since Eclipse is all the rage in the Java world. See, part of the reason that Palm hasn't kept pushing on Java is that Garnet imposes some limits on the kind of Java environment that can be supported: the highly constrained CLDC/MIDP is the best you can do, whereas Symbian and Windows Mobile support CDC/Foundation Profile and Personal Profile--much closer to full-fledged Java SE.

As a developer I find it very interesting that the 68k API could become more like a standard (akin to J2ME) than a specific implementation. In other words, it might actually exist for some time on devices running both ALP and "Palm OS 7" devices from Palm. Nevertheless, we'd expect the two platforms to focus on the development of their native frameworks and for both users and developers to migrate fairly quickly over to those frameworks for the apps that they create and buy. Lots of opportunities looking at this from the standpoint of the growth of mobile Linux, but also plenty of problems with this kind of split of the "Palm" economy. If Palm is really doing what it looks like they are doing I hope they'll get involved with MLI and LiPS and help to form some standards for mobile Linux rather than just "going rogue."

Keep in mind, while I think it's fairly certain that Palm is doing some significant framework development with Linux, we really have no idea what that framework is for. It could have nothing at all to do with smartphones and be for a completely new product category. Palm could be quiet about ALP just because ALP for all intents and purposes doesn't even exist yet and they want to be cautious as they were with Cobalt. There are many unknowns and the stuff I'm presenting here is just what I see as a probable scenario based on rumors and job postings.

[cervezas]

Just a question, who's browser do you think they'll use? Will the license Access Netfront for Linux?

Based on Palm's and Handspring's long-standing partnership with ACCESS on the browser front, I'd say yes.

If Palm was *really* desperate, they could actually get that whole native Linux application suite from ACCESS: http://www.access.co.jp/english/products/nf_mcs.html. I don't think they are, though. And I wonder if ACCESS would allow them the freedom to do their special Treo magic on that software if they did license it.

[surur]

Actually, looking at these two job listings, it looks like Palm is planning to do it all on its own.

Smartphone Browser Software Engineer Job code: 334
Job Category: Engineering

Job Description:

Duties/Responsibilities:

Design and implement the wireless web browser for our future smartphone and handheld products

Help invent new ways to improve the performance and layout of web content on mobile devices

Work collaboratively with a multidisciplinary team to successfully take the software through the entire development cycle (design, implementation, maintenance)

Help define and implement web-based and other applications and technologies for our mobile devices

Respond to customer and developer issues inside and outside of the company, troubleshoot problems, and respond with recommendations, patches or upgrades as appropriate


Qualifications:

2+ years of software engineering experience desired


Skills/Experience:

Experience in several software projects from design through delivery; demonstrated design skills; proficient C and C++ coding and debugging skills, good problem solving skills

Project experience designing and implementing software user interfaces

Knowledge of markup languages and data transport protocols, such as HTML, CSS, Javascript, WML, XHTML, DHTML, XML, TCP/IP, HTTP, and SSL

Demonstrated success working in collaborative team projects

Excellent communication skills, both verbal and written

Significant project experience developing software for Palm OS, UNIX/Linux, or similar embedded platforms; knowledge of broad areas of software technology

Experience with network communications application development, specifically web browsers, messaging (mail, SMS, IM), voice applications or camera (imaging) applications


Education:

B.S. in Computer Science, or equivalent

http://www.maxhire.net/clients/MH160...?reference=334

Software Engineer, Email Applications Job code: 957
Job Category: Engineering

Job Description:
Title:

Software Engineer


Overview:

The successful candidate will play a key role in the development of groupware application products for Palm Inc.'s handheld and smartphone devices. Work as part of a team to develop and maintain Email applications. Candidate will be actively involved in all aspects of the software development lifecycle.


Duties/Responsibilities:

Develop and improve existing features in Email application. Take existing designs and create elegant and robust implementation.

Debug existing features to improve overall product quality.

Using User Centric Design principles, identify opportunities to improve the overall usability of the application.

Grow into a role that will utilize marketing requirements to define, design and implement new product capabilities.


Qualifications:

2-5 years of software product development experience.
Experience with producing consumer based applications, especially email a plus.
Experience with Palm OS a plus
Experience with Linux a plus.

Skills/Experience:

- Experience in product development
- C and C++ coding and debugging skills
- Proven problem solving skills.
- Proven object oriented analysis and coding skills.
- Demonstrated success working in collaborative team projects.
- Excellent communication skills, both verbal and written with the ability to communicate technical concepts clearly and effectively across multiple organizations
- Demonstrated commitment to quality.


Education:

B.S. in Computer Science, or equivalent

http://www.maxhire.net/clients/MH160...?reference=957
Sounds like a brief to port existing software to another (linux) platform.

They are certainly ambition, which may mean slippage.

Surur

[cervezas]

The only thing about those two postings, Surer, is that embedded Linux skills would be good experience to have for those jobs even if they were for 68k Palm OS application development. In this day of object-oriented programming, Java, and .NET, I expect it's harder to find talented C language developers than it used to be, especially ones with specific Palm OS experience. But any good Linux C developer can learn Palm OS pretty easily. They also might be a little more likely to have experience working on teams in a corporate setting than, say, you're average Palm OS shareware developer.

I still think Palm is doing some kind of platform development using Linux because of that one very specific job posting and the fact that they were hiring lots of Linux engineers in the Fall, but these two positions just sound like Palm OS engineering jobs to me.

[Bob Russell]

Don't we already expect that it's likely Hawkin's secret "third business" will involve some sort of Linux platform? In other words, Linux doesn't seem to require the conclusion that pda/Treo lines are moving to a non-Access platform.

[Chaos]

Erm... Is it a mistake that those diagrams suggest that no 3rd-party apps will be Linux native, or is that just a bad decision by Palm?

Because all 3rd party apps having to be run through a "Palm app" emulation layer seems like an awful waste of resources for people who will want to run things like games or emulators on Linux-based Palms.

[surur]

Originally Posted by cervezas

The only thing about those two postings, Surer, is that embedded Linux skills would be good experience to have for those jobs even if they were for 68k Palm OS application development. In this day of object-oriented programming, Java, and .NET, I expect it's harder to find talented C language developers than it used to be, especially ones with specific Palm OS experience. But any good Linux C developer can learn Palm OS pretty easily. They also might be a little more likely to have experience working on teams in a corporate setting than, say, you're average Palm OS shareware developer.

I still think Palm is doing some kind of platform development using Linux because of that one very specific job posting and the fact that they were hiring lots of Linux engineers in the Fall, but these two positions just sound like Palm OS engineering jobs to me.

The point is that they are hardly going to write an e-mail client and web browser for POS Garnet. We all know Garnet is not the future. If they are writing for the future, its either going to be WM or their own Linux. If they are going ALP, it will come with an e-mail and very good web browser. So will WM (and they dont mention WM experience at all). The obvious inference is that they are ignoring ALP and going their own way.

Surur

[cervezas]

Originally Posted by surur

The point is that they are hardly going to write an e-mail client and web browser for POS Garnet. We all know Garnet is not the future. If they are writing for the future, its either going to be WM or their own Linux. If they are going ALP, it will come with an e-mail and very good web browser. So will WM (and they dont mention WM experience at all). The obvious inference is that they are ignoring ALP and going their own way.

The problem, as I think you well know, is that ALP is at least a year a way and could take another year to 18 months to be turned into the first Palm products. I agree that Garnet as it exists today is not the future, but Palm needs a short-term future as well as a long term one for Palm OS. This is where the kind of stop-gap Garnet-oriented Linux platform I described might come into play. But there's another possibility that I haven't discussed: Garnet has a preemptive multi-tasking kernel that with the right framework added to it could support multitasking much like Linux, Windows Mobile, and Symbian do. That framework would not be able to run existing Palm applications, but it might be written to exist side by side with the PACE environment to run some ROM applications within their own processes. In other words, take the diagram I presented and substitute the Garnet kernel for Linux. Call it Garnet 2. Again, this might be something that Palm would plan to use just for 2 or 3 years until it's had time to assess ALP and the result of it's own Linux work.

Garnet 2 would need non-Palm OS applications designed to run on the new framework, same as a Linux platform would. Email and browser would be among them since those would be applications that would most improve the multitasking capabilities of the platform. The Phone application would be the other one that would be critical to enable Garnet 2 phones to run on UMTS networks. Those jobs could be for new Garnet 2 browser and email applications for all we know.

Garnet 2 would still be a big undertaking. Once you get outside the existing application framework I'm not sure whether there is enough of a system left to bother building on. I'm somewhat skeptical that Palm would invest the time if they wanted to start building their Linux chops for the future. But like I said: Palm needs to be able to support the shift to 3G on the GSM networks and they probably know better than the rest of us how far mobile Linux has to go before it's ready to deliver the kind of experience that Palm users expect on a 3G phone. If there isn't going to be a way to get Palm OS running on Linux quickly enough, maybe they'd hire some ex-PalmSource engineers to help them hack an extra private framework onto the side of Garnet.

Bottom line: ALP's future on Palm hardware looks murky, but it's still too early to say for sure. If Palm is creating a stop-gap OS they only plan to use for a couple of years that's not exactly something they'd want to advertise by getting all enthusiastic about ALP in public, is it? Given their current predicament, I don't blame them for holding their cards pretty close.

[cervezas]

Originally Posted by BobR

Don't we already expect that it's likely Hawkin's secret "third business" will involve some sort of Linux platform? In other words, Linux doesn't seem to require the conclusion that pda/Treo lines are moving to a non-Access platform.

I think it could be a Linux platform, yes. The way he describes it (involving lots of storage capacity and fancy high-speed networking, for e.g.) it would probably be something that would do well with a standard file system and Linux protocol stacks.

The main things that makes me think the job postings I was reading are about building a smartphone platform are the use of the word "handset" in the job title and my understanding that Garnet is going to be a sticky problem for Palm OS Treos that are expected to run on some 3G networks.

Originally Posted by Chaos

Erm... Is it a mistake that those diagrams suggest that no 3rd-party apps will be Linux native, or is that just a bad decision by Palm?

That was intentional on my part. Not that Palm doesn't want to have an open Linux platform at some point, but that if they are trying to get an updated version of Palm OS to market quick they might not expose their native Linux APIs at first. Also, I hate to say this, but some operators might like it better if the Linux APIs were not exposed since they might see this as causing support headaches for them. If Palm wants this to be used on cheaper Treos they are going to want it to be as trouble free as they can make it because support calls burn up the value to the operators very very quickly.

One other reason maybe not to create and publish a public API on the native Linux side: if Palm wants to keep the door open for ALP they might not want to do this only to say a couple years later "just kidding about that API... now we want you to use this one."

This is all speculation, of course. I don't have any knowledge about real decisions Palm has made in this regard, good, bad or neutral.

[surur]

All this talk about stop gap measures does make much sense, especially if Palm has to hire in new programmers to make it happen. 20 coders at $100 000 is $2 000 000 per year, all wasted in two years when Palm goes ALPOS. And all this to get on the ALPOS royalty bandwagon in two years.

When Palm renewed their PalmOS license in 2005 till 2009, this was the deal.

PalmSource will receive minimum royalty commitments of $148.5 million and source code license fees in the amount of $3.2 million over the remaining course of the contract as follows. The minimum annual royalty commitments for the contract years ending December 3, 2005 and 2006 remain unchanged from the Prior Agreement at $41.0 million and $42.5 million, respectively. The minimum annual royalty commitments under the extended term of the SARSLA for the contract years ending December 3, 2007, 2008 and 2009 are $35 million, $20 million and $10 million, respectively, subject to the Company meeting certain development milestones.

Thats $148.5 million between 2005 and 2009. Thats nearly $30 million/year. The cost of the license decreases as POS obviously depreciates with age. However for a new ALP license, especially if the Treo is very popular, they will obviously charge more again.

If Palm goes for a per device license, and they sell 5 million Treo's, at a conservative $10 per device, thats still $50 million/year. Even at half that its still $25 million/year.If they own the OS they save that money. Thats the salary of a few hundred Linux hackers/year (and many more in Asia ).

Symbian currently charges $7.50 / device for the first 2 million devices, and then $5/device after this. Even under that license Palm would have to pay $30 million for 5 million Treo's/year. Nokia is estimated to have paid Symbian $140 million in 2005. Thats up from $55 million the year before. Why do you think the Nokia 770 is Linux? If that experiment succeeds they could drop Symbian like a hot potato. I believe Microsoft charges between $12-16/device, but then you get components you have to license separately included, such as a web browser (blazer in POS), media player (Ptunes in POS) and Office Suite (Docs to Go).

License fees for the OS is obviously a major cost for OEM's, which the real reason why Linux is such a threat to the various closed mobile OS's. PalmSource (before acquisition) has 518 employees. Palm has 700+, 80% programmers. If PalmSource can do POSLinux, so can Palm. The original creators of PalmOS are on their payroll, for heaven's sake.

Your suggestion is like buying a flat for a few years while waiting for a rental complex to open, demolishing the flat in two years and then renting a flat in the flat complex in perpetuity. Why not just buy a bigger flat and stay there forever, and for a lot cheaper to boot?

Ed Colligan has already said he wished he owned POS. Now he can.

Surur