Comments on: Is Palm Building their own OS?

Because that is the problem really. The keyb, the antenna and the smaller screen.

Marty

May You Live in Interesting Times

The big question is how it will run legacy apps.

I just want a 320*480 device with a TX-sized screen and wi-fi/cellular connectivity. Since BT has turned into nothing more than a neutered shell of what it was originally promised to be, that can be omitted in favor of a cellular radio.

So...take a TX, drop the BT, add in cellular, keep all antennas internal even at the expense of signal strength. Add a higher capacity battery, a charge LED & a voice recorder for good measure and I'll pay whatever price Palm asks for such a beast!

Whether or not it has voice functionality is irrelevant to me (I'd prefer it left out for size/cost/complexity issues) as long as there's something similar to what the good Vampire mentions. But the tiny SSS and the hideous antennae protruding are the MAIN reasons I still have trouble stomaching the Treo concept.

Pilot 1000-->Pilot 5000-->PalmPilot Pro-->IIIe-->Vx-->m505-->T|T-->T|T2-->T|C-->T|T3-->T|T5-->TX

Well, I haven't bought a new Palm OS device since ~2001 because Garnet is a garbage, go between OS (as a developer, I want something fun and worth developing software for), and I use Bluetooth daily for syncing, file transfer, headsets, etc. Cellular would be OK (it'd especially be nice if they could do some kind of dual CDMA/GSM radio), but I can always just use WiFi or through my cell phone via Bluetooth for connectivity.

So, "FrankenGarnet" and no Bluetooth would be a guaranteed way to continue to keep me off the Palm platform.

What you mean by this is that the "features" of FrankenGarnet are fine.

The consequences of FrankenGarnet are an unstable and underpowered system that results in mistrust of the device and causes companies to leave the Palm OS to adopt WindowsMobile devices. Mistrust isn't an overnight problem, but will cause users to slowly move away from Palm OS.

I'm sure that you have had a perfectly acceptable time with your Treo as an individual and therefore Garnet must be fine. There isn't a specific bug, but rather the fact that Garnet has been stretched out way beyond its original capacity and is held together with fraying strands of duct tape. It isn't reliable. Some more advanced features (like a full powered browser) would be either not feasible (or feasible and costly to develop). In the long run it should be obvious that an OS with a development "tariff" is not advantageous for the Palm economy.

The solution is/was Cobalt which is the operating system that Palm needs/needed. Cobalt has the solidity that make it acceptable for large corporations. Cobalt was complete and PalmOne never adopted it.

It is idiotic that the guys at Palm are essentially trying to make Cobalt again. They already made it the first time and then cashed in for money when sold PalmSource. Now they are making a new Cobalt on a lower budget and less solid.

Why was Cobalt never complete? Answer: It was completed! It was solid. Palm/One chose to convert the project into today's cash rather than using it to improve the product. This is the single most idiotic move that the company ever made. It is completely representative of the kinds of choices made by Palm executives. When in doubt always take the cash instead of improving the product.

Ever since, these idiots have been ignoring the issue of Treo dysfunction and do their best to ignore/hide these problems in the media. Treo has sold pretty well in spite of the problems. It could have been the leader in the smartphone market and should been the king.

Today, all the companies want to make a phone with a Treoish keyboard, larger screen etc. I get it that you personally don't like Treo, but this is what the market wants and this is where the money is. If Palm had had a solid offering here, they would have cleaned up and been ahead of the curve instead of lagging behind it.

Even though you don't use/want a phone, the Garnet on your TX still hurts you. The Franken/Garnet "tariff" results in higher development costs that lead to less software being created even for non-phone models.

You make mostly valid and accurte points. There's a distince reason I've never had a Treo. Remember, just because I've never owned one doesn't mean I have not USED one.

It's just that the Treo in its most *current* advanced permutations (700w/650/700p?) trail the top conventional Palm PDAs (TX, T5, T3) in most areas...specifically, screen size & resolution, RAM and/or wi-fi. Those are the three most important factors along with battery life for me when choosing a mobile device.

I have also been rather underwhelmed with the Treo's voice quality & RF performance. I use a V3c on Verizon and find its voice quality leagues better than a colleague's Verizon 650.

I have zero problems with the market wanting & buying Treos. I do agree that Garnet is well past its prime but I'd still rather put up with its quirks than have to suffer through WinMob adaptation and rebuying all of my registered apps/games. Trust me, I am quite well versed with how to make FrankenGarnet crack under pressure. You must not have read my reports on using the LifeDrive last year and trying to download HTML e-mails in VersaMail while in landscape mode and connected via wi-fi.

Of course, there are many Treo 650 fans that say their carefully tweaked 650s are actually more stable than a comparable T5/TX so go figure.

For anything with just one wireless radio & 320*320 or less, Garnet *IS* a decent OS for a cheap PDA. Think Z22, Zire 31, T|E2 etc. Anything above $200 or incorporating telephone or multi wireless functionality functionality needs a more robust US. But since WinMob & Garnet are the only games in town for well into next year, I'll stick with the one whose idiosyncracies I am most familar with. It's not like I/you/we have a CHOICE in the matter! And FrankenGarnet HAS been shored up considerably since the T5 & Treo 650 launch as far as speed & stability.

P.S.
"Even though you don't use/want a phone, the Garnet on your TX still hurts you"
This brings to mind Gekko's prediction from last year when the LifeDrive came out... "My prediction? MORE PAIN!"

;-)

Pilot 1000-->Pilot 5000-->PalmPilot Pro-->IIIe-->Vx-->m505-->T|T-->T|T2-->T|C-->T|T3-->T|T5-->TX

Before Palm Inc. got their hands on Garnet, it was reliable, fast, and fairly lean. Frankengarnet is a masterpiece of crapola. I wouldn't touch anything that Palm Inc. put out, and I'll buy any phone that PalmSource puts out. It's palmsource that has all the Be programmers and original PalmOS programmers. Palm Inc just takes existing working software like Versamail and PalmOS and insert bugs into them.

I'm jumping off the Palm Inc. train as soon as I get a chance. They suck.

I don't! :P

"It's palmsource that has all the Be programmers and original PalmOS programmers"

Ha! That really helped them deliver on Cobalt, didn't it....

This sig is a placeholder till I come up with something good

Garnet was faster and leaner before the NVFS debacle, but was it really more reliable? I have to go back to OS 4 to find a really reliable Palm OS, which is one reason I love my little Samsung i500 phone.

The problem with your statement is this: when was the last time we really got to see what PalmSource can do? Every really substantial product that they've developed since they were spun off has died on the vine (Cobalt and Cobalt on Linux) or is still in development (ALP). Who's to say what a PalmSource platform would be like if we had one we could hold in our hand?

