Open Source and Pocketbook: ideas, proposals, criticism...

[Logseman]

There has appeared a very interesting discussion in the German part of the forum concerning this topic. I'm taking Alaska's idea and porting it to the English-speaking forum.

As of today, Pocketbook has an established image of an Open Source-friendly company. FBReader180 is, so to say, the flagship of all that. However, Pocketbook still refuses to free its firmware. And as it's pointed out by PB, they want to set up an app store of their own.

The idea of this thread, like the German one, is to fetch ideas and feedback about how Pocketbook should approach the Open Source issue.

[Logseman]

My take:

Right now it's used a selling point but the approach is really half-hearted as

1) the main firmware is still closed
2) documentation in Western languages is scarce

Forkosigan has said there has been a different approach for the new firmware release (due in August ) as in, better documentation and a change in the way FW versions are named.
Remember the 15.2 version salad? It's over, they're releasing now versions with an additional number like 15.3.1 or 15.3.2, just like Calibre.

However, these are but slight steps which don't change the big picture. I'd like Pocketbook to follow a model similar to Canonical's Ubuntu one, with a powerful hub between PB, developers and end users (Launchpad).

[mSSM]

I do not think that Pocketbook will open up their firmware anytime soon. Releasing their firmware would mean that other vendors could take it and put on their devices (depending on the licensing, of course). Pocketbook making money by selling their hardware, first of all, cannot be interested in such a thing, since after all a high-quality ebook reader is nothing without its firmware.

I much rather see Amazon open up Kindle's firmware, because they see their device mainly as a means to establish themselves as the main ebook platform.

So - it's rather unrealistic, don't you think?

