Openmoko on Design

[Marcus Bauer]

On Tue, 2008-07-29 at 00:35 -0700, Brian C wrote:

[snip <lots of very clever thoughts>]

> So, I'll ask again: does
> Openmoko intend to allow direct code contributions by community members
> to core components of the ASU/FSO frameworks?

It would be better to get rid of this whole framework concept and doing
what Sean is constantly talking about: freedom. Freedom of choice.

The framework means tying the applications to the system level which is
like tying Firefox to Apache. 

No developer who is sane in his mind will want to marry a whole PIM API
just for sending an SMS. And FSO is essentially a newly invented,
unstable and immature PIM API. This is so much like Microsoft.

And there are already plenty of PIM APIs. Just use one of them, they all
work cross toolkit.

The gsmd needs a libgsmd and on top of this implement whatever dbus API
you like. This is freedom. This is choice. But by immediately glueing
the dbus API to a specific gsmd you forcefully marry all developers to
your FSO. End of freedom, end of choice.

phonekit is a lot more flexible and future proof than FSO. Due to the
nature of dbus it can potentially run side by side with any other
'phonekit'. But the whole point of FSO is to block this out.

Why do you want people to "rip phonekit out" of OM2007.2? It is not your
business anyway if you stopped development of OM2007.2.

The problem is not ETK, not qtopia, not GTK. The problem is framework
and FSO. This whole strength of Linux is separation of components. Do
one thing and do it well. Why willfully destroy this great concept of
success?

Openmoko should concentrate on kernel and driver work, power management
and working hardware and a basic set of apps. All this is mostly there
with OM2007.2 and now energy is better spend on doing thousand of little
improvements than starting again from scratch.

Marcus - developer of tangoGPS. I know what I'm talking about.