I realize that Cobalt may possibly have failed in part because of poor engineering, but my take (based on my limited knowledge) is that the biggest failures--even many of what could be called engineering failures--came as a result of decisions and habits of the top management.

David Beers
Pikesoft Mobile Computing
Software Everywhere blog
www.pikesoft.com/blog

Most of the handful of remaining Be programmers went to Google recently. (See Dianne Hackborn's interview on OSNews.)

Access has a large talent pool in Japan, the CMS folk in China, the Montpelier team, and, of course, PalmSource sunnyvale, to draw on.

May You Live in Interesting Times

FX: Knowing grin

If the history of PalmSource is ever written, there will be enough blame to go around to just about everyone. While management failures there are significant and routine, the mix of former Be, former Palm, former Apple, and so forth, did not make for good engineering.

May You Live in Interesting Times

But they did deliver on Cobalt; Cobalt is an excellent solution, but PalmOne never adopted it. The problems weren't technical or programming, the problems were political and licensing.

Garnet isn't a horrible thing. The problem is that Garnet grew out of the original Pilot architecture designed in the 1990's long before phones and NVFS existed. Garnet is stretched far beyond its original intent and doesn't belong on Treo 650s.

Cobalt isn't a horrible thing. The problem is that Cobalt belongs on Treo 650s and solves many of the problems that users are experiencing today. PalmOne never used Cobalt because of all the idiotic licensing structures and political fighting.

Where is the poor engineering in Cobalt? Where is the evidence that anything is wrong with it? The problem is that Cobalt never made it to a PalmOne device and therefore many people assume that Cobalt must be buggy or faulty. This is not true!

PalmOne never adopted Cobalt because they didn't want to pay the fees. PalmSource separated from Palm with an unusustainable licensing structure. Licensing should have been based on royalties but instead licesning was weighted towards lump sums that discouraged hardware makers from moving to a new OS. The lump sums were formulated during a time when Palm was on an upward curve and competition from hardware makers would ensure adoption. Later the lump sums were just not sustainable and PalmOne was unable to pay fees for their own OS. Idiots at PalmOne didn't want to pay for the new OS and idiots at PalmSource couldn't back away from the front-loaded licensing scheme because they had already spent money expecting future windfalls.

When Palm was split into two, PalmOne was able to "hide" the expense of several years software development by inserting the development costs into PalmSource. PalmSource on the other hand was counting their chickens by relying on a huge windfall owed to them by PalmOne for Cobalt. In a dysfunctional way both sides were able to benefit (in the short run) from these shenanigans. The bubble burst when PalmSource tried to get PalmOne to pay up and neither side actually had money.

PalmOne did not use Cobalt because they could not afford the fees. PalmOne skipped Cobalt and in doing so made their financials look better so that management could retain their jobs.

The idea that Cobalt is bad is an implicit rumor. Very clever. Neither PalmOne nor PalmSource has ever indicated that Cobalt was faulty. (Yes there will always be minor issues in a complex system, but please show me the fundamental flaws with Cobalt--you can't because there are none)

By the way, I am not a PalmSource engineer. I am/was a stockholder (who knows software) and am so pissed off. I refuse to let management blame engineering. The truth of Palm is pretty simple--greedy mismanagement--point the finger at engineering as cause. This is as bad as Enron blaming non-existent energy shortages in California.

If and when it did, it was mostly by accident, and despite one engineering faction or another getting into another faction or another's face over significant differences in how to develop software.

Neither PalmOne nor PalmSource has ever indicated that Cobalt was faulty. (Yes there will always be minor issues in a complex system, but please show me the fundamental flaws with Cobalt--you can't because there are none)

The binder and the driver model are both fundamental flaws in Cobalt. The process model isn't precisely the best engineering I've ever seen, either. Power management was clever but could have been significantly better. LFS was never finished, so there was no real replacement for NVFS. There was no attempt to deprecate the sram non-volatile model.

I refuse to let management blame engineering.

Blame both, there's plenty of blame to go around in this case.

I can't speak to Palm(One)'s problems at all. PalmSource, on the other hand had plenty, and engineering was among them.

May You Live in Interesting Times

Dear PenguinGuy. Obviously you are an engineer and in a limited sense, I agree with you on some of these issues and I understand why you want to bring them up. However, from a business level perspective, these are minor things. These aren't the reasons PalmOne backed away. Your talk is confusing to outsiders and assists PalmOne get away by hiding mismanagement by focusing on engineering issues. Ken Lay can point at bad energy laws in California and certainly some of his points are true, but the greater reality is that Ken Lay is trying to move focus away from the real problems.

Even if power management was better or LFS finished, PalmOne would still have renegged because their cashflow looked bad. The bottom line is that management needed to hide their cash problems and pointing at engineering was the convenient way to do it.

I really wish that Cobalt had been released on some real devices (tiny foreign companies don't count) and then people could debate some of these fine points. I'd probably take your side on many of these issues in that alternate future reality. But as it is Cobalt never really existed and it makes little sense to blame minor engineering points when management is the root cause.

The blame lies firmly with PalmSource for producing a smartphone/handheld OS which nobody wanted to buy. Even if PalmOne couldn't afford Cobalt due to cash flow problems, how come no other company has shown interest in Cobalt? If Cobalt is so appealing then how come Dell, HP, Motorola, SonyEricsson or even one of the carriers (ie Verizon, Orange, T-Mobile) haven't shown any interest or are you telling us all these companies have cash flow problems too!

It's notable that HTC (an Original Device Manufacturer) have been selling their devices directly to the mobile carriers. What was to stop T-Mobile or Orange putting Cobalt onto these devices instead of Windows Mobile?

No other company will touch Cobalt unless PalmOne picks it up first. The confidence problems feed themselves and become a self-fulfilling prophecy if PalmOne doesn't buy.

Software needs to be recompiled and rewritten to take advantage of Cobalt. No software developers will sign on if the base market isn't large enough. Even if, for example, Verizon built their own Cobalt phone, this wouldn't hit critical mass for 3rd party software to appear.

I do think that PalmSource deserves blame but for different reasons than you do. PalmSource should have never been separated from Palm in the first place because the overall size of the Palm market (even if PalmOne did sign on) wasn't really large enough or growing fast enough to financially sustain an independent OS company. Basically, it was not financially feasible from day one. Given the total size of market, the OS producing team needs to be subsidized by the hardware.

You are right that PalmSource should not have produced a smartphone/handheld OS that nobody wanted to buy. But here is the truth. No matter what they produced (no matter how good or how terrible), nobody will buy unless PalmOne buys first. I have said all along that PalmSource was stupid for assuming that PalmOne was an automatic customer.

Additionally, Cobalt was really optimized for Treo. It might be feasible, but costly to adapt Cobalt to run on an originally WinMob designed hardware. Why would anybody do this?

Additionally, even if other Cobalt handset manufacturers existed, they would very likely purchase portions of design and/or components from PalmOne. Nobody is going to build an entire device from scratch.

Cobalt was finally released only after everybody (except PalmOne and a few insignificant users) had already left the Palm business.

Sorry, no, I'm not. Got into this business before people felt the need to inflate their job title. I'm a programmer, when I'm not a manager.

However, from a business level perspective, these are minor things.

Sorry, but "doesn't work" is not a minor thing. Oh, and the reason I brought them up? You claimed they didn't exist.

These aren't the reasons PalmOne backed away.

They are the reasons given. Your comments about cash flow make no sense, given the structure of the license deal, by the way.

Palm(One) may be mismanaged. It certainly gives that appearance. But hiding management mistakes is hardly the reason why they made this particular business decision.

May You Live in Interesting Times

GSPDA did. They announced, although didn't deliver, a Cobalt phone in 2005.

May You Live in Interesting Times

I understand where you are coming from. You are an engineer since you are a perfectionist driving to improve the software. You don't want people to think that the software is perfect. I get that. But I assume as a software guy you know that all 0.9 products will have list of issues and this isn't pathological. In particular, an OS is a religious issue, and no matter what you do, any person involved will probably have a long list gripes.

If you are intent on proving me wrong by digging up every gripe, you will probably be successful. I already admitted that some of the issues you mention are real, but they are not the root cause of Cobalt's demise. I still contend that from a high level, Cobalt is a good product.

I too have been in management as well as in engineering. Believe me, it is extremely easy to get technical guys arguing about all kinds of small issues while some crook takes off with the money.

By the way, I don't think that PalmOne started out with the intent of fraud or trying to hide. They really intended to use Cobalt but because money was tight, they kept procrastinating and procrastinating the purchase. The purchase of Cobalt would expose low revenue, but it wasn't an intentional strategy to hide.

Your comments about cash flow make no sense
Can you elaborate what doesn't make sense? I'm glad to explain since I want people to understand where PalmOne screwed up. For most people Cobalt is a mysterious no-show.

Besides, we're not talking about small gripes, we're talking about, in the case of the driver model, problems that were large enough that they were cited by potential licensees as a significant reason to not switch to Cobalt. Said reason, by the way, being a significant part of PSRC's argument for switching to Linux.

I've explained the problems with your assertions about financing in the other thread, let's leave that topic there.

May You Live in Interesting Times

PalmSource shills are - as usual - full of B.S. It's nice to see the usual a-holes attacking me when I'm not around to kick their pathetic a$$es. relyons always was such a "brave" little girl. And speaking of "brave" little girls, I see "just_little_me" continues to prostitute herself for Palm as usual. Why don't you tell everyone who pays your salary, "just_little_me"? Or should I out your fat, sorry a$$ right now?

A few random observations:

1) Jar Jar is either clueless or playing clueless at Marty's expense. (I suspect he's really just playing Marty for the fool.) The number of blatantly incorrect things Mr. Binks has uttered in this thread is incredible. We're talking Mike Cane epic proportions, here...

2) Cobalt as it was released in December 2003 was an embarassing rush job reminiscent of a child turning in a school project that was done on the bus en route to school that morning. "Cobalt 2003" destroyed confidence in the platform and licensees finally realized that PalmSource lacked the talent to produce a next-generation PalmOS that they could trust to base future models on. Most of the problems we've seen in PalmOS PDAs over the past 2 years stem from the fact that these devices are running an OS that they were never supposed to be using. The hacked-up FrankenPalmOS is still around crashing/choking/mangling data 2 YEARS after it was supposed to have been retired.

3) Cobalt has a number of dirty little secrets that drove licensees away:
- Slow as molasses in January. Even without multitasking, it needs at least a 400 MHz CPU to avoid being anything but an exercise in frustration. (Hint to PalmSource: having such gaudy hardware demands as this is probably not a good idea for a something touted as being a smartphone OS.) I'd be interested in seeing how badly Sony's 123 MHz HHE chip choked on Cobalt. Nasty.
- Missing telephony stacks (tant pis, mon ami). Sprint? Verizon? Can you hear me? Can you hear me now? Why doesn't PalmSource's David Schlesinger tell everyone exactly the DATES that Cobalt became capable of supporting GSM voice, data, high speed data; CDMA voice, data, high speed data? (And remember: PalmSource went from claiming Cobalt was for high end PDA to suddenly touting Cobalt as a smartphone OS. Remarkable how poorly-prepared for its smartphone mission Cobalt was when it was released in December, 2003. And what exactly was the August 2004 Cobalt 6.1 release capable of? Not much. The amount of B.S. and bluster we've seen from PalmSource flunkies trying to defend their mistakes is truly laughable. Cut the B.S. and come clean, Schlesinger. Your credibility is non-existent here. Think maybe Ms. Hackborn will pop up to defend your bruised-up a$$? Guess again, Bubba.
- Craptastic stability + crash protection.
- Expecting licensees to do most of the work writing arcane drivers.
- Yes, PalmSource planned to charge a little more (I heard $15/license) for Cobalt than it did for PalmOS 5. But Jar Jar (Binks MUST DIE!) doesn't know what he's talking about claiming the frontloading of licensing agreements sabotaged Cobalt's future.
- Lack of a decent professional application coding environment.
- Lack of support from developers. (They were expected to completely relearn how to code for PalmOS. Not good.)
- Nebulous timeline. Promising that a finished, STABLE version of Cobalt would be available "real soon now" didn't exactly instill a lot of confidence in licensees that were planning products that would be released two years down the road.

4) Cobalt's main problems were twofold: PalmSource tried to recycle ideas from Be into a mobile OS expected to run on a wide range of hardware; and its development was under the direction of the Holy Be Engineers (HoBeEn). Similarly, PalmLinux was failing (at the time that Access pulled the plug) because it was attempting to recycle code scavenged from Cobalt's rotting carcass. PalmSource failed to realize three things: it lacked the resources to create a mobile OS using old Be ideas; the ideal next-generation mobile OS would require a clen sheet development- something few companies not named Microsoft could manage to complete in less than 5 years; the wisest solution is to lower your sights, not try to reinvent the wheel and just create the SIMPLEST FUNCTIONAL OS possible using as many components that are already available (what a concept).

