Bi-weekly OpenMoko community update

[Derek Pressnall]

On 10/14/07, Robin Paulson <robin.paulson at gmail.com> wrote:

> hmm. this an open phone with open hardware and (where legal) open
> drivers. not having the source code to something would defeat the
> whole purpose of what sean et al are doing, and not attract any of the
> community that's here - the neo would be just another smartphone/pda
> and we'd be back to square one.

I've got a personal system of prioritizing the items that I want
source for, based on what the result of source availability /
unavailability is.
The primary purpose (for me) to have source to something is to make it
more functional (either by me modifying the code, or someone else
modifying it).  To go along with that, source availability under a
freedom license allows others to share their modifications with others
(including me) which makes the code more functional to me.
So from there I can make a determination on what I really want source for:
1) Binary blobs -- since thes are alternatives to having firmware
already on an external chip, it makes no difference in functionality
wheather a chip is used with a rom chip already loaded with the binary
blob (which I can't modify), vs. pushing the unmodifyable binary blob
to the chip at initialation time.  If I don't have source for that
binary blob, it doesn't bother me because it is something that runs
outside of the main processor.
2) Kernel modules -- These are more important to have source for,
since lack of source means that I loose the functionality of that
device when I upgrade to a newer kernel.  If I can be guaranteed that
updated versions of the driver are provided in a timely manner for
newer kernel versions, AND if the driver is already perfect enough
that it won't need any functionality added, then I can almost accept
using binary drivers.  Of course, these two conditions are almost
never met.
3) Binary apps / daemons -- If a binary app runs completely in user
space (so that there is little chance of it destabilizing the system),
AND if it has a well defined and fully implemented functionality (so
that it is not likely that I would need to have "improved" versions of
it), then I can accept it.

If the gpsd falls into catagory 3 (and not 2), then for me that is ok,
as long as it is bug free, will work with updated kernels, and has a
defined api for talking to it from other apps.  In that case, I can
treat it as if I'm using a gps chip that spits out the protocal that
the daemon is spitting out. (I assume that is what the daemon is for,
to take the propriarity api on the chip and convert it to a
standards-based api).

Now a secondary purpose of having source availability is to study the
code to improve my programming techniques.  So having a closed gpsd
doesn't help there.  But it doesn't affect the primary purpose. (Of
course, other people have different primary purposes than me, so this
won't apply to them).