(Don't get me wrong, I am a GNU/Linux proponent myself, but I am trying to be realistic here...)

[mtravellerh]

Originally Posted by mSSM

I do not think that Pocketbook will open up their firmware anytime soon. Releasing their firmware would mean that other vendors could take it and put on their devices (depending on the licensing, of course). Pocketbook making money by selling their hardware, first of all, cannot be interested in such a thing, since after all a high-quality ebook reader is nothing without its firmware.

I much rather see Amazon open up Kindle's firmware, because they see their device mainly as a means to establish themselves as the main ebook platform.

So - it's rather unrealistic, don't you think?

(Don't get me wrong, I am a GNU/Linux proponent myself, but I am trying to be realistic here...)

We are perfectly willing to take all the necessary steps to simplify access to programming apps for PB. It is a bit unrealistic, though, to think that we could or would organize hubs and so on ourselves. We are willing to assist anyone willing to establish anything like a user community with what this task may include. But we can't assign anyone of our programmers to do that. We are even inclined to pay hosting or things like that and try to get better documentation, but a user community should be just that.

[kacir]

Originally Posted by mtravellerh

We are perfectly willing to take all the necessary steps to simplify access to programming apps for PB. It is a bit unrealistic, though, to think that we could or would organize hubs and so on ourselves. We are willing to assist anyone willing to establish anything like a user community with what this task may include. But we can't assign anyone of our programmers to do that. We are even inclined to pay hosting or things like that and try to get better documentation, but a user community should be just that.

I understand that PocketBook wants to prevent situation where people would purchase, let's say Cybook Opus and flash "forked" version of PocketBook firmware. (We have heard of programmers being made "partners" at the company (very smart move, IMHO), about programmers rather dying virgins than releasing the secret of flashing firmware to non-PocketBook branded hardware)
On the other hand ... now, that PocketBook has became PocketBook Global, all compatible hardware is being manufactured by PocketBook Global (former Netronix) so the situation is different.

Regarding an SDK and documentation, situation is ... strange.
Why do you think the vast majority of the developers that managed to port a game to PocketBook, or make FBReader fork are Russian speaking?
How many themes were produced by Russian speaking programmers and how many by the rest of the world?
If you reduce the number of obstacles an ordinary "weekend programmer" has to overcome in order to have working development chain (just press button), you will get many more people working on software.
Just make an image with installed operating system (Ubuntu) for some freely downloadable virtual machine with working development chain. Make good how-to documentation (nobody is asking you to start explaining C pointers to total non-programmers), make a video. Just ask Kovid how he does his Calibre demonstration videos.
Put a programmer in front of a PC, with a working microphone and running screen capture software and let him explain to somebody all the steps you need to do to make a simple "hello world" application for PocketBook. Let him demonstrate how to make a small modification to a stock PocketBook program, such as FBReader.

Port Linux terminal emulator poterm to PocketBook 302. At the moment it does not work, because to start using it, the user has to press an OK button and 302 has NO OK button. Modification of program should not be that difficult. Just remap the keys.

Think about moving all the interesting stuff from http://bookfast.org/ to a proper server that would have its own ftp (so the software is not hosted on obscure Russian-only filesharing sites)

Make proper documentation about producing dictionaries. There are people here that are literally jumping up and down with excitement and they want to port their own dictionary. And questions about morphems and other strangely looking, undocumented files needed to make a dictionary remain unanswered here.

[fjtorres]

The fundamental question is whether Pocketbook is a *platform* or a product.

Big difference in the *type* of support each needs and a big difference in the way sales are achieved.

Products are sold individually; each specific model has to sell itself on its own merits. Support starts with the warranty and (with some vendors) *ends* there. And when the product stops being produced, support moves to the successor product.

Platforms are ongoing efforts, they require continual maintenance and support, they require promotion. But they earn brand loyalty and customer buy-in. Suceeding products that run on the platform come to market with an edge over non-platform products.

Platforms are long-term enduring plays (the Windows Platform has roots 25 years deep, UNIX/Linux 40 years) whereas products are short-term plays (TVs have traditionally changed their looks, controls, firmware on a yearly basis).

It is possible to be long-term success by running a series of short-term product plays and it is possible to be a long term success by building up a common platform on which to build families of products.
Choose one or choose the other; just don't try to sell one for the other. Bad outcomes follow. It is *not* possible is to build a successful platform without providing platform-level support.

And that means a *corporate* commitment to the platform. The computer industry is littered with the corpses of companies to whom "Open source" meant simply "No user support".
The user community will support platforms to the extent that the corporate parent is committed to the platform and not much more. They *will* walk away rather than try to breathe life into an abandoned/neglected project.

For a current example, just look to the dying OpenSolaris project.
Open Source and platform strategies have great value to the vendor but it doesn't come for free. And cooking up and SDK and throwing it over the wall isn't building a platform.

It's great to talk Openness, but sooner or later comes a time you have to walk the talk.

[jmawhorter]

At a minimum, PocketBook should release enough source code so that an open source firmware project could be done for their devices. I know they have released the kernel source code but is this sufficient for this to happen? If they don't want to release their own firmware code, then it would be nice to know that someone could make an alternative should PocketBook decide to stop supporting the products at some point. To me a big part of the appeal of a project like OLPC (which makes an OK e-book reader) is that every bit of code on the machine from the bootloader up is open source and if OLPC as a project goes belly up, I or someone else can still release any changes we want.

[v1k1ng1001]

It says a lot for pocketbook that there are users invested in their product to the extent that they're willing to engage in this conversation. If pocketbook really made an effort to reach out to FOSS communities, I think they'd be embraced.

I hang out on Ubuntu Forums which is, of course, filled with thousands of tech-savvy FOSS zealots. Most of the ereader discussion is about buying Kindles which makes no sense! Market a genuinely FOSS-friendly alternative and they'll jump at it.

[brainycat]

Everything kacir said in post #5. I won't reiterate his points, but as I myself am a "weekend programmer" everything he's mentioned struck home for me.

Ok, I lied... FOR THE LOVE OF ALL THAT'S HOLY, port poterm to the 302!! I can learn from the diffs, if nothing else.

[iPocketBook]

are you guys looking for poterm on 302?

https://www.mobileread.com/forums/sho...=76847&page=14
(post 199)

[brainycat]

Yet another example of why we need a properly organized, onestop URL for pocketbook resources.

Thanks for the link!!! I'll get installed shortly.

[LoneTech]

The more I read, the more I like PocketBook service. I was intimidated at first by finding only cyrillic conversation at the pocketbook-free project, but at this point, I have ordered a 903 and gotten the inkView demo in the SDK to run. I would like to participate in documenting development for the PocketBooks in English.

For my first little tip: The SDK apps look for some resources, such as fonts, in a bunch of places - /ebrmain and /mnt/ext1 among them. Symlinking the ebrmain directory included in the SDK to /ebrmain did the trick. This is probably mentioned in the readme, but I couldn't read it.

Next would be figuring out how to compile a program. Perhaps this sort of thing could be collected on the mobileread wiki? Considering the devhub, it looks on topic.

By the way, it feels clumsy dealing with winelib. I understand inkview was written with win32 APIs for emulation, but it would be easier for us GNU/Linux developers with a more native approach, such as SDL. My initial attempt at building grays hit a winegcc not found.

Second add: Another step complete! After installing ia32-libs-dev, libc6-dev-i386, libwine-dev, and lib32z1-dev, grays compiled with a simple make. Unlike the precompiled inkdemo, the freshly built program expected the whole SDK in /usr/local/pocketbook. Looking good!

Third add: Finding keynames-nanox.xml suggests that inkView may use the win32-like MicroWindows API. In that case using winelib represents much less effort than using SDL, and it wasn't that hard to install libwine-dev, so don't bother changing that part.

[Logseman]

Your efforts will be very worthwhile, and Karma is in your way . You should know that there is already an (embrionary) Pocketbook development wiki. If you could start documenting it, it would surely make an impact!

http://sourceforge.net/apps/mediawik...itle=Main_Page

[LoneTech]

Thank you, that wiki would be a great place to collect information. I already noted one niggle; in the networking API, one should test for NET_CONNECTED rather than the individual NET_*READY bits, to allow for future connection methods (USB tethered, perhaps). I haven't figured out how to enable editing or join the pocketbook-free project, though.

I've started in slightly on Doxygen-tagging the inkview.h header. Combined with the demo app, this got me some clarifications such as what Long (long tap) and Hold (pointer stopped after moving) pointer events are.

A copy of the current progress (limited, I know) is at http://donkey.vernier.se/~yann/pbapi/. The API itself looks fairly manageable, but eventually I'll probably be down to a few questions or points that need testing.

[MrPLD]

Originally Posted by fjtorres

And that means a *corporate* commitment to the platform. The computer industry is littered with the corpses of companies to whom "Open source" meant simply "No user support".

Sadly the same is for a great number of commercial projects that closed down leaving existing licence holders high and dry (a recent one for me was the "MainActor" NLVE program).

At least with OpenSource applications you do have a chance to continue if the author decides to halt development, more so than if a commercial vendor halts.

Paul.