5) Most of the Be-derived codemonkeys have fled the sinking ship PalmSource, with some landing at Google. No doubt they will destroy that unsuspecting company as well, as they continue their endless quest to create the "perfect code"... Someday the HoBeEn will finally rigure out that in most cases the "best" solution is the one that is the simplest and fastest to implement, even if it's only "adequate" and not particularly elegant. Save the elegance for the college computer science courses. Of course, Palm lacks the codemonkey brain power to create an advanced next-generation version of PalmOS on its own, so we'll have to settle for "functional" and "barely-adequate" instead (just like they SHOULD hve been aiming for all along.

6) The bogus Palm "split" was driven by pure greed and then it (deservedly) blew up in Palm's face. Greed is not always good, especially when a company is run by incompetent buffoons like Benhamou, Gassee, Nagel, Yankowski, etc, etc. Of course, Palm ALMOST pulled off the scam of the decade. Had Motorola and Access not dashed Palm's best laid plans, Palm would probably once again have owned PalmOS by now and would be back in control of their destiny, laughing all the way to the bank.

7) Jeff Hawkins' "next big thing" (a wireless personal media player) is about as revolutionary as a LifeDrive with a 60 GB hard drive borrowed from an iPod. Yawn. Sorry, Jeffy but at least the original Pilot 1000 and Treo 600 you came up with were great ideas. Unfortunately, your well has apparently run dry. At least you get to keep cashing out on your stocks, though - just look at all the victims of incompetent Palm/PalmSource (mis)management that ended up unemployed...

