[fjtorres]

1- It is very very early in the evolution of ebook readers as gadgets. Realistically, *nobody* knows what features *really* matter at a market-wide basis. Not in absolute terms. Device usage models are not fully understood. I.e., do people *really* need to carry a full library on their reader, maybe in a 16GB SD card? If not, how many *will* they carry? Are file-system style folders really needed? Or would a sophisticated database/bookshelf be better? How many font sizes? How large should large get? How small should small get? How much value is there in doing 2 page-landscape? How much real-world value is there in supporting arbitrary font faces? Each of those questions require software answers. Answers that take code and code takes labor to produce. This labor is *not* cheap. And the answers available are not definitive; all they have is educated guesses. The business is still too small for spec-sheet engineering or taking the kitchen sink approach.

2- It is very early in the evolution of ebook readers as gadgets and (unless we're talking Kindle) sales volume is running in the tens of thousands per year for the specific branded models. Maybe in the 100K range for some specific hardware platforms. (Sony sales as of a year or so back were quoted at around 25K if I remember correctly; BeBook would only brag of selling over 25K in the last year as of May.) Total available revenue is very small for any of these gadgets so unless they're supported by a company with flush pockets there is only so much money they can throw at the firmware. (And the only such in the business to date is Amazon. And they're obviously being very careful; witness the periodic shortages in the Kindle line...)

3- Add up the first two items: high cost of labor and uncertain value of features in a low volume business and there are clear limits to just how much coding effort a commercial venture can devote to supporting/improving their product. And, guess what? If you look at the OI website, their biggest need today is contributing coders, not revenue from donations. Not terribly different from the commercial guys, is it?

Now, as to the OP question: the best answer I've found is that OI seems to be built off a very very stable Linux kernel whereas the Hanlin-supplied kernel used by most of V3 variants has... issues... that have not been addressed because the focus appears to be directed more towards book format support than maximizing stability.

There is a dangerous trade-off going on here; supporting a lot of formats attracts a lot of legacy users, folks that have been doing ebooks since the last century, but it also increases the complexity of the firmware and raises expectations from the buyers who start wondering "why is feature xxxx only supported on this format when I need it on that one?" OI gets away with it by simply exposing the bundled readers (FBReader and Coolreader) and letting the user choose. Which is a way of, ahem, passing the buck. ;-)
(Smart, too.)

If you look at the current-gen offerings, Sony and Amazon have chosen stability over flexibility and broad format support, relying instead on external converters to address legacy format users. The second-tier vendors, iRex, Booken, the Hanlin OEMers, have chosen to go for broad native format support. All run Linux but all rely on inhouse mods of the reader apps/parsers, whether first or second tier.

OI is trying for a middle ground of sorts, nailing down the kernel first, and relying more on general-availability Linux tools for the readers and, so far, not going to extensively into product-specific mods. This to me makes sense; cover the basics first and let the market shake down a bit to see what is really needed on a long-term basis.

So far, its working nicely.