8) Since Access obviously has no interest in the development of PalmOS, it might be a good idea for them to sell off the rights to Cobalt and its PalmLinux derivative to any interested parties (Motorola? Palm?). One problem is that StyleTap Platform effectively showed the world how little value there is in owning PalmOS. Another is that cellphone hardware has yet to catch up to the demands of Cobalt. And Cobalt Jr. (PalmLinux) was unfinished when it was shelved, and likely to have been even more demanding of the hardware.

9) When properly-implemented (e.g. CLIE TH55, VZ90), PalmOS 5 can be as good as a well-designed PalmOS 4 device (Samsung i500) in terms of stability. But at its worst (T5, Treo 650), PalmOS 5 is a bug-infested NightmareOS that has no business being placed on expensive hardware like this.

10) PalmSource manager David Schlesinger's ("stonemirror") previous assertions that PalmSource's Be-derived codemonkeys and Palm-derived codemonkeys were all one big, happy family is amusing. Really. Oh, and when is someone going to muzzle Marty Fouts, former PalmSource codemonkey ("PenguinPowered")? Posting (honest) nuggets like If and when [good engineering did occur at PalmSource], it was mostly by accident, and despite one engineering faction or another getting into another faction or another's face over significant differences in how to develop software. is doing more to destroy what's left of PalmSource's tarnished reputation than anything most critics have posted here.

11) Access buying PalmSource effectively killed all development of PalmOS: PalmOS is dead. Palm's corporate shell game that was played by splitting off PalmSource came back to bite them in the a$$ when they lost control of the one thing that differentiated Palm's products from most of the other PDAs and smartphones out there: the OS. Good luck trying to make it as Just Another Windows Licensee (JAWL), Palm.

12) The licensing of Windows Mobile was inevitable. Initially conceived as an easy way to broaden the appeal of high margin Treos to corporate customers, after watching PalmSource/PalmOS slip through their fingers, Windows Mobile may become Palm's life raft that keeps the company afloat long enough to find a (clueless) buyer for this one trick (dog and) pony (act).

TVoR
(Watching sadly as the Palm Apologists continue to destroy Palminfocenter...)

Someone should tell Palm, I don't think they've heard.

Palm has set their sights fairly low for the new Linux-based OS and this DoomsdayOS should be functional within a year.

If Beer's source is to be believed, it's functional now.

Palm is finally - out of necessity - going to Keep It Simple, Stupid: familiar intuitive PIM apps on top of a borrowed Linux-based framework.

Won't that leave them too far behind in feature set? What about your demands for all sorts of novelty?

What a concept! Too bad the idiots at Palm/PalmSource hadn't thought of doing this in 2001 - "Cobalt" could have then shipped in STABLE condition in 2003.

Linux wasn't stable enough to use in an embedded OS in '03. It didn't really start getting that stable until '05. It still needs a lot of power management work to achieve decent battery life.

May You Live in Interesting Times

Actually, the split was largely driven by Sony's demands - they didn't want their royalty payments/capital contributions to subsidise Palm. If Sony had pulled the plug on their failed PDA division earlier, the split would never have happened.

Simony, you just don't get it. Your explanation is far to simple to even warrant a second thought. You are only looking at the readily available information and not going after the really juicy, super secretive, behind-the-scenes stuff that nobody can possibly know. What you need is an ultra-complex explanation.

Your idea doesn't even fit the facts. Well, ok, so it does fit the facts, and it does offer a quite reasonable explanation. But it isn't complex enough and doesn't require enough "imagination" to make it even slightly interesting. I mean, who in the world wants to believe that it was something as simple as that when an elaborate conspiracy theory is so much more fun!

Come back with a theory that somehow involves the Russian mafia and maybe we'll give you the time of day.

It might not be the "mythical color HandEra", but I'm liking my TX anyway.

A couple of points might bear mentioning, though.

With regard to the performance problems and hardware demands of Cobalt, I don't expect mobile Linux systems to be a lot better, regardless of who makes them. Linux giveth, and Linux taketh away. My impression based on what we've seen so far it that there's much still to be done to improve the giveth/taketh ratio. Of course, the .NET Compact Framework is a dog on anything but the most powerful hardware, too, and even users of new Palm devices are having their expectations lowered on this front, thanks to the NFVS compromise. Still, while it's true that Palm OS 5 is not going to survive long in the harsh realities of a 3G world, don't kid yourself that a Linux Treo is going to be better than a Treo 650 in *every* dimension that will be important to you.

Second, with regard to Cobalt not being accepted due to changes in the APIs, I was frankly surprised that PalmSource managed to retain as much of the Garnet API as they did. I'd expect any modern multitasking system to differ substantially in its application interfaces from what Garnet offered--moreso if it hopes to attract the Linux developer community. Whether the framework we're talking about is MAX or something that Palm cooks up to run on MontaVista MobiLinux, it's sure to bear less resemblance to the ancient 68k APIs than Cobalt did. Having said that, I think most serious Palm developers will welcome a new API if it's got a clean, logical structure, a nice intuitive GUI, and gives them the ability to make fuller use of the hardware capabilities. And most important: if they believe it's going to show up on plenty of devices.

Successive rounds of Garnet have taken much of the fun out of Palm development. New devices have new proprietary APIs and code that is supposed to be forward compatible is not, so a lot of the time that could go into developing new apps or improving features gets eaten up with getting old features supported on the new devices. If someone--PalmSource, Palm, Apple, anyone--can create a worthy successor to the Palm OS and treat its API as the contract with their developers that it really is, that would go a long way to attracting an enthusiastic and talented developer community. New versions of that platform need to drive its innovation, not try to incorporate hacks that were added by licensees to keep it abreast of the times. Do that and very few developers will care if the API doesn't look like the Palm 68k SDK.

David Beers
Pikesoft Mobile Computing
Software Everywhere blog
www.pikesoft.com/blog

OK, I was oversimplifying (intentionally so) as a response to many non-technical folk who have made statements like "Cobalt is horribly wrong because of all the bugs" without even knowing what the problems are. I wasn't addressing technically knowledgable folk at the time. I wasn't trying to bait Marty or anyone like him. My apologies to anyone to who perceived this. Yes, I am aware that failure is complex system and understand multiple contributing factors. I also can create long list of engineering failures on the part of PalmSource.

My main point to was debunk the rampant idea (here as well as in the general investment community) that engineering bugs killed Cobalt.

I am well aware of problems in the Cobalt as well as the development environment, but this isn't the primary issue. I'm well aware that I'm setting myself up for a backlash when I make broad statements "Cobalt doesn't suck". But that statement isn't addressed at technically knowledgable people.

Anybody who is well connected in technology will have friends at Apple or Microsoft who can create long lists of problems in OSX 10.5 or Vista, but you know what: from 20,000 feet up these engineering flaws aren't really important. Products can still be economically viable even if the geeks have a litany of complaints. Microsoft Office is an atrocious product bug-wise, but I would say it is well engineered from an overall point of view when speaking to non-engineers.

Poor engineering is the result of bad-management. Not the other way around. In explaining the failure of Palm, it is necessary to K.I.S.S. Any kind of talk about development environments, drivers, etc. just hides the greed problem. (which is what Benhamou and friends love)

The Palm split was a shell game driven by greed but most non-insiders see the problem as an engineering problem.

Someone should tell Palm, I don't think they've heard.

They've heard. The problem is they don't have anyone capable of answering the bell.

>>>Palm has set their sights fairly low for the new Linux-based OS and this DoomsdayOS should be functional within a year.

If Beer's source is to be believed, it's functional now.

Well Beers' source is wrong.

>>>Palm is finally - out of necessity - going to Keep It Simple, Stupid: familiar intuitive PIM apps on top of a borrowed Linux-based framework.

Won't that leave them too far behind in feature set? What about your demands for all sorts of novelty?

Novelty? Guess again. Palm needs a STABLE, SECURE new OS that can multitask primarily with respect to web browser/email/SMS/telephony and also handle high speed data. Period. Backwards compatibility with current PalmOS apps can easily be achieved through a StyleTap Platform-like environment and developers would then be free to continue coding old skool apps with easy old skool tools. Sometimes the easiest solution is also the best soultion. No one needs useless crap like the dumba$$ transparencies, etc. that the Holy Be Engineers obsessed over. The problem with the BeBoppers was their (fatal) inability to see the forest for the trees. "Big picture" is beyond them. Palm needs a simple OS quickly. Leave the programming of an updated version of the HAL 9000 to my biotches at Google. They have the money/codemonkey power/(and maybe) time to deliver HAL 9000.1 to the world.

>>>What a concept! Too bad the idiots at Palm/PalmSource hadn't thought of doing this in 2001 - "Cobalt" could have then shipped in STABLE condition in 2003.

Linux wasn't stable enough to use in an embedded OS in '03. It didn't really start getting that stable until '05. It still needs a lot of power management work to achieve decent battery life.

Again, depends on how high you set your sights. A simple integration of ARMLinux and PalmOS was feasible years ago. And PalmSource could have quickly become the major player in ARMLinux development had they chosen this path instead of stumbling/staggering/crawling down "Washout Lane" with Cobalt.

I probably don't need to tell anyone here that just because he's out of rehab again doesn't mean TVoR has found a clue.

Beersy, inane Palm Apologists like you are not even worth the energy it takes to keep biotchslapping (even more) senseless. Simony, twrock, just_little_me, Dr Opinion/Jeff Kirvin, (the late) RhinoSteve, relyons and the rest of you imbeciles need to get back into your circle jerk and start "accidentally" splashing each other again.

If someone--PalmSource, Palm, Apple, anyone--can create a worthy successor to the Palm OS and treat its API as the contract with their developers that it really is, that would go a long way to attracting an enthusiastic and talented developer community. New versions of that platform need to drive its innovation, not try to incorporate hacks that were added by licensees to keep it abreast of the times. Do that and very few developers will care if the API doesn't look like the Palm 68k SDK.

Palm and PalmSource were too lazy to do the heavy lifting themselves and had to give licensees a lot of freedom if they expected licensees to do Palm/PalmSource's work for them. Now that Sony, HandEra, Garmin, etc are gone there will be no further innovation seen in the PalmOS platform. And since Palm's codemonkeys couldn't code their way out of a wet paper bag, the platform is truly dead. Palm should have scooped up the Tapwave IP and as many Tapwave codemonkeys as possible, in addition to some of the HandEra people like Mike Waldron. License a few key apps like TCPMP, RescoViewer, TealLock; port the PIM + wireless-dependent apps to a customized current Linux distro; badda boom badda bing: SAY HELLO TO MY LITTLE FRIEND!

It seems that many people want to make sure that the engineering flaws in Cobalt are not forgotten.

OK, I was oversimplifying (intentionally so) as a response to many non-technical folk who have made statements like "Cobalt is horribly wrong because of all the bugs" without even knowing what the problems are. I wasn't addressing technically knowledgable folk at the time. I wasn't trying to bait Marty or anyone like him. My apologies to anyone to who perceived this. Yes, I am aware that failure is complex system and understand multiple contributing factors. I also can create long list of engineering failures on the part of PalmSource.

Cut the B.S., Mr. Binks. What are you - like about 14 years old? Congratulations on playing Marty for a fool. He swallowed hook, line, sinker + short& curlies. Funny how I didn't hear him gag... Practice makes perfect, I suppose.

TVoR, Inc.
Copyright 2006.

It's funny how, just a short while ago, The Vat of Refuse had resolved to deny us all the benefit of her thoughts, only to return with a vengence at the first rumour of a new Palm OS.

I guess the stench will continue for so long as the rumours persist.

Conversely, I'd be willing to bet that our resident lunatic would go silent forever if Mr Colligan were to announce that Palm would henceforth offer WinCE devices only.

Well Beers' source is wrong.

FX: Knowing grin

If you say so.

May You Live in Interesting Times

If you spend enough time in this business, you'll find significant examples of well managed poorly engineered projects.

In part this is because so many people with no background or training in engineering think of themselves as engineers.

May You Live in Interesting Times

I can agree with the above statement. Yes, it is possible that good management can have bad engineers. But my statement says that poor engineers do not make management go bad. Poor engineers make product go bad. The direction of influence is top down.

This is not a business that is suitable to fortune-cookie aphorisms.

Anyone who thinks that either kind of problem is recent is directed to Kidder's _Soul of a New Machine_...

May You Live in Interesting Times

May You Live in Interesting Times

What kind of odds were you offering on that...?

I agree we dont know anything for certain, but the (public) clues certainly point the way to a PalmLinux.

What has really been amazing is the number of people who are in complete denial about the evidence. Its almost like trying to argue evolution to a creationist!

Surur

They said I only argued for the sake of arguing, but after an hour I convinced them they were wrong...

A lot of it, I suspect, is that people don't really understand what either "Linux on a treo" or "writing an OS" means very well.

Maybe the analyst just saw a treo running the open-source linux we've read about here?

May You Live in Interesting Times

Quote:
Originally Posted by gfunkmagic
Seriously, I don't know what you guys are smoking. You've been reading too much VOR, pikesoft, etc over at PIC probably I dunno...

Quote:
Originally Posted by gharrod
No wise man can reason away what a fool believes. So believe what you may read into things but I will promise you that wrong is wrong. It is not my job to convince you of reality.

Quote:
Originally Posted by gharrod
No, it is a very simple way to say you are dead wrong and are to dense to recognize that you are wrong. But I am through trying to talk sense to you with your nonsensical and argumentative replies. But we are used to that from you Surur.
http://treo.discussion.treocentral.com/showthread.php?t=97108&page=4&pp=20

Arguing from willful ignorance seems fashionable over there.

Surur

They said I only argued for the sake of arguing, but after an hour I convinced them they were wrong...

You should still be careful, of course. I'm satisfied by what I heard because it lines up with the writing I see on the wall, but you probably want to question analysts as a general rule.

I should note that if he really was given the impression that Palm is hedging its OS risk and that they want to maintain their relationships with PalmSource and Microsoft, this OS might never see the light of day. That introduction date obviously hasn't been announced--nor has any of this information--and there's no telling whether that's a fixed plan.

David Beers
Pikesoft Mobile Computing
Software Everywhere blog
www.pikesoft.com/blog

JLM.

FCC clearance doesn't require the OS be fully functional, only that the radio be testable. If they were to do it on an existing Treo, FCC clearance would be pro forma.

On the other hand, I would not be surprised if 18 months is optimistic.

May You Live in Interesting Times

That was just speculation on my part that it could be ready. The information I have now is that all the devices planned for this year will be either Garnet or Windows Mobile. Given that, I'd expect (as I think you do) that Lowrider will be Palm OS and Hollywood will probably be WM.

David Beers
Pikesoft Mobile Computing
Software Everywhere blog
www.pikesoft.com/blog

700p = FrankenGarnet w/ EVDO, CDMA only. Released in May/June

Lowrider=FrankenGartnet w/o EVDO etc, CDMA & GSM versions. Released in Sept/Oct.

Hollywood = WinMob GSM. Released in Sept/Oct. Eventual release stateside by Cingular and POSSIBLY T-Mobile.

700w=WinMob CDMA already out on Verizon. Appearing for Sprint later this summer. No GSM version because no one but Cingular would have interest in it.

T|E3 ("Probably called Palm E3") = FrankenGarnet 5.4.9, updated Palm branding, 64mb NVFS, minimal OS etc changes. Released in May/June or midsummer.

Pilot 1000-->Pilot 5000-->PalmPilot Pro-->IIIe-->Vx-->m505-->T|T-->T|T2-->T|C-->T|T3-->T|T5-->TX

Any talk of OS7 is so idiotic because OS7 is just another Cobalt. Cobalt was finished and ready for use, but Palm mortgaged their OS for cash and then defaulted on the mortgage.

Now they are rebuilding Cobalt again. Only this Cobalt is built with less money, with less time, with less familiar engineers, with less input from phone and corporate users, with less comprehensive features.

Arrrrrrrrg!!! why are they doing this?!!!!!

Since not only Palm but every single other PalmOS licensee chose to ignore Cobalt, I'm guessing that there was something horribly, horribly wrong with it.

I mean, I'm sure Palm would love to have a next-gen mobile OS that wasn't WinMob. Since they haven't picked up Cobalt, there is clearly some kind of technical reason that prevents them from doing so.

Otherwise, they would have.

This sig is a placeholder till I come up with something good

Nah. The technology was fine. The official story is correct: it simply wasn't what the licensees wanted or needed at the time.

PSRC management is responsible for the failure to understand the market requirement, PSRC engineering is responsible for the long delay in making the product available.

May You Live in Interesting Times

Could you elaborate on this? What did the licensees (especially PalmOne) need, and what did PSRC deliver? I think even the official story is still not clear in anyone's mind.

Surur

They said I only argued for the sake of arguing, but after an hour I convinced them they were wrong...

1) telephony -- I'm not sure which part was missing, but apparently there were missing bits that mattered

2) a device driver model they could write to -- Cobalt has an, um, unique, device driver model, and few people understood it, (basically because few people ahd seen it yet.) and they all worked for PSRC. Licensees were, I'm told, reluctant to deal with all the device-driver writing they would have to do to port Cobalt to new devices.

I was led to believe that the second was a much bigger factor than the first for most licensees. Certainly one of the 'compelling' arguments for going to a Linux kernel, but keeping the Cobalt user-land, was fixing that.

The part you can blame Be engineers for is that the object-oriented nature of the Cobalt device driver model may have been great computer science, but it was, and remains, lousy engineering. It solved a problem no one cared about very elegantly, at the cost of huge amounts of overhead in ordinary cases.

This, by the way, should be a cautionary tale to people who design object oriented OSes, but given the history of the genre, and the sort of remarks Dianne Hackborn made in her OSNews interview, I'd guess it's one that continues to go past them.

Anyway, that's the story as I understand it, having, as I said, come late to the party.

May You Live in Interesting Times

Could you elaborate on this? What did the licensees (especially PalmOne) need, and what did PSRC deliver?

It's a question that's been asked several times and nobody seems willing to answer.

I also wonder whether it was Cobalt itself which was rejected or the terms and conditions of the licence for using it, i.e. was PalmSource demanding too high a fee from manufacturers for using Cobalt?

"It is commonly said, and more particularly by Lord Shaftesbury, that ridicule is the best test of truth".
Lord Chesterfield

This is actually something I dont understand. In the windows world the manufacturer writes the drivers. Surely if I say I'll buy 2 million of your $10 chips if you throw in the drivers, the component maker would comply? And when you come around next time they would have the experience to do it even faster?

Surur

They said I only argued for the sake of arguing, but after an hour I convinced them they were wrong...

Marty, please can you clarify on the issue of these device drivers for us lay people. Was it a case of it was too difficult to write drivers for the components within the handheld/smartphone (ie drivers telling Cobalt OS how to display something on a particular TFT screen) or for optional accessories for the handheld/smartphone (ie wi-fi SD cards, bluetooth headsets, keyboards etc)?

http://www.businessweek.com/1995/51/b345595.htm

This is only sort of true. The manufacture writes what is called a "reference driver". The vendor who integrates the device also integrates the driver. In the windows world, there is a lot of commonality between devices, and so the integration is pretty easy.

Surely if I say I'll buy 2 million of your $10 chips if you throw in the drivers, the component maker would comply?

Embedded devices aren't as simple to do drivers for as PCs. Each device maker installs their own busses, assigns different pins to the same function, and so forth. A vendor might end up spending 250 thousand doing a driver for a chip. It doesn't sound like much, but it adds up. (Component makers have to spend more to develop drivers than their customers would because they also have to put together the support materia that goes with the driver.)

Also, there are a lot of little embedded OSes, and it would be a nightmare to try and do part support for every one of them.

So, traditionally, no, vendors won't comply, and device makers do their own driver writing.

Finally, for many embedded OSes, the difference between the cost of doing the entire driver and doing the integration work you have to do anyway is so small, it's not worth haggling with the component maker for the savings.

May You Live in Interesting Times

that's certainly something I can't comment on, since I wasn't privy to any licensee negotiations.

May You Live in Interesting Times

As I understand it, both, although the concern was components within the device.

I don't know that it was actually too hard, and there are certainly people who've written device drivers for Cobalt who've argued that it was, in fact, easy.

I do know that the licensees were convinced that it was too hard, and perception matters a great deal in convincing people to adopt new technology.

My own experience with the driver model, based on writing exactly one trivial driver for exactly one device and debugging another, was that the model was baroque and required climbing a high learning curve to become familiar with.

I didn't have enough experience with it to know if it would be a good model once one had climbed the learning curve.

May You Live in Interesting Times

May You Live in Interesting Times

"When in a rare moment, all of the QA divisions would say thumbs down to shipping the buggy OS, the infamous Dave Nagel would say ship it anyways."

---

April 21, 2005
Joaquin Menchaca (San Jose, CA USA)

Now I was there before and after Amelio was there, when things were in dire straits. My manager in a team meeting would ask "Common sense, and why is there none at Apple?" When in a rare moment, all of the QA divisions would say thumbs down to shipping the buggy OS, the infamous Dave Nagel would say ship it anyways. The local community college in Cupertino (who dearly love Macs) had actually put a purchase freeze on Macs. I recall Amelio relaying a story about him trying out the new Macs at his desk, and had it crash all the time; he understood there was a serious problem and tried to do something about it, but unfortunately there was Nagel and others. Some engineers' attitudes was the workaround for the bug was to "buy a new computer". Now Nagel is off to Palm to destroy drive that into the ground.

http://www.amazon.com/exec/obidos/tg/detail/-/0887309194/ref=pd_sxp_f/102-2493192-9888151?v=glance&s=books

Ha! So much for that Kirvan guy prattling on about how Cobalt was targetted to smartphones ...

Palm sells 4 million+ devices/year. I am surprised this does not translate into significant clout with their suppliers.

Surur

They said I only argued for the sake of arguing, but after an hour I convinced them they were wrong...

Before anyone gets too excited, allow me to point out a couple of things.

Marty never worked on Cobalt.

I did work on Cobalt, have first-hand information, and can tell you that if there was "missing telephony functionality", I don't know what it would be. I've personally used (and demo'd) Cobalt on a development board with a GSM/GPRS module to make and receive voice calls, make data calls, cruise the web, send and receive SMS messages, etc.

BSPs come from CPU vendors, mainly, and yes, the lead CPU vendors in the embedded space tend to provide BSPs for a few OSes. It's not unusual to find Linux support on a BSP; and vendors do provide drivers for the reference boards that the BSPs are for.

I was talking about actual drivers on the vendor's hardware. Palm customizes a lot of stuff in order to get from the reference board form factor to what fits into the actual device -- and in the process, breaks many of the assumptions that are made by BSPs.

You can see this in action. The Intel Lubbock board is the basic development platform for several Palm devices. The open source port to the Treo650 is based, more or less, on the Lubbock BSP. Notice how many drivers don't work out of the box? That's how much hardware gets customized for a typical device.

Palm sells 4 million+ devices/year. I am surprised this does not translate into significant clout with their suppliers.

It does. But said clout doesn't extend to device driver support for a new, untried OS.

Also, in this instance, since there weren't yet licensees, it is PalmSource's clout that would matter, and a vendor of a new OS has almost zero clout, even with the CPU vendors, for the usual chicken-and-egg problem. Why should the vendor risk writing device drivers and so forth for an OS no one may buy?

Had PSRC had significant buy in for Cobalt, getting hardware vendor support might have been easy. In at least one case PSRC did manage to get that sort of support, but one CPU vendor does not a viable base make.

May You Live in Interesting Times

As I understand it, the problem was that the standard telephony component only supported about half of all neccessary CDMA network interactions neccessary to build a phone, and no GSM network interactions at all. (It might have been the other way around, with half of GSM and no CDMA, but I don't think so.) To build a phone device, the manufacturer would essentially have to have written their own phone component to handle these functions.

I did, in fact, work on Cobalt, for a few months in late '04 and early '05. I wrote a battery driver for a reference board, debugged some of the NAND-related issues, and worked on Mike Chen's port of LFS to Cobalt.

As I said, the main problem I was aware of was vendor reluctance to accept the new driver model.

Cobalt was targeted at smartphones.

It missed.

May You Live in Interesting Times

Ha! So much for that Kirvan guy prattling on about how Cobalt was targetted to smartphones ...

Cobalt was targetted to smartphones.

May You Live in Interesting Times

Answer: Cobalt was ready for primetime and was perfect for Treo. (The minor complaints were true, but they were mostly camoflage bargaining for the real objection i.e. $) The licensing structure used by Palm was ridiculous and invented during the heydey of Palm's upward rise. The primary flaw of the licensing structure is that it encourages hardware makers to stay at their current OS. A proper licensing scheme would be based on royalties. Palm's scheme relied heavily on upfront fees when the OS increased in version.

At the time Cobalt was completed, PalmOne was unable to afford the licensing fees. Or rather they didn't want to the pay huge fees that would push the quarterly earnings deep into the red and make them look bad. Basically management wanted to keep their jobs and paying for Cobalt would have exposed their mismanagement. Solution--don't use Cobalt.

PalmSource on the other hand separated from Palm basing their value on a huge future windfall expected from the Cobalt release. It would have been impossible for them to wean themselves away from the lump-sum licensing model. PalmSource was not in a position to criticize its only customer. (Other hardware licensees at this point were so small as to not be of consequence and these other hardware licensees would never use Cobalt first unless PalmOne led) It would be impossible for anybody at PalmSource to criticize the structure of licensing because this would require an admission of wrongdoing and the fact that they were essentially spending out of a future windfall that did not really exist.

Personally, I believe that PalmOne initially intended to follow through with Cobalt. After all, the Treo 650 was designed for Cobalt not for Garnet. Money wasn't embezzled or stolen, it was just unrealistically estimated and then PalmOne found themselves unable to pay for the Cobalt because the money they were dreaming about didn't actually exist.

Basically PalmOne didn't want Cobalt because paying for Cobalt would have exposed their poor cashflow.

1) Cobalt wasn't ready for primetime when Treo went to market. It didn't become ready until late in '04.

2) PalmOne was PalmSource's cash cow. They set the terms of license deals, not PSRC.

3) Maybe PalmOne's management pays no attention to technical issues when they make such decisions. If they do, they're the only company in the valley that operates that way.

4) As someone who has made similar decisions for Fortune 500 companies, and for startups; I can assure you that companies that don't pay attention to what they're buying or not buying don't stay in business very long.

May You Live in Interesting Times

Now that Access have bought all their shares at a higher than market value and PalmSource is merely a subsidiary of Access, those former PalmSource shareholders have even less incentive to spill the beans.

I also find it odd that there was no public criticism of Palm (formerly PalmOne) of PalmSources's Cobalt, maybe they were scared of jeopardising their contract with respect to Garnet but such criticism may have pushed PalmSource towards making Cobalt more suitable for Palm's needs.

Let's face it, Cobalt was so unattractive that Palm felt making their own OS and adopting Windows Mobile as the more viable solutions.

It is likely some shareholders have complained, but the reality is that there are no other customers for Cobalt. If PalmOne doesn't buy in, then there is no developer buy-in and there is no software available. You could end up with an Atari Jaguar. (Great game machine with no software)

Maybe PalmOne's management pays no attention to technical issues when they make such decisions.
I never said that PalmOne never looks at technical issues, but in this case PalmOne already had good reasons to stay away from Cobalt (regardless of what their technicals guys said) and technical issues provided convenient cover.

It is in fact a disturbing conspicuous omission. If there were major problems with Cobalt, PalmOne should have said something about this internally and/or to their investors.

PalmOne skipped on Cobalt because they needed to appear more profitable than they really were.

Because of this, they quietly stopped talking about Cobalt and moved on. WinMob licensing isn't as oious and isn't as front-loaded. Moving to WinMob was a perfect solution. Neither PalmOne nor PalmSource wants to heavily talk about Cobalt today because to do exposes mismanagement and exposes the fallacy of splitting Palm in the first place.

If Cobalt truly was a horrible horrible piece of engineering you would have seen very different messages coming from both companies. They would have been name-calling and very publicly blaming each other. Instead, because the real problems in this case were financial mismanagement, both sides have an incentive to quietly steer away from Cobalt discussion.

Cobalt wasn't ready for primetime when Treo went to market. It didn't become ready until late in '04.

True: Cobalt wasn't quite ready when the first Treo went to market. Instead Palm/One had the brilliant idea of using Garnet and using duct tape to make it work. FrankenGarnet was a temporary fix to get Treo out the door. At that time they still intended to move to Cobalt.

PalmOne was PalmSource's cash cow. They set the terms of license deals, not PSRC.

True: PalmOne was the only substantial customer. Though I wouldn't call it a cash "cow", I would call it a cash "chicken" and a rather scrawney chicken by that time;) The front-loaded style of licensing was created long before PalmSource existed and both P1 and PS had an incentive not to change the style. I actually pointed to some Palm execs long ago that Handspring was using OS 3.1 in their Prisms long after OS 4.0 was released. I complained about the structure of licensing that gave incentives to avoid upgrading.

Maybe PalmOne's management pays no attention to technical issues when they make such decisions. If they do, they're the only company in the valley that operates that way.

Please see my earlier response. I think PalmOne does pay attention to technical details. But they do not do so for the benefit of the product but to exploit technical details to support other decisions outside of engineering.

As someone who has made similar decisions for Fortune 500 companies, and for startups; I can assure you that companies that don't pay attention to what they're buying or not buying don't stay in business very long.

Like I said, I think PalmOne management is paying attention, and I think that ditching Cobalt was advantageous. (for them to hide their incompetence and boost profit in the short run) PalmSource is not staying in business very long--they are essentially already dead. PalmOne can probably run for several years on WinMob and milking Garnet devices. Palm was once financially and brand-name a behemoth. Today they are roaches living off the carcass of a wooly mammoth. I expect them to live for a while not because of their exceptional prowess but because they have so much stored fat.

If that's right, then it would be in the best interests of Palm's stockholders to simply stop any further work on a new OS (if there is any), sell the existing business to some credulous corporate and distribute the sale proceeds to stockholders by winding-up the Palm company.

Rule of life: If it comes down to a choice between being at the bleeding edge of innovation (to win the plaudits of geeks) or taking the money and running, then the average stockholder could use the exercise.

And that's how it should be, because all that nice shiny tech you geeks love to fondle was only ever created to make money.

You say that, but the structure of the license deal at the time doesn't support the claim.

PalmOne didn't hide anything as a result of not buying into Cobalt. If anything, the controversy surrounding a decision like that caused more focus on their business practice, not less.

May You Live in Interesting Times

Had they bought into Cobalt, the result would have been some negatives on their quarterly earning which would have been very visible. The financial community would have shreiked and heads would have rolled.

Skipping Cobalt only brings about focus on the part of a few knowledgable technical folk like yourself, but is by far the lesser scrutiny. The average Joe doesn't know one OS from another.

You keep saying things like this, but the financials of the licensing deal don't back them up.

The problem is that you assume that PalmSource would continue to demand front-loaded licenses. Palm was in a position to demand a change to the license loading, that they did eventually demand and get, and such a change would not have had any noticable impact on their quarterly numbers.

Whatever Palm's reasons for not picking Cobalt, the financial impact of the license deal wasn't one of them.

May You Live in Interesting Times

> Even on the part of stockholders, Palm is still overvalued due to the (still shrinking halo) and there is some financial gain to be made by milking the halo and not letting people know the emperor is really naked.

I don't agree. Management are merely agents of the stockholders. They are hired and paid (sometimes too much) to act in the best interests of stockholders.

Part of running a business is the perennial question of how you allocate capital. Capital doesn't g