Re: Openmoko on Design

[Michael Shiloh]

Jay Vaughan wrote:
>> I have a MIDI keyboard I can bring with me to LinuxWorld, and a USB/ 
>> MIDI
>> interface.
> 
> Well I spent some time hacking on it this weekend and I've gotten a  
> basic MIDI parser/librarian/sequencer setup on the Freerunner now ..  
> great fun to play back tracks to my 19" rack using the Freerunner!   
> But I've got some cleaning up to do and some serious catching up to do  
> in the packaging department before I can put this out there for  
> general use - right now its quite a bit hacky to get things started.
> 
>> If your synth is ready in time I'd love to show it.
>> M
> 
> It would be nice indeed, but I don't think I'm ready to release yet ..  
> I have to get move away from my current hacked-up configuration to a  
> cleaner, public-packaged style setup .. and I can't really do that  
> with the moving targets of our current images, alas .. but stay tuned,  
> because if things go well with this weeks new ASU release, I'll do my  
> work all over again and make sure I produce proper packages that will  
> work for a majority.


No worries - there will be plenty of other opportunities.

I am no musician myself but have plenty of friends who are, and are 
Linux geeks as well, and they will love this. Please keep us informed.

Michael

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko on Design

[Jay Vaughan]

> I have a MIDI keyboard I can bring with me to LinuxWorld, and a USB/ 
> MIDI
> interface.

Well I spent some time hacking on it this weekend and I've gotten a  
basic MIDI parser/librarian/sequencer setup on the Freerunner now ..  
great fun to play back tracks to my 19" rack using the Freerunner!   
But I've got some cleaning up to do and some serious catching up to do  
in the packaging department before I can put this out there for  
general use - right now its quite a bit hacky to get things started.

> If your synth is ready in time I'd love to show it.
> M

It would be nice indeed, but I don't think I'm ready to release yet ..  
I have to get move away from my current hacked-up configuration to a  
cleaner, public-packaged style setup .. and I can't really do that  
with the moving targets of our current images, alas .. but stay tuned,  
because if things go well with this weeks new ASU release, I'll do my  
work all over again and make sure I produce proper packages that will  
work for a majority.


;
--
Jay Vaughan





___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko on Design

[Michael Shiloh]

I have a MIDI keyboard I can bring with me to LinuxWorld, and a USB/MIDI 
interface.

If your synth is ready in time I'd love to show it.

M

Jay Vaughan wrote:
>> 7) Maybe run some simple synth applications on the FR, using the USB  
>> host mode to connect it to a MIDI keyboard.
> 
> 
> this is what i'm doing this weekend .. ;)
> 
> ;
> --
> Jay Vaughan
> 
> 
> 
> 
> 
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko on Design

[Ken Restivo]

On Wed, Jul 30, 2008 at 11:28:13AM +0800, Marek Lindner wrote:
> On Wednesday, 30. July 2008 10:18:33 Al Johnson wrote:
> > I agree with everything you say here. The keyboard should just appear when
> > I want it and disappear when I don't. The absence of a manual override
> > means that whenever it gets it wrong I can't correct it, the worst case
> > being when I need to enter something but the keyboard doesn't appear.
> > Conversely the presence of a manual override causes no problem even if it
> > is never needed.
> >
> > The keyboard failing to appear is not a hypothetical scenario. Without
> > manual intervention minimo was unusable because the keyboard didn't appear
> > when the cursor was placed for URL entry. This is likely to be an issue
> > with other apps that don't have a specific openmoko port, and we shouldn't
> > have to create such a port just to use an otherwise capable app on
> > openmoko. Other issues include the keyboard appearing when an edit field
> > has focus although I don't want to edit it, keyboard appearing and
> > disappearing frequently if a form contains mixed input types, or appearing
> > over the top of the field to be edited. The field having focus although
> > editing is not required is probably impossible to detect because the answer
> > depends on the opinion of the user at the time.
> 
> I understand your points and they all are valid. How do we address them ? 
> That 
> brings us back to Seans mail. Openmoko will provide the minimum set of 
> applications and basic functionality that empowers ordinary users to use the 
> phone. We will make sure that these applications work well with the 
> environment we provide. This is an ongoing process we just started compared 
> to many established phone systems. 
> Feel invited to extend that basic system through packages that can be 
> installed. If you install an application that hasn't been ported to the 
> Openmoko platform and does not support the keyboard you also should install 
> the manual keyboard button or you just install a package which deativates the 
> automatic keyboard behaviour right away if you don't like it.
> We have to realize that the world is very diverse - we wont find a solution 
> which suits for everybody in all the cases. So, we have to make it flexible. 
> Again: This is a process and you can help us with that.
> 
> 


I feel terrible about this whole mess because I was one of the first people in 
the original terminal thread, and I filed one of the original bug reports on it 
too.

I don't expect to be able to stop the mailing-list train wreck from continuing, 
now that it has developed a momentum of its own, except to apologize for having 
been involved in starting it in the first place. Sorry about that.

-ken

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko on Design

[Jay Vaughan]

> 7) Maybe run some simple synth applications on the FR, using the USB  
> host mode to connect it to a MIDI keyboard.


this is what i'm doing this weekend .. ;)

;
--
Jay Vaughan





___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko on Design

[Jacob Peterson]

On Thu, Jul 31, 2008 at 4:27 AM, Ken Restivo <[EMAIL PROTECTED]> wrote:

> On Wed, Jul 30, 2008 at 11:38:07AM +0800, John Lee wrote:
> > On Wed, Jul 30, 2008 at 01:47:29AM +0100, Al Johnson wrote:
> > > I'll snip most of it to keep the length reasonable.
> >
> > same here :)
> >
> > > On Tuesday 29 July 2008, William Lai wrote:
> > > >
> > > > It already is.
> > > > We've offered a couple of different solutions to community requests
> that
> > > > were declined by, well, engineering.  One of them was:
> > > >
> > > > * create a package to be installed through installer adding manual
> > > > qwerty button to illume theme.
> > >
> > > The only suggestion I remember was that the community fork illume. Is
> this a
> > > different take on the same suggestion, or a different suggestion? What
> was
> > > the other option? And what was the objection to providing it as a
> > > configuration option with the default being off, as proposed on this
> list?
> >
> >
> > What we are trying to do:
> >
> > provide a OM repository and a community repository.  in this
> > particular case, if in the end the illume still shipped without kbd
> > button, then the community will very likely provide another version of
> > illume called illume-kbd in the community repository.  thus you can
> > replace the shipped illume with illume-kbd, and the next upgrade will
> > get the new version of illume-kbd instead of illume, so you don't need
> > to change it again after upgrade.
> >
> >
> > Where we are right at the moment:
> >
> > illume is there.
> >
> > the community repository is not ready yet but we're working on it.
> >
> > the dependency handling of replacing the shipped illume with
> > illume-kbd is not ready yet but we're working on it.
> >
> >
> > My personal comment on this:
> >
> > if the illume is so much more popular then illume-kdb (theoretically
> > we can know that from the repository log) or the other way around then
> > you bet that fact will be very effective in OM.  ;)
> >
>
> I bought the FreeRunner in order to:
>
> 1) Use for remote system administration, via a terminal and onscreen
> keyboards, via SSH over WiFi and GPRS.
> 2) Browse the web via WiFi and/or GPRS
> 3) Read/write email using some kind of IMAP mail app, and send/recieve SMS
> 4) Make and receive calls via VOIP and GSM
> 5) Play media (Vorbis, MP3, FLV's, MP4's) and record audio
> 6) Write a custom touchscreen UI app for a linux-based music synthesizer
> (connecting to the synth via Bluetooth)
> 7) Maybe run some simple synth applications on the FR, using the USB host
> mode to connect it to a MIDI keyboard.
>
> So far, not even the first 5 of those are complete and reliable enough for
> me to actually use without hassle, and based on what I've read here, I'm
> estimating about 2 years before they are.
>

2 years?  At the rate I am seeing progress, I would bet closer to two
months, as it seems the ASU and eventual FSO images are coming along quite
nicely.


>
> In the meantime, however,  I've realized that I can probably get through
> the rest of my life happily without *any* of the above features, and I
> should have waited a few more years before spending so much money.
>
> -ken
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [openmoko-announce] Openmoko on Design

[Clemens Kirchgatterer]

Ken Restivo <[EMAIL PROTECTED]> wrote:

> It seems to me from my former-product-mananger perspective that
> OpenMoko doesn't really want to be in the software business. 

why would they do ASU/FSO then? i don't buy this.
 
> I'm sensing a business model that has OpenMoko focussing on selling
> general-purpose computing hardware (like Dell or ASUS). but in a
> handheld format, and letting the "community" or some third party
> (like Trolltech/Nokia) deal with the software issues, for the most
> part. 

if that was true, they would just throw some money at trolltech/nokia
and ship qtopia, not needing to bother with anything else. for sure
would be much cheaper (at least i think).

best regards ...
clemens

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [openmoko-announce] Openmoko on Design

[papa-piet]

> It seems to me from my former-product-mananger perspective that OpenMoko 
> doesn't really want to be in the software business. 
> 
> I'm sensing a business model that has OpenMoko focussing on selling 
> general-purpose computing hardware (like Dell or ASUS). but in a handheld 
> format, and letting the "community" or some third party (like 
> Trolltech/Nokia) deal with the software issues, for the most part. 
> 
> Obviously they need to ship the phone with *something*, so they're betting on 
> Qtopia-over-X11, which seems a solidly good choice.
> 
> The one very big problem with this model, is that Dell and ASUS have very 
> mature, end-user-ready software suites (Ubuntu, Windoze, etc.) to ship with 
> their hardware or for users to add on their own, and the OpenMoko doesn't 
> really have that yet.
> 
> This will get sorted out though. I'd bet on about two years from now it'll 
> all be squared away.
> 
> -ken
> 
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community

Hey Ken, Hey Community,

this is also my interpretation, Openmoko is trying only to to open up a
building site, *WE* have to build our houses and factories, anybody
expecting more than infrastructure is still bound to products before NEO
and before Openmoko.

freeyourphone.de

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko on Design

[Ken Restivo]

On Wed, Jul 30, 2008 at 11:38:07AM +0800, John Lee wrote:
> On Wed, Jul 30, 2008 at 01:47:29AM +0100, Al Johnson wrote:
> > I'll snip most of it to keep the length reasonable.
> 
> same here :)
> 
> > On Tuesday 29 July 2008, William Lai wrote:
> > >
> > > It already is.
> > > We've offered a couple of different solutions to community requests that
> > > were declined by, well, engineering.  One of them was:
> > >
> > > * create a package to be installed through installer adding manual
> > > qwerty button to illume theme.
> > 
> > The only suggestion I remember was that the community fork illume. Is this 
> > a 
> > different take on the same suggestion, or a different suggestion? What was 
> > the other option? And what was the objection to providing it as a 
> > configuration option with the default being off, as proposed on this list?
> 
> 
> What we are trying to do:
> 
> provide a OM repository and a community repository.  in this
> particular case, if in the end the illume still shipped without kbd
> button, then the community will very likely provide another version of
> illume called illume-kbd in the community repository.  thus you can
> replace the shipped illume with illume-kbd, and the next upgrade will
> get the new version of illume-kbd instead of illume, so you don't need
> to change it again after upgrade.
> 
> 
> Where we are right at the moment:
> 
> illume is there.
> 
> the community repository is not ready yet but we're working on it.
> 
> the dependency handling of replacing the shipped illume with
> illume-kbd is not ready yet but we're working on it.
> 
> 
> My personal comment on this:
> 
> if the illume is so much more popular then illume-kdb (theoretically
> we can know that from the repository log) or the other way around then
> you bet that fact will be very effective in OM.  ;)
> 

I bought the FreeRunner in order to:

1) Use for remote system administration, via a terminal and onscreen keyboards, 
via SSH over WiFi and GPRS.
2) Browse the web via WiFi and/or GPRS
3) Read/write email using some kind of IMAP mail app, and send/recieve SMS
4) Make and receive calls via VOIP and GSM
5) Play media (Vorbis, MP3, FLV's, MP4's) and record audio
6) Write a custom touchscreen UI app for a linux-based music synthesizer 
(connecting to the synth via Bluetooth)
7) Maybe run some simple synth applications on the FR, using the USB host mode 
to connect it to a MIDI keyboard.

So far, not even the first 5 of those are complete and reliable enough for me 
to actually use without hassle, and based on what I've read here, I'm 
estimating about 2 years before they are.

In the meantime, however,  I've realized that I can probably get through the 
rest of my life happily without *any* of the above features, and I should have 
waited a few more years before spending so much money.

-ken

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [openmoko-announce] Openmoko on Design

[Ken Restivo]

On Mon, Jul 28, 2008 at 10:31:55PM +0200, Jay Vaughan wrote:
> > Sorry to hear it doesn't work for you. But like I said, we each have  
> > our
> > own ways of understanding and making meanings.
> > You are free to create your own meanings.
> 
> 
> I just can't see how you honestly believe all this panty-waiste  
> dilettante waffling about "not having a design because its up to the  
> open community" is going to drive things forward.  Are you, or are you  
> not, committed to delivering a working phone platform that *users* and  
> developers alike are going to be interested in?  Then: some standards  
> need to be put forth, and they need to be adhered to.
> 


It seems to me from my former-product-mananger perspective that OpenMoko 
doesn't really want to be in the software business. 

I'm sensing a business model that has OpenMoko focussing on selling 
general-purpose computing hardware (like Dell or ASUS). but in a handheld 
format, and letting the "community" or some third party (like Trolltech/Nokia) 
deal with the software issues, for the most part. 

Obviously they need to ship the phone with *something*, so they're betting on 
Qtopia-over-X11, which seems a solidly good choice.

The one very big problem with this model, is that Dell and ASUS have very 
mature, end-user-ready software suites (Ubuntu, Windoze, etc.) to ship with 
their hardware or for users to add on their own, and the OpenMoko doesn't 
really have that yet.

This will get sorted out though. I'd bet on about two years from now it'll all 
be squared away.

-ken

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko on Design

[Charles-Henri Gros]

Marek Lindner wrote:
> On Thursday, 31. July 2008 05:24:45 Josh Monson wrote:
>> Or is Sean saying that this would be an option if it was in the form of
>> a package, so if the package was built (by the community) then you would
>> have the choice to toggle or not to toggle? I am assuming that
>> functionality was removed so that it can be an installable option and
>> not a default.
> 
> Bingo !  :-)

This might be a desirable goal, but people don't like it if they have to
spend days writing the package that's required to bring the
functionality back (which so far no one has even tried doing apparently)

I don't think anyone would have complained if you had created that
package yourself (since, presumably, you're well qualified to do it) and
made it available on the standard repo.

Right now the way to bring the keyboard back is to dig into the wiki,
decompile a theme, modify it, recompile it. A bit harder than installing
a package.

So: pretty please, could you create a package to add the option? Could
you, in the future, when you remove functionality (to make it
"optional"), create a package to get the functionality back? Or at least
warn in advance that such a package is needed, so that the community can
build the package if you don't have time?

Thanks!

-- 
Charles-Henri


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko on Design

[Marek Lindner]

On Thursday, 31. July 2008 05:24:45 Josh Monson wrote:
> Or is Sean saying that this would be an option if it was in the form of
> a package, so if the package was built (by the community) then you would
> have the choice to toggle or not to toggle? I am assuming that
> functionality was removed so that it can be an installable option and
> not a default.

Bingo !  :-)


Marek

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko on Design

[papa-piet]

Open Source is more than that,
do you all propose OM to sell their Software bound to the Hardware?

I fear you thing too much in the old fashined way of MObile
COmmunication. The Freerunner is a piece of Hardware *YOU DECIDE* what
software you want to run on it FSO ASU 2007.1 2007.2, SHR, ASDF or
something YOU HAVE created
*FREE YOUR CHOISE*

Think of your pc I assume the percentage of the people on this list is
really high who dislike Microsoft's politics and the fact that nearly
every OEM pc comes up with Vista.

Think of opensource projects, the most of then started within a
comunity, not a company.

If you think 2007.2 is not enouth and you feel neglected by OM Ltd. do
it yourselves. YOU can't expect a project starting from 0 full speed
within *ONE MONTH*!

When you bought the FR nobody told you: "Okay, right now the SW is
really buggy, but I swear within a month, it is gonna be perfect."

So be patient, put your power to develop the project, not to complain
that some metaphors are better than others or come up with ideas not
abuses.

be friendly, stop expecting the very best for YOU, be grateful, relax,
code, relax, come up with great ideas (like tangoGPS) relax,
communicate, stop abusing, free your choice


http://freeyourphone.de


Scott schrieb:
> Sean Moss-Pultz wrote:
>> On 7/30/08 Daniel Benoy wrote:
>>> Also, would the openmoko design team be willing to consider a  toggle
>>> in the configuration menu between manual and automatic?
>>
>> What we want is for people to add their own configuration options to
>> menus in the form of packages installable from the "Installer". This
>> is why we remove functionality. So we can focus on how to make sure
>> our products are extensible.
> 
> This seems like a bullshit answer to me. Taking functionality away
> doesn't improve the FR. It makes it less useful. Are you guys deaf or
> something?  Haven't you hear the screams from the people who plonked
> down their cold hard cash for your product about this reduction in
> functionality?
> 
> Or are you just so damn arrogant you think its your way or the highway?
> 
> If the functionality was there and you felt it should be an option, YOU
> should have made it one!  But thats not what you did. You made it
> difficult for a programmer to temporarily bring it back, and no way to
> make it a user selectable option.
> 
> bah!!
> 
> Scott
> 
> 
> 
> 
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko on Design

[arne anka]

> People need to stop biting the hand that feeds you.

he bit the other hand, actually.
*scnr*

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko on Design

[Josh Monson]

Scott wrote:
> Sean Moss-Pultz wrote:
>> On 7/30/08 Daniel Benoy wrote:
>>> Also, would the openmoko design team be willing to consider a  toggle 
>>> in the configuration menu between manual and automatic?
>>
>> What we want is for people to add their own configuration options to 
>> menus in the form of packages installable from the "Installer". This 
>> is why we remove functionality. So we can focus on how to make sure 
>> our products are extensible.
> 
> This seems like a bullshit answer to me. Taking functionality away 
> doesn't improve the FR. It makes it less useful. Are you guys deaf or 
> something?  Haven't you hear the screams from the people who plonked 
> down their cold hard cash for your product about this reduction in 
> functionality?
> 
> Or are you just so damn arrogant you think its your way or the highway?
> 
> If the functionality was there and you felt it should be an option, YOU 
> should have made it one!  But thats not what you did. You made it 
> difficult for a programmer to temporarily bring it back, and no way to 
> make it a user selectable option.
> 
> bah!!
> 
> Scott
> 
> 
> 
> 
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community

Or is Sean saying that this would be an option if it was in the form of 
a package, so if the package was built (by the community) then you would 
have the choice to toggle or not to toggle? I am assuming that 
functionality was removed so that it can be an installable option and 
not a default. Sean?

Maybe asking for more information on why, or a more in-depth explanation 
would be appropriate.

Tone down the negativity and just post the question. Constructive 
criticism is needed for things to move forward, but you can at least be 
respectfull. I think if OM answered you in the same rhetoric you are 
asking questions and throwing flames that you would find it offensive.

Yes, things need to be improved and yes things are not exactly how 
everyone wants them. OM has as least opened this up so your input can be 
received NOW, they could have kept this completely closed for the next 
year and we would still all be waiting...

People need to stop biting the hand that feeds you.


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: illume keyboard button (was Openmoko on Design)

[The Rasterman]

On Wed, 30 Jul 2008 15:01:52 +0200 Andreas Bogk <[EMAIL PROTECTED]> babbled:

as its just a button provided by the theme - the theme determines if the ui
element is there or not - the code will still respond to the signal from the
theme saying 'someone pressed the keyboard toggle". the idea here is that now
the designer can decide if the button is there or not, where it is, how it
looks, how you interact with it etc. - and the designers have spoken that it is
not to be there. it is up to you to provide a package of your own that changes
this.

otherwise you;ll just have to wait until i get to changing how it works.

> Dear community and OM Powers That Be,
> 
> I have read the "Openmoko on Design" thread with a certain alienation. 
> I'll try to resist the temptation to pick up one of the many flame 
> baits, but even after sleeping it over for a night, I feel inclined to 
> comment on the issue here.
> 
> First, I think that the complaints of users about "the phone should know 
> when it expects keyboard input, and automatically bring up the keyboard" 
> are right.  The work going into this direction is correct.
> 
> However, there are situations when a manual override is needed.  The 
> automatic detection could be wrong, for instance.  But much more 
> important: the user could be in a situation where keyboard input is 
> theoretically possible, but not currently desired, because the keyboard 
> is taking away screen real estate.  This happened to me yesterday, when 
> I was sitting in the train, and reading some code using the terminal 
> application.
> 
> So, in my opinion, the decision to remove the button is incorrect.  Even 
> more so, the strong reaction of the users should have been an indication 
> that the decision was incorrect.  It's always a good idea to listen to 
> your users.
> 
> It has been said that, since OpenMoko is an open project, the community 
> has the chance to come up with a different solution.  Now let's take a 
> look at what the community (read: folks who actually write code instead 
> of participating in lengthy discussions) did, the day the button was 
> removed from illume:
> 
> http://gitweb.openembedded.net/?p=org.openembedded.dev.git;a=blob;f=packages/openmoko-projects/illume/configure-keyboard.patch;h=589fe53f38afc59be95a13ed67a9f9d1fc452148;hb=HEAD
> 
> They re-enabled the feature in their branch, and went on with their 
> life.  However, the patch stopped applying this morning, and I had to 
> lock down illume to r170.
> 
> Raster: if you could make the keyboard button a configuration option, as 
>   in the above patch, you'd make me and a couple of other people happy. 
>   Thanks in advance.
> 
> Andreas
> 
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community


-- 
Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]>

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko on Design

[Scott]

Sean Moss-Pultz wrote:

On 7/30/08 Daniel Benoy wrote:
Also, would the openmoko design team be willing to consider a  toggle 
in the configuration menu between manual and automatic?


What we want is for people to add their own configuration options to 
menus in the form of packages installable from the "Installer". This is 
why we remove functionality. So we can focus on how to make sure our 
products are extensible.


This seems like a bullshit answer to me. Taking functionality away 
doesn't improve the FR. It makes it less useful. Are you guys deaf or 
something?  Haven't you hear the screams from the people who plonked 
down their cold hard cash for your product about this reduction in 
functionality?


Or are you just so damn arrogant you think its your way or the highway?

If the functionality was there and you felt it should be an option, YOU 
should have made it one!  But thats not what you did. You made it 
difficult for a programmer to temporarily bring it back, and no way to 
make it a user selectable option.


bah!!

Scott



signature.asc
Description: OpenPGP digital signature
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

RE: Openmoko on Design

[steve]

Actually Jay,

The book is about behavior and biology and how we perceive things. But let's
not argue.
Let's solve your problem.. How can I help?

Steve 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jay Vaughan
Sent: Wednesday, July 30, 2008 1:21 AM
To: List for Openmoko community discussion
Cc: [EMAIL PROTECTED]
Subject: Re: Openmoko on Design

> If you go read Morse Peckham's book
> http://www.amazon.com/Mans-Rage-Chaos-Biology-Behavior/dp/080520142
> You will understand how museuems and gallery's function; and, Sean's 
> words will strike you more deeply.


Its all well and good when you're dealing with art students, but when you
hope to sell 1,000 Freerunners as the base hardware platform for a
multinational operation, it doesn't sell too well.

Sorry.

;
--
Jay Vaughan





___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: illume keyboard button (was Openmoko on Design)

[Holger Freyther]

On Wednesday 30 July 2008 15:01:52 Andreas Bogk wrote:

> http://gitweb.openembedded.net/?p=org.openembedded.dev.git;a=blob;f=package
>s/openmoko-projects/illume/configure-keyboard.patch;h=589fe53f38afc59be95a13
>ed67a9f9d1fc452148;hb=HEAD
>
> They re-enabled the feature in their branch, and went on with their
> life.  However, the patch stopped applying this morning, and I had to
> lock down illume to r170.

Hey Andreas,

you actually want to have a different illume.edj file. So the fso guys created 
one[1] and use that. It is on the distro team's todolist to make it possible 
to easily replace (update-alternative) the illume.edj file with other 
versions (installable through the installer). Personally I hope people will 
be more creative than just adding a qwertz button and will play with edje to 
try other things as well.

About the patch you posted. The sad truth is that X/freedesktop.org lacks a 
way to identify virtual inputmethods and this means we have no way to find 
out which apps might be able to send key events, let alone switching between 
these... So for ASU we can only instantiate one virtual keyboard and we 
decided to use the Qtopia keyboard. So what my patch for fso did was to make 
that "#if 0" compile time configurable. It was not applied upstream as raster 
wanted to make it runtime configurable and the patch doesn't apply anymore as 
this has happened.

For post ASU we want to propose E_VIRTUAL_KEYBOARD_STATE (probably _NETWM_...) 
to freedesktop.org and want to establish the means to find out which keyboard 
implementations are available...

i hope this helps
z.

[1] 
http://gitweb.openembedded.net/?p=org.openembedded.dev.git;a=blob_plain;f=packages/freesmartphone/illume-theme-freesmartphone_git.bb;hb=HEAD

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

illume keyboard button (was Openmoko on Design)

[Andreas Bogk]

Dear community and OM Powers That Be,

I have read the "Openmoko on Design" thread with a certain alienation. 
I'll try to resist the temptation to pick up one of the many flame 
baits, but even after sleeping it over for a night, I feel inclined to 
comment on the issue here.

First, I think that the complaints of users about "the phone should know 
when it expects keyboard input, and automatically bring up the keyboard" 
are right.  The work going into this direction is correct.

However, there are situations when a manual override is needed.  The 
automatic detection could be wrong, for instance.  But much more 
important: the user could be in a situation where keyboard input is 
theoretically possible, but not currently desired, because the keyboard 
is taking away screen real estate.  This happened to me yesterday, when 
I was sitting in the train, and reading some code using the terminal 
application.

So, in my opinion, the decision to remove the button is incorrect.  Even 
more so, the strong reaction of the users should have been an indication 
that the decision was incorrect.  It's always a good idea to listen to 
your users.

It has been said that, since OpenMoko is an open project, the community 
has the chance to come up with a different solution.  Now let's take a 
look at what the community (read: folks who actually write code instead 
of participating in lengthy discussions) did, the day the button was 
removed from illume:

http://gitweb.openembedded.net/?p=org.openembedded.dev.git;a=blob;f=packages/openmoko-projects/illume/configure-keyboard.patch;h=589fe53f38afc59be95a13ed67a9f9d1fc452148;hb=HEAD

They re-enabled the feature in their branch, and went on with their 
life.  However, the patch stopped applying this morning, and I had to 
lock down illume to r170.

Raster: if you could make the keyboard button a configuration option, as 
  in the above patch, you'd make me and a couple of other people happy. 
  Thanks in advance.

Andreas

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko on Design

[Jay Vaughan]

> Yeah it was a misunderstanding then. That's exactly what I was  
> referring
> to. Too many emails :-)
> Only a joke Jay. Nothing personal.
>


okay, so please consider this .. i have a customer with the potential  
to place an order for 1,000 phones.  when do you propose i go to them  
and close the deal?

;
--
Jay Vaughan





___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko on Design

[Sean Moss-Pultz]

On 7/30/08 arne anka wrote:
> >> Yes Jay. That is exactly the goal of this company. Sell 1,000 
> phones.
> >> >> They we all can retire.
> > >
> > > wtf?  you're ridiculing a single order of 1,000 phones being 
> placed at
> > > one time by an enthusiastic customer?  sheesh.  what sort of CEO 
> are
> > > you?
> 
> 
> chill. only a misunderstanding probably -- you were talking about a 
> single  
> order of 1.000 phones, sean was obviously understanding an overall 
> sale of  
> 1.000 phones (and so did i).

Yeah it was a misunderstanding then. That's exactly what I was referring 
to. Too many emails :-)

Only a joke Jay. Nothing personal.

   -Sean

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko on Design

[Sean Moss-Pultz]

On 7/30/08 Jay Vaughan wrote:
> > Yes Jay. That is exactly the goal of this company. Sell 1,000 
> phones.
> > > They we all can retire.
> > >   -Sean
> 
> 
> wtf?  you're ridiculing a single order of 1,000 phones being placed 
> at  
> one time by an enthusiastic customer?  sheesh.  what sort of CEO are  
> you?
> 
> *all* orders, large and small, are worth the effort, or is that not  
> true?  i suggest you think about this a little.

Jay, give me a break. It was a joke. You chide me for selling to art 
students. Can't I poke a bit of fun, too? ;-)

No hard feelings man. Seriously. Let's all get on with our day.

   -Sean

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko on Design

[arne anka]

>> Yes Jay. That is exactly the goal of this company. Sell 1,000 phones.
>> They we all can retire.
>
> wtf?  you're ridiculing a single order of 1,000 phones being placed at
> one time by an enthusiastic customer?  sheesh.  what sort of CEO are
> you?


chill. only a misunderstanding probably -- you were talking about a single  
order of 1.000 phones, sean was obviously understanding an overall sale of  
1.000 phones (and so did i).

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko on Design

[Jay Vaughan]

> Yes Jay. That is exactly the goal of this company. Sell 1,000 phones.
> They we all can retire.
>   -Sean


wtf?  you're ridiculing a single order of 1,000 phones being placed at  
one time by an enthusiastic customer?  sheesh.  what sort of CEO are  
you?

*all* orders, large and small, are worth the effort, or is that not  
true?  i suggest you think about this a little.

;
--
Jay Vaughan





___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko on Design

[Sander van Grieken]

> On 7/30/08 Jay Vaughan wrote:
>> > If you go read Morse Peckham's book
>> > >
>> http://www.amazon.com/Mans-Rage-Chaos-Biology-Behavior/dp/080520142
>> > > You will understand how museuems and gallery's function; and,
>> Sean's
>> > > words
>> > > will strike you more deeply.
>>
>>
>> Its all well and good when you're dealing with art students, but when
>>
>> you hope to sell 1,000 Freerunners as the base hardware platform for
>> a
>> multinational operation, it doesn't sell too well.
>
> Yes Jay. That is exactly the goal of this company. Sell 1,000 phones.
> They we all can retire.

Come on now. If OM can only respond with hostile ad hominems to IMHO valid 
critisism,
then I fear for the life of this 'community'.

Without solid leadership this community will fragment (which, to some degree, 
it already
has) and lose momentum. And that is hard to regain.

And to stay with the museum/gallery metaphor; If you don't use high quality 
paint and
canvas, it'll all fade away quickly.


Sander



___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko on Design

[Sean Moss-Pultz]

On 7/30/08 Jay Vaughan wrote:
> > If you go read Morse Peckham's book
> > > 
> http://www.amazon.com/Mans-Rage-Chaos-Biology-Behavior/dp/080520142
> > > You will understand how museuems and gallery's function; and, 
> Sean's  
> > > words
> > > will strike you more deeply.
> 
> 
> Its all well and good when you're dealing with art students, but when 
>  
> you hope to sell 1,000 Freerunners as the base hardware platform for 
> a  
> multinational operation, it doesn't sell too well.

Yes Jay. That is exactly the goal of this company. Sell 1,000 phones. 
They we all can retire.

   -Sean

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko on Design

[Jay Vaughan]

> If you go read Morse Peckham's book
> http://www.amazon.com/Mans-Rage-Chaos-Biology-Behavior/dp/080520142
> You will understand how museuems and gallery's function; and, Sean's  
> words
> will strike you more deeply.


Its all well and good when you're dealing with art students, but when  
you hope to sell 1,000 Freerunners as the base hardware platform for a  
multinational operation, it doesn't sell too well.

Sorry.

;
--
Jay Vaughan





___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [openmoko-announce] Openmoko on Design

[Jay Vaughan]

> About Jay, I apologize if I attached personally it, but he was  
> attaching
> a lot of person of this ML, and it was not too much nice.
>

I don't believe I attacked any one person specifically, personally,  
but okay .. lets move on.  There is code to be written and new things  
to be talked about.  All griping aside, it sure is fun to have a nice  
open pocket platform to code for, as stormy as this one is ..


> Now I wish you a very nice day, and happy programming ( or  
> experimenting).
>

Indeed!  Moving on ..

;
--
Jay Vaughan





___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [openmoko-announce] Openmoko on Design

[Jay Vaughan]

>   you seem very passionate about your concerns. If you are going to  
> linux
> world I'd be happy to meet and discuss things.
>   Or if you can make a list of specific problems I can try to  
> explain or
> address your concerns.


[reply off-list]

;
--
Jay Vaughan





___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko on Design

[Sean Moss-Pultz]

On 7/30/08 Daniel Benoy wrote:
> Also, would the openmoko design team be willing to consider a  toggle 
> in the configuration menu between manual and automatic?

What we want is for people to add their own configuration options to 
menus in the form of packages installable from the "Installer". This is 
why we remove functionality. So we can focus on how to make sure our 
products are extensible.

Simplify and Open.

   -Sean

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [openmoko-announce] Openmoko on Design

[Michele Renda]

On Wednesday 30 July 2008 04:37:20 Christopher White wrote:

Hi Cristopher, let me to understand why you are so in angry.

> My frustration comes off as anger because I just can't seem to figure
> out where to go at times.  I know I signed up for a tough road, and I am
> not afraid to rollup my sleeves and strace a process to see why it's
> hung.
>
> But it's **sloooww** to come up to speed.  It's practically a vertical
> learning curve.

This is the hard work of pioneers :) Usually are them that take all 
disadvantage of a new technology and took the "arrow" by Indians. But our 
experience is very important and will help the persons will come after us.

You work, and your experience are really important for Openmoko.

In this moment I am thinking to the very early adopter of Neo 1973

> I'm sharing this with the folks at OpenMoko because *they* have the most
> experience with this device, if anything because it's been in their
> hands for a *lot* longer.  Their wisdom is golden.  Right now, it comes
> out in bits and pieces on the wiki and in email.  Finding the answers is
> tough.
>
> Please don't take this as severe criticism.  Instead understand that I'd
> like to try and influence the immediate direction of the folks at
> OpenMoko to work on helping the masses of developers like me and Jay and
> others that want to dive in, but we're severely hindered by the current
> state, which may require pulling people of projects temporarily.  It's
> like sacrificing a little time on ASU goals to get the rest of us up to
> speed.  In the long run, that will be a much bigger pay off.
>

I understand that you did it in a constructive way, and this is nice. The 
problem is that when the critics become too much as in these days, in place to 
take the effect to put the OM developer "to give the max" put the developer to 
felt criticized in every side, and I think you get the opposite effect.

Remember they are only persons.

> Forgive me...which is the GTK version?  Are you speaking of FSO, or
> 2007.2, or some new version?  It sounds very appealing.

I am speaking 2007.2. but with all these names :)

> I have tried very hard to voice my complaint along *with* a suggestion.
> I held my tongue for a while on this topic because I don't want to be
> "yet another whiner".  But there often a grain of wisdom to the masses,
> thus I felt it necessary to validate some of the complaints of others.
>

I thinks that complaints are enough validated for now. There are some problem 
and I hope them will be fixed fast.

>
> I am very excited about itjust ready to kick off the mud already ;-)

... and I read also about Ubuntu ARM  

>
> Thank you Michele, forgive me if I sounded harsh.  I am a satisfied, if
> temporarily frustrated, customer.

I think you wrote in a constructive way, so it is important.
May be one time, when we will have our GTA99 we will read these email and we 
will smile about it :)

Regards
Michele Renda

> ...cj
>
>
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko on Design

[Sean Moss-Pultz]

On 7/29/08 david varnes wrote:
> On Tue, Jul 29, 2008 at 4:22 AM, Sean Moss-Pultz <[EMAIL PROTECTED]> 
> wrote:
> [snip]
> > >
> > > Think of our products as museums. We're building the environment.
> 
> I re-read Sean's post a couple of time (like a few people I am 
> guessing   :-) 
> For some of us 'museum' may have an old/musty connotation.
> 
> When I put "art gallery" everywhere he says "museum", it landed in my
> my ears very differently:-) 
> 

Marek likes "art gallery" better, too. I hope this gets the point across.

Ryan Paul wrote the following in Ars Technica:

   "Openmoko's potential for success will be heavily predicated on the
ability to turn choice and diversity into an asset rather than an
impediment.

This is the essense of what we're doing with efforts like FSO (the 
future framework of ASU and more) and our Installer. We (Openmoko) focus 
on making a very attractive "museum" or, if you prefer, "art gallery".

We embracing the need to figure out *what needs to be made the most 
simple*. We then try to focus on what is needed to grow and diversify 
human interests as they change.

   -Sean

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko on Design

[Sean Moss-Pultz]

On 7/29/08 ian douglas wrote:
> I feel that Sean has just given us (or perhaps just reiterated what
> should have already been known), as a community, the means to empower
> ourselves to help on *everything* about the Openmoko project as a 
> whole.
> We wanted an open platform, and it's been given to us. We're *all* 
> part
> of that design.

Thank you Ian. Very well said.

   -Sean

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [openmoko-announce] Openmoko on Design

[Sean Moss-Pultz]

On 7/29/08 Stroller wrote:
> Initially I was  
> really angry about the whole removal-of-the-keyboard-button-by- 
> shadowy-designers thing, and I've come to realise it's irrelevant and 
>  
> that I was stupid to get upset about it.

Please don't think it's irrelevant. It's anything but. This is the 
essence of what we're making. An empy vessel for you to personalize.

We make something simple but powerful. Removing and adding meaning.

   -Sean

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko on Design

[Charles-Henri Gros]

Scott wrote:
> Charles,
> 
> While that is a means of bringing the keyboard button back, thats just
> too damn hard!  And I have to do that all over again if I upgrade!
> 
> Needs to be a simple configuration setting.

Agreed, but I was just replying to that part:

> if you HAVE to leave them out could someone post easy to
> follow directions to replace them in the wiki somewhere?? For those of
> us not gifted with totally amazing programming skills?

-- 
Charles-Henri


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko on Design

[John Lee]

On Wed, Jul 30, 2008 at 01:47:29AM +0100, Al Johnson wrote:
> I'll snip most of it to keep the length reasonable.

same here :)

> On Tuesday 29 July 2008, William Lai wrote:
> >
> > It already is.
> > We've offered a couple of different solutions to community requests that
> > were declined by, well, engineering.  One of them was:
> >
> > * create a package to be installed through installer adding manual
> > qwerty button to illume theme.
> 
> The only suggestion I remember was that the community fork illume. Is this a 
> different take on the same suggestion, or a different suggestion? What was 
> the other option? And what was the objection to providing it as a 
> configuration option with the default being off, as proposed on this list?


What we are trying to do:

provide a OM repository and a community repository.  in this
particular case, if in the end the illume still shipped without kbd
button, then the community will very likely provide another version of
illume called illume-kbd in the community repository.  thus you can
replace the shipped illume with illume-kbd, and the next upgrade will
get the new version of illume-kbd instead of illume, so you don't need
to change it again after upgrade.


Where we are right at the moment:

illume is there.

the community repository is not ready yet but we're working on it.

the dependency handling of replacing the shipped illume with
illume-kbd is not ready yet but we're working on it.


My personal comment on this:

if the illume is so much more popular then illume-kdb (theoretically
we can know that from the repository log) or the other way around then
you bet that fact will be very effective in OM.  ;)


Regards,
John

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko on Design

[Marek Lindner]

On Wednesday, 30. July 2008 10:18:33 Al Johnson wrote:
> I agree with everything you say here. The keyboard should just appear when
> I want it and disappear when I don't. The absence of a manual override
> means that whenever it gets it wrong I can't correct it, the worst case
> being when I need to enter something but the keyboard doesn't appear.
> Conversely the presence of a manual override causes no problem even if it
> is never needed.
>
> The keyboard failing to appear is not a hypothetical scenario. Without
> manual intervention minimo was unusable because the keyboard didn't appear
> when the cursor was placed for URL entry. This is likely to be an issue
> with other apps that don't have a specific openmoko port, and we shouldn't
> have to create such a port just to use an otherwise capable app on
> openmoko. Other issues include the keyboard appearing when an edit field
> has focus although I don't want to edit it, keyboard appearing and
> disappearing frequently if a form contains mixed input types, or appearing
> over the top of the field to be edited. The field having focus although
> editing is not required is probably impossible to detect because the answer
> depends on the opinion of the user at the time.

I understand your points and they all are valid. How do we address them ? That 
brings us back to Seans mail. Openmoko will provide the minimum set of 
applications and basic functionality that empowers ordinary users to use the 
phone. We will make sure that these applications work well with the 
environment we provide. This is an ongoing process we just started compared 
to many established phone systems. 
Feel invited to extend that basic system through packages that can be 
installed. If you install an application that hasn't been ported to the 
Openmoko platform and does not support the keyboard you also should install 
the manual keyboard button or you just install a package which deativates the 
automatic keyboard behaviour right away if you don't like it.
We have to realize that the world is very diverse - we wont find a solution 
which suits for everybody in all the cases. So, we have to make it flexible. 
Again: This is a process and you can help us with that.


Marek


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [openmoko-announce] Openmoko on Design

[Christopher White]

Hi Michele,

> Cristopher, let me to understand why you are so in angry.

Forgive me if I came across as very angry.  I actually am not.  I am
frustrated, but I do not find fault with anyone in this regard.

> Like you I sent my 350 Eur postcard (= 2 month of my house rent) for a
> phone that I was knowing was not software complete (and some possible
> hardware bug).
> 
> OM wrote very well on the homepage that is not a end user product. They
> wrote very well. I bought my phone knowing that it will show me "things
> we human can't neither to image (and not in the good sense)"

You are absolutely correct.  I fully understood what I was getting into,
as I think most people on this list did.  By no means did I expect an
end user product.

> Then now we can choose: we can use the 2007 gtk version or the new
> version. Is our freedom. Why we must to be in angry if we have the choose?

You are correct that it was my choice to join the club.  Let me expand
on my frustration.  I think it is first and foremost a matter of clear
channels of communication.

My frustration comes off as anger because I just can't seem to figure
out where to go at times.  I know I signed up for a tough road, and I am
not afraid to rollup my sleeves and strace a process to see why it's
hung.  

But it's **sloooww** to come up to speed.  It's practically a vertical
learning curve.

I'm sharing this with the folks at OpenMoko because *they* have the most
experience with this device, if anything because it's been in their
hands for a *lot* longer.  Their wisdom is golden.  Right now, it comes
out in bits and pieces on the wiki and in email.  Finding the answers is
tough.  

Please don't take this as severe criticism.  Instead understand that I'd
like to try and influence the immediate direction of the folks at
OpenMoko to work on helping the masses of developers like me and Jay and
others that want to dive in, but we're severely hindered by the current
state, which may require pulling people of projects temporarily.  It's
like sacrificing a little time on ASU goals to get the rest of us up to
speed.  In the long run, that will be a much bigger pay off.

> Openmoko never said that will do that will make impossible to install
> the gtk version. If you use it, and you maintain it, it will become
> better and will take the place of ASU.

Forgive me...which is the GTK version?  Are you speaking of FSO, or
2007.2, or some new version?  It sounds very appealing.

> But please, is not the situation to complain if you install the aplha
> version and it is not running stable.

I have tried very hard to voice my complaint along *with* a suggestion.
I held my tongue for a while on this topic because I don't want to be
"yet another whiner".  But there often a grain of wisdom to the masses,
thus I felt it necessary to validate some of the complaints of others.

> You must to take Openmoko as a piece of "free" hardware. Install then
> what you want, and be happy.

I am very excited about itjust ready to kick off the mud already ;-)

> Now I wish you a very nice day, and happy programming ( or experimenting).

Thank you Michele, forgive me if I sounded harsh.  I am a satisfied, if
temporarily frustrated, customer.

...cj



___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko on Design

[Al Johnson]

On Wednesday 30 July 2008, Marek Lindner wrote:
> On Wednesday, 30. July 2008 04:57:27 Chris Wright wrote:
> > Something as simple as a keyboard button -- well, users were
> > complaining about its lack very quickly. If the design team were also
> > users, then they would have insisted that the error be fixed.
>
> They _are_ users and kept complaining all the time why we have to push the
> damn button. The software should know that we want to type something.
> Yes, they are no engineers but I try to see that as a plus not a burden.
> Their perception is to have software that gets invisible while enabling the
> user to get the real job done and not the other way round.

I agree with everything you say here. The keyboard should just appear when I 
want it and disappear when I don't. The absence of a manual override means 
that whenever it gets it wrong I can't correct it, the worst case being when 
I need to enter something but the keyboard doesn't appear. Conversely the 
presence of a manual override causes no problem even if it is never needed.

The keyboard failing to appear is not a hypothetical scenario. Without manual 
intervention minimo was unusable because the keyboard didn't appear when the 
cursor was placed for URL entry. This is likely to be an issue with other 
apps that don't have a specific openmoko port, and we shouldn't have to 
create such a port just to use an otherwise capable app on openmoko. Other 
issues include the keyboard appearing when an edit field has focus although I 
don't want to edit it, keyboard appearing and disappearing frequently if a 
form contains mixed input types, or appearing over the top of the field to be 
edited. The field having focus although editing is not required is probably 
impossible to detect because the answer depends on the opinion of the user at 
the time.


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko on Design

[The Rasterman]

On Tue, 29 Jul 2008 20:56:23 -0400 Daniel Benoy <[EMAIL PROTECTED]> babbled:

> Is it feasible to have illume detect that an application isn't 
> capable/interested in sending the signal to bring up the keyboard?

with the matchbox protocol - it is not possible. with the new protocol i put in
(which uses window properties) it is possible to know. the app will explicitly
set a property on its window indicating its desired keyboard state.

> Also, would the openmoko design team be willing to consider a  toggle in the 
> configuration menu between manual and automatic?
> 
> I have a portable bluetooth keyboard (Something which I assume the design
> team wants to eventually support out-of-the-box) and it's annoying for the on 
> screen keyboard to ever come up for me unless I specifically ask for it 
> because it reduces my usable window space, so in my case, I would prefer to 
> set it to manual. (And I have modified my illume theme to achieve that)

actually i just committed code that "in theory" detects extra keyboards (bt,
usb - not tested) and forcibly disables and vkbd if you have one attached. i
know - it'd be nice to even have this behavior a conifg value and able to be
overridden... that's a matter of code - enough of it, but for now, it probably
covers 99% of use cases in the event of a bt/usb kbd... but as i said - it's
untested right now (it works - if i fake it - so the code works, but detection
of the keyboard is still untested - it should work... in theory).

it's in latest rev of illume in svn, no nightly build or update to asu.dev
git... yet... will do soon.

> If I didn't have a bluetooth keyboard, I'd prefer for it to be automatic, but 
> provide me with a manual toggle (automatically) when I'm currently looking at 
> software which doesn't know how to ask for the keyboard..
> 
> I think this is a good compromise, and in the best interests of the platform 
> because of the value of quick-and-dirty linux X11 application porting, but at 
> the same time end-consumers who only use pre-installed software will never 
> even know the toggle is there, so the designers should be happy.
> 
> I hope I'm not adding to the flame war :(  I really appreciate the hard work 
> and money that openmoko is putting into this project for me and the rest of 
> the community .. and I don't want them to feel underappreciated as a result 
> of all the nitpicks.

it's up to the designers to say if they want it or not. me - personally, agree.
i also don't see the harm in keeping the toggle if the app can do it
automatically anyway - as you may not want to edit anything - just browse (eg
web browser - the javascript forces a editable field to be focused - thus the
kbd pops up - but you have no desire to edit - you just want to read... so tap
the button to pop it down). but that's just my opinion.

> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community


-- 
Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]>

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko on Design

[Marek Lindner]

On Wednesday, 30. July 2008 04:57:27 Chris Wright wrote:
> Where I work, the design team is the same as the development team.

May I ask where you work and what kind of consumer products you are creating ?


> Something as simple as a keyboard button -- well, users were
> complaining about its lack very quickly. If the design team were also
> users, then they would have insisted that the error be fixed.

They _are_ users and kept complaining all the time why we have to push the 
damn button. The software should know that we want to type something.
Yes, they are no engineers but I try to see that as a plus not a burden. Their 
perception is to have software that gets invisible while enabling the user to 
get the real job done and not the other way round.


Marek


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko on Design

[Daniel Benoy]

Is it feasible to have illume detect that an application isn't 
capable/interested in sending the signal to bring up the keyboard?

Also, would the openmoko design team be willing to consider a  toggle in the 
configuration menu between manual and automatic?

I have a portable bluetooth keyboard (Something which I assume the design team 
wants to eventually support out-of-the-box) and it's annoying for the on 
screen keyboard to ever come up for me unless I specifically ask for it 
because it reduces my usable window space, so in my case, I would prefer to 
set it to manual. (And I have modified my illume theme to achieve that)

If I didn't have a bluetooth keyboard, I'd prefer for it to be automatic, but 
provide me with a manual toggle (automatically) when I'm currently looking at 
software which doesn't know how to ask for the keyboard..

I think this is a good compromise, and in the best interests of the platform 
because of the value of quick-and-dirty linux X11 application porting, but at 
the same time end-consumers who only use pre-installed software will never 
even know the toggle is there, so the designers should be happy.

I hope I'm not adding to the flame war :(  I really appreciate the hard work 
and money that openmoko is putting into this project for me and the rest of 
the community .. and I don't want them to feel underappreciated as a result 
of all the nitpicks.

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko on Design

[Al Johnson]

Many thanks for the direct answers. This is what I've been hoping for. I'll 
snip most of it to keep the length reasonable.

On Tuesday 29 July 2008, William Lai wrote:
> No bad intentions for snipping,
> Just trying to get to the facts:
>
> Brian C wrote:
Snipped
> > 3) If the design department is operating from a design document, has it
> > been made public?  If so, where?  If not, why not?
>
> Design doc uploaded (sometime in April)
> http://people.openmoko.org/ninjutsu/freerunner1.4.swf
>
> Posted by Ian Darwin in May
> http://lists.openmoko.org/pipermail/community/2008-May/017504.htm

Just in case anyone wonders why it comes back not found, typo corrected
http://lists.openmoko.org/pipermail/community/2008-May/017504.html

> Feature Plan tracking
> http://wiki.openmoko.org/wiki/ASU_Feature_Plan
>
> Bug Tracking:
> https://docs.openmoko.org/trac/milestone/ASU
>
> You get the point.

I think so. There's some documentation but nothing particularly detailed, and 
details weren't set in stone as of Ian's post in May when the keyboard toggle 
existed. It has been public, but perhaps not widely known about, for quite 
some time. Comments in the bug tracker reference a discussion on the 
openmoko-devel list which I assume to be one of these:
http://www.mail-archive.com/openmoko-devel%40lists.openmoko.org/msg02263.html
http://www.mail-archive.com/openmoko-devel%40lists.openmoko.org/msg01542.html

Big chunk of snippage...

> > If so, will such
> > community members also have a voice in underlying design decisions that
> > guide that/those framework(s)?
>
> It already is.
> We've offered a couple of different solutions to community requests that
> were declined by, well, engineering.  One of them was:
>
> * create a package to be installed through installer adding manual
> qwerty button to illume theme.

The only suggestion I remember was that the community fork illume. Is this a 
different take on the same suggestion, or a different suggestion? What was 
the other option? And what was the objection to providing it as a 
configuration option with the default being off, as proposed on this list?



___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko on Design

[The Rasterman]

On Wed, 30 Jul 2008 01:05:35 +0800 Marek Lindner <[EMAIL PROTECTED]> babbled:

> Do you mean that sentence: 
> "we are paid by openmoko to do what  we are told to do by the design 
> department and that is what we then do." If that's the state of things for 
> paid developers, then community contributors have even less hope.
> 
> Again, this is the statement from a single developer - I _definitely_ don't 
> agree with that. This is simply not the way it is. Honestly, I have never 
> seen a company that gives so much freedom to its employees. Sometimes I even 
> have the feeling this is more a democracy instead of a business here.  :-)

oooh.. i have to make this clear. this is EXACTLY how it has become. i have
done things differently in the past - because that was just what i saw needed
doing. i have disagreed. i have changed things to make things work better
(imho). and the response to this has been "grumble grumble - we don't like you
wasting all your time on things not in the design, but you just do whatever
you want to anyway because you can (and implied is the we don't like what you
do - but have very little ability to stop it)".

in fact even you were there at the time that was said. you have missed the
other time it was very explicitly stated to me in a meeting. i have rescinded my
freedom to do what i think is right, and do what i am instructed. those unhappy
with my "doing things different to/outside of the design" do not want to argue
- i don't either. so to cease arguments, i do as instructed. you joined
openmoko after we started on ASU and have missed a lot of history.

i also will disagree with openmoko giving developers so much freedom - i have
worked with significantly more freedom in the past at linux/open source
companies. much more. openmoko is middle-of-the-road in this department, and not
an outstanding beacon, neither is it a sweatshop dungeon :)

-- 
Carsten Haitzler (The Rasterman) <[EMAIL PROTECTED]>

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

RE: Openmoko on Design

[steve]

Thanks marek.

   

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Marek Lindner
Sent: Tuesday, July 29, 2008 10:06 AM
To: List for Openmoko community discussion
Subject: Re: Openmoko on Design

On Tuesday, 29. July 2008 19:19:10 Al Johnson wrote:
> Whether the term is 'key developer' or just 'a developer' is irrelevant.
> The issue is the total lack of communication over removal of a 
> function many in the community, not to mention said developer, have 
> good technical reasons to see as absolutely vital.

Unfortunately, this tiny difference is important because it sounded like
"Even THE key developer (and god knows who else) objected and still you did
it!". 


> Diversity of opinion is fine and expected, but we needed to hear what the
> other opinions were!

True, and you did hear it.


> I thought that was the whole point too, but your answer seems only to
> answer one of the two questions. You seem to be saying 'Of course you can
> submit code, and if we like it we'll use it' but saying nothing about
> whether the community has a voice in the decision. It would be helpful to
> know before embarking on implementation whether the idea conflicts with
one
> or more of the unstated ideals by which inclusion may be judged.

You should realize that we (Openmoko) are vastly outnumbered by the tasks on

our ToDo list and the mails we have to process. For us it is very hard to 
grep out the genius and doable ideas - it is just too much !
But if you can provide a working prototype of your idea you can be sure that

we seriously look at it. We simply install it, play with it and eventually 
get infected by it. In the end we are geeks as well and like to see cool 
stuff.  :-)


> I think so, but I think the rest of the paragraph, particularly the
> preceding sentence, was at least as important. Since you snipped it I'm
not
> sure you feel the same way.

Do you mean that sentence: 
"we are paid by openmoko to do what  we are told to do by the design 
department and that is what we then do." If that's the state of things for 
paid developers, then community contributors have even less hope.

Again, this is the statement from a single developer - I _definitely_ don't 
agree with that. This is simply not the way it is. Honestly, I have never 
seen a company that gives so much freedom to its employees. Sometimes I even

have the feeling this is more a democracy instead of a business here.  :-)


Marek


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko on Design

[Chris Wright]

2008/7/29 Marek Lindner <[EMAIL PROTECTED]>:
> On Tuesday, 29. July 2008 20:17:00 Chris Wright wrote:
>> But you do have a design team, according to Rasterman.
>
> Of course we have. How do you think we are trying to get to a device that is
> ready for end user ? And this is just the beginning. We will work with more
> designers for the UI, the housing, etc to continue the direction towards the
> mass market.
> But that does not mean all that is perfect right from the beginning or that we
> don't listen to constructive criticism. Please help us making it better by
> _demonstrating_ a superior solution not by sending more emails.

Where I work, the design team is the same as the development team.

>> Out of curiosity, how many of these developers use an Openmoko phone
>> as their primary phone?
>
> What do you mean with "these" developers ? Everybody certainly has a different
> opinion than others on something.

Then it's vacuous to say so.

>> Do these differences of opinion tend to fall on the same boundaries?
>
> I don't get what you trying to say here.

Something as simple as a keyboard button -- well, users were
complaining about its lack very quickly. If the design team were also
users, then they would have insisted that the error be fixed.

>> Still, nobody has mentioned why the design team can't be contacted or
>> identified.
>
> Sorry but this is just not true. I don't get why you follow this childish
> witch-hunt game.

Because you were responding to this quote:
> This also seemed to reveal something about the internals of
> Openmoko that weren't expected: development decisions are not entirely
> made by the developers, but instead they answer to some people who the
> community cannot readily identify and who the community doesn't know how
> to interact with or if they even can interact with these decision-makers.

And your response was in no way related. I was merely pointing that out.

>> Strange, I read this as "Openmoko has not been, but should in the
>> future, trust those members"
>>
>> I haven't been here long enough to determine which is the case. Maybe
>> the company hasn't, either.
>
> Meant was: Openmoko pays much more attention to installable solutions and
> listens to hackers that provide those instead to people that complain all day
> long but don't get their hands dirty.

Okay.

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko on Design

[William Lai]

No bad intentions for snipping,
Just trying to get to the facts:

Brian C wrote:
> 
> 1) Who is Openmoko's "design department"?


That would be:

William Lai - PM
Regina Kim - Testing
Wendy Hung - Testing


> 2) Many in the community believed that Openmoko wanted the community to
> contribute code to the core applications/functionality of the software
> stack.  Is this not the case?


This is still the case, yes.


> 3) If the design department is operating from a design document, has it
> been made public?  If so, where?  If not, why not?
>

Design doc uploaded (sometime in April)
http://people.openmoko.org/ninjutsu/freerunner1.4.swf

Posted by Ian Darwin in May
http://lists.openmoko.org/pipermail/community/2008-May/017504.htm

Feature Plan tracking
http://wiki.openmoko.org/wiki/ASU_Feature_Plan

Bug Tracking:
https://docs.openmoko.org/trac/milestone/ASU

You get the point.


> Sean responded with a lengthy email.  It illustrated again why he is the
> CEO.  A CEO needs to be focused on the big picture, as was his response.
>  A CEO also needs to point his or her team and the customers towards
> that vision.  Sean's email was great at this.  However, I think many in
> the community just wanted some specific answers to the questions above.


Read Above.


>  
> And while we didn't get any answer to question (1)--who is the design
> team?--we were told that an answer to question (3)--is there a design
> doc?--would require working as an Openmoko employee for several months.


Yes and No.  Ian Darwin found my asu flash doc, and I sure as hell don't 
remember telling him where it was..


>  I think the implication of this has to be that, No, there isn't a
> single design document that can be pointed to at this moment that
> explains every decision made or priority had by the Openmoko team.  OK.
>  Fine.
> 

Every decision?  No.
I can try to help,
but I barely remember what I had for breakfast..


> 
> But the community can have (at least) two distinct ways of helping with
> that giant TODO list.  1) The community can build applications that run
> on a framework delivered to us by the Openmoko team; 


Yes.


or 2) the community
> can be directly involved in working on the underlying framework on the
> device; 


Yes.


or 3) both.
> 

Yes.


> It was this incident with the keyboard that made several people believe
> option (2) was not available, and even after Sean's message, I still
> don't believe that we know the answer.  So, I'll ask again: does
> Openmoko intend to allow direct code contributions by community members
> to core components of the ASU/FSO frameworks?  


Yes.


> If so, will such
> community members also have a voice in underlying design decisions that
> guide that/those framework(s)?
> 

It already is.
We've offered a couple of different solutions to community requests that 
were declined by, well, engineering.  One of them was:

* create a package to be installed through installer adding manual 
qwerty button to illume theme.


> Further, a number of developers have repeatedly asked with respect to
> option (1): How do I design my application to work with so many
> different stacks?  What should I be targeting?  Sometimes this gets
> answered with: "Take your pick!  The ultimate goal is for all such
> applications to work regardless


How do I design a website for Safari, Firefox, Internet Explorer?
Think about it.

Openmoko is to mobile
Firefox is to internet

'Firefox' supports
html
xhtml
dhtml
php
java
flash
...

I am by no means a technical person,
does this help?

> 
> Again: it's been less than a month that the device has been on sale.  I
> believe the Openmoko team has clearly been working overtime and doing a
> great job at an overwhelming-sized task.  


Thank you.


> Everyone take a deep breath
> and let's find ways to work together.  
> 

Sure.

-

Will


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

RE: Openmoko on Design

[steve]

That's really perceptive.

If you go read Morse Peckham's book
http://www.amazon.com/Mans-Rage-Chaos-Biology-Behavior/dp/0805201424

You will understand how museuems and gallery's function; and, Sean's words
will strike you more deeply. 



 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of david varnes
Sent: Monday, July 28, 2008 5:32 PM
To: [EMAIL PROTECTED]; List for Openmoko community discussion
Subject: Re: Openmoko on Design

On Tue, Jul 29, 2008 at 4:22 AM, Sean Moss-Pultz <[EMAIL PROTECTED]> wrote:
[snip]
>
> Think of our products as museums. We're building the environment.

I re-read Sean's post a couple of time (like a few people I am guessing  :-)
For some of us 'museum' may have an old/musty connotation.

When I put "art gallery" everywhere he says "museum", it landed in my
my ears very differently   :-)

[snip]
> Like Will already said, by removing a manual keyboard button we are 
> forced to self-organize using the resources in our environment.
[snip]

A  lot of re-organizing in the real world comes with some pain ..
but often, less is more in genuinely good design.

This is an interesting ride ... it's good to be able to ride along.

Interesting post Sean,
thanks!
davidv

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

RE: Openmoko on Design

[steve]

Jay,

   you need to chill. You are being really disrepectful to a fellow human
who has worked tirelessly on
   this stuff for years. I know you have some passion about this too, but
you need to dial down the rhetoric
   a notch or 52.



-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jay Vaughan
Sent: Monday, July 28, 2008 1:21 PM
To: [EMAIL PROTECTED]; List for Openmoko community discussion
Subject: Re: Openmoko on Design

> Let's start simple. And grow. I know we can get there!


Get where exactly?  Got coordinates for that destination?  By the sounds of
it, not really ..

;
--
Jay Vaughan





___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko on Design

[Marek Lindner]

On Tuesday, 29. July 2008 20:17:00 Chris Wright wrote:
> But you do have a design team, according to Rasterman.

Of course we have. How do you think we are trying to get to a device that is 
ready for end user ? And this is just the beginning. We will work with more 
designers for the UI, the housing, etc to continue the direction towards the 
mass market.
But that does not mean all that is perfect right from the beginning or that we 
don't listen to constructive criticism. Please help us making it better by 
_demonstrating_ a superior solution not by sending more emails.


> Out of curiosity, how many of these developers use an Openmoko phone
> as their primary phone?

What do you mean with "these" developers ? Everybody certainly has a different 
opinion than others on something. 


> Do these differences of opinion tend to fall on the same boundaries?

I don't get what you trying to say here.


> Still, nobody has mentioned why the design team can't be contacted or
> identified.

Sorry but this is just not true. I don't get why you follow this childish 
witch-hunt game.


> Strange, I read this as "Openmoko has not been, but should in the
> future, trust those members"
>
> I haven't been here long enough to determine which is the case. Maybe
> the company hasn't, either.

Meant was: Openmoko pays much more attention to installable solutions and 
listens to hackers that provide those instead to people that complain all day 
long but don't get their hands dirty.


Marek


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [openmoko-announce] Openmoko on Design

[Michele Renda]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Cristopher, let me to understand why you are so in angry.

Like you I sent my 350 Eur postcard (= 2 month of my house rent) for a
phone that I was knowing was not software complete (and some possible
hardware bug).

OM wrote very well on the homepage that is not a end user product. They
wrote very well. I bought my phone knowing that it will show me "things
we human can't neither to image (and not in the good sense)"

I think we was knowing very well what it mean.

Then OM give it the possibility to follow from the alpha version the
next software framework. It is like the first version of KDE4: all was
knowing that was a realy big revolution, and it need time.

Then now we can choose: we can use the 2007 gtk version or the new
version. Is our freedom. Why we must to be in angry if we have the choose?

Some people worked and bring us the possibility to install Debian + XFCE
(I was not beliving to my eyes). If you want the GTK version use and
maintain it.

Openmoko never said that will do that will make impossible to install
the gtk version. If you use it, and you maintain it, it will become
better and will take the place of ASU.

But please, is not the situation to complain if you install the aplha
version and it is not running stable.


You must to take Openmoko as a piece of "free" hardware. Install then
what you want, and be happy.

About Jay, I apologize if I attached personally it, but he was attaching
a lot of person of this ML, and it was not too much nice.

Now I wish you a very nice day, and happy programming ( or experimenting).


PS. If you want to enjoy with programming, try to see something about
python and pygtk. It gave me some satisfactions with only a few of hours
of work. May be it can be surprice you.

Regards
Michele Renda

Christopher White wrote:
> On Tue, 2008-07-29 at 16:02 +0200, Michele Renda wrote:
>> I think this require some hours hour man-time (let suppose 3-4 h)
> 
> I'll agree that responding as Jay has takes considerable time, but I
> disagree with what a person can do.
> 
>> In 3-4 hours a person can do:
>>
>>  To learn a bit how to write an little application for Freerunner
>>  (To start you need around 2-3 hour of intensive study, if you
>>   have experience in programming)
> 
> I've been poking at FR for probably a good 20hrs now.  Flash,
> reflashing, playing, poking, looking for logs, looking for hooks. 
> 
> And I still haven't started programming yet (yes, i have embedded linux
> experience).
> 
> I spent an hour *just* trying to figure out why exposure was not
> starting up.  In the end, I could not and just gave up.
> 
>>  To check 10 pages of the Wiki updating old information
> 
> Ok, that assumes I have something to contribute.  After 20 hrs on my FR,
> and countless hours over the last year reading the list, I do not feel
> very confident in *any* of my methods yet to start sharing them with
> others.  
> 
>>  Start to know of to make a theme for Openmoko
> 
> Yikes, I wouldn't even know where to start if I wanted to do that.
> 
>>  Go out buy a postcard and to send it to Openmoko team that will be
>> happy that someone is thinking to them
> 
> Well...that's some blue sky thinking for you!  Tell you what I did do,
> though...I sent them a virtual postcard with $369 attached ;-)
> 
> I vent now because I'm frustrated.  My wheels are spinning in the mud.
> I have some great ideas but and can't seem to get traction in the
> product.  That's why you hear so much on this topic.  Jay already has 3
> projects *underway* -- he has clearly invested a lot more time
> implementing for the phone than he has emailing about it.
> 
> This is the 3rd time I've started a message on this thread.  It always
> gets to the point where I want to make concrete suggestions on how to
> improve.  That's where it gets messy.  I'm too lost in finding the right
> set of magic commands to fix the problem of the day to figure out what
> would make it better...
> 
> More than anything, my suggestion to the OpenMoko team -- get things
> *stable*.  Stop all new development until you get it stable.  The build
> process, basic menuing, core documentation.  I still have the window
> manager crash on me periodically ...stuck with a brick until I can ssh
> in and restart X.
> 
> Until it gets stable, adding more features or more apps is just adding
> fuel to the fire.
> 
> ...cj
> 
> 
>> I am no one to tell to you how to use your time, but I personally thing
>> that continuing to use your time to repeat how many stupid things
>> Openmoko do, and complaining how many fanboy there are, is not the best
>> way to help this project. Then do you what do you think is better!
>>
>> All this in my personal opinion!
>>
>> Michele Renda
>> -BEGIN PGP SIGNATURE-
>> Version: GnuPG v1.4.9 (GNU/Linux)
>> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>>
>> iEYEARECAAYFAkiPIvYACgkQSIAU/I6SkT3eogCfUX7G2mvUJmcg6KH4KOLMWkzi
>>

Re: Openmoko on Design

[William Lai]

Chris Wright wrote:
> 
> 
> Still, nobody has mentioned why the design team can't be contacted or
> identified.
> 

Posted to the list a couple days ago:

http://lists.openmoko.org/pipermail/community/2008-July/023806.html

We can be contacted,
just wasn't using an openmoko email at the time I wrote it.

-

Will


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

RE: [openmoko-announce] Openmoko on Design

[steve]

Jay,

   you seem very passionate about your concerns. If you are going to linux
world I'd be happy to meet and discuss things.
   Or if you can make a list of specific problems I can try to explain or
address your concerns. 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jay Vaughan
Sent: Tuesday, July 29, 2008 7:53 AM
To: List for Openmoko community discussion
Subject: Re: [openmoko-announce] Openmoko on Design

> I am no one to tell to you how to use your time, but I personally 
> thing that continuing to use your time to repeat how many stupid 
> things Openmoko do, and complaining how many fanboy there are, is not 
> the best way to help this project. Then do you what do you think is 
> better!
>


I don't think rabid fanboix'ism is going to help the situation.  There
*are* negatives to whats going on with OpenMoko; perhaps you don't see them
because you haven't been attempting to write applications for the platform,
as I have for a year now.

Certainly, unless there is pressure to address the faults in current
strategy which are making it /so/ /very/ /hard/ for 3rd-party developers to
ramp up to productivity in promoting, and using, the OpenMoko platform, then
it won't happen.  OpenMoko *need* to know that there is dissatisfaction in
the ranks with the way they are dealing with these issues - I'm only one of
about 15 people who have shared the same views as me, and I'm vocal about it
because *I care*; sycophants and dilettantes are not going to make it easy
for them to see they are turning developers away, and making it difficult to
get behind the platform in a big way.

I do believe we can build a great product with OpenMoko.  I just want to
make sure that the OM community realises that there are issues at hand which
*must* be addressed if we want to make it as big as we all desire.
Certainly the current fractious nature of the distribution,  
the feature regression and creeping bugs are not making it easier.   
Something must change.

> All this in my personal opinion!
>


Thanks for sharing it in a manner we are all entitled, since this is an Open
project.  And thank you to all those people who have shared their opinions
with me privately.  If any of you wish to continue to voice an opinion about
"Jay Vaughan" and how much time he is wasting, please feel free to do so -
privately, off-list.

;
--
Jay Vaughan





___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [openmoko-announce] Openmoko on Design

[Christopher White]

On Tue, 2008-07-29 at 16:02 +0200, Michele Renda wrote:
> I think this require some hours hour man-time (let suppose 3-4 h)

I'll agree that responding as Jay has takes considerable time, but I
disagree with what a person can do.

> In 3-4 hours a person can do:
> 
>   To learn a bit how to write an little application for Freerunner
>   (To start you need around 2-3 hour of intensive study, if you
>have experience in programming)

I've been poking at FR for probably a good 20hrs now.  Flash,
reflashing, playing, poking, looking for logs, looking for hooks. 

And I still haven't started programming yet (yes, i have embedded linux
experience).

I spent an hour *just* trying to figure out why exposure was not
starting up.  In the end, I could not and just gave up.

>   To check 10 pages of the Wiki updating old information

Ok, that assumes I have something to contribute.  After 20 hrs on my FR,
and countless hours over the last year reading the list, I do not feel
very confident in *any* of my methods yet to start sharing them with
others.  

>   Start to know of to make a theme for Openmoko

Yikes, I wouldn't even know where to start if I wanted to do that.

>   Go out buy a postcard and to send it to Openmoko team that will be
> happy that someone is thinking to them

Well...that's some blue sky thinking for you!  Tell you what I did do,
though...I sent them a virtual postcard with $369 attached ;-)

I vent now because I'm frustrated.  My wheels are spinning in the mud.
I have some great ideas but and can't seem to get traction in the
product.  That's why you hear so much on this topic.  Jay already has 3
projects *underway* -- he has clearly invested a lot more time
implementing for the phone than he has emailing about it.

This is the 3rd time I've started a message on this thread.  It always
gets to the point where I want to make concrete suggestions on how to
improve.  That's where it gets messy.  I'm too lost in finding the right
set of magic commands to fix the problem of the day to figure out what
would make it better...

More than anything, my suggestion to the OpenMoko team -- get things
*stable*.  Stop all new development until you get it stable.  The build
process, basic menuing, core documentation.  I still have the window
manager crash on me periodically ...stuck with a brick until I can ssh
in and restart X.

Until it gets stable, adding more features or more apps is just adding
fuel to the fire.

...cj


> 
> I am no one to tell to you how to use your time, but I personally thing
> that continuing to use your time to repeat how many stupid things
> Openmoko do, and complaining how many fanboy there are, is not the best
> way to help this project. Then do you what do you think is better!
> 
> All this in my personal opinion!
> 
> Michele Renda
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (GNU/Linux)
> Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
> 
> iEYEARECAAYFAkiPIvYACgkQSIAU/I6SkT3eogCfUX7G2mvUJmcg6KH4KOLMWkzi
> wGoAnRjT9zbvrCXFFEf/q6I7aeRn8qeU
> =kWjH
> -END PGP SIGNATURE-
> 
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

RE: [openmoko-announce] Openmoko on Design

[steve]

Hehe.

  Michele your comment made my day and I read hundreds of emails per day 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Michele Renda
Sent: Tuesday, July 29, 2008 7:03 AM
To: List for Openmoko community discussion
Subject: Re: [openmoko-announce] Openmoko on Design

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jay Vaughan wrote:
> I'm glad OpenMoko has as many rabid fanboix as other projects, it 
> means there is hope yet ..

Usually I am not too much disposed to moderation in a ML, but now I am
started to think:

In these two days you wrote around 15 email (it is only stimated). Every
email was enought long, to explain why Openmoko suck.

I think this require some hours hour man-time (let suppose 3-4 h)

In 3-4 hours a person can do:

To learn a bit how to write an little application for Freerunner
(To start you need around 2-3 hour of intensive study, if you
 have experience in programming)

To check 10 pages of the Wiki updating old information

Start to know of to make a theme for Openmoko

Go out buy a postcard and to send it to Openmoko team that will be
happy that someone is thinking to them


I am no one to tell to you how to use your time, but I personally thing that
continuing to use your time to repeat how many stupid things Openmoko do,
and complaining how many fanboy there are, is not the best way to help this
project. Then do you what do you think is better!

All this in my personal opinion!

Michele Renda
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkiPIvYACgkQSIAU/I6SkT3eogCfUX7G2mvUJmcg6KH4KOLMWkzi
wGoAnRjT9zbvrCXFFEf/q6I7aeRn8qeU
=kWjH
-END PGP SIGNATURE-

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko on Design

[Marek Lindner]

On Tuesday, 29. July 2008 19:19:10 Al Johnson wrote:
> Whether the term is 'key developer' or just 'a developer' is irrelevant.
> The issue is the total lack of communication over removal of a function
> many in the community, not to mention said developer, have good technical
> reasons to see as absolutely vital.

Unfortunately, this tiny difference is important because it sounded like "Even 
THE key developer (and god knows who else) objected and still you did it!". 


> Diversity of opinion is fine and expected, but we needed to hear what the
> other opinions were!

True, and you did hear it.


> I thought that was the whole point too, but your answer seems only to
> answer one of the two questions. You seem to be saying 'Of course you can
> submit code, and if we like it we'll use it' but saying nothing about
> whether the community has a voice in the decision. It would be helpful to
> know before embarking on implementation whether the idea conflicts with one
> or more of the unstated ideals by which inclusion may be judged.

You should realize that we (Openmoko) are vastly outnumbered by the tasks on 
our ToDo list and the mails we have to process. For us it is very hard to 
grep out the genius and doable ideas - it is just too much !
But if you can provide a working prototype of your idea you can be sure that 
we seriously look at it. We simply install it, play with it and eventually 
get infected by it. In the end we are geeks as well and like to see cool 
stuff.  :-)


> I think so, but I think the rest of the paragraph, particularly the
> preceding sentence, was at least as important. Since you snipped it I'm not
> sure you feel the same way.

Do you mean that sentence: 
"we are paid by openmoko to do what  we are told to do by the design 
department and that is what we then do." If that's the state of things for 
paid developers, then community contributors have even less hope.

Again, this is the statement from a single developer - I _definitely_ don't 
agree with that. This is simply not the way it is. Honestly, I have never 
seen a company that gives so much freedom to its employees. Sometimes I even 
have the feeling this is more a democracy instead of a business here.  :-)


Marek


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [openmoko-announce] Openmoko on Design

[Jay Vaughan]

> I am no one to tell to you how to use your time, but I personally  
> thing
> that continuing to use your time to repeat how many stupid things
> Openmoko do, and complaining how many fanboy there are, is not the  
> best
> way to help this project. Then do you what do you think is better!
>


I don't think rabid fanboix'ism is going to help the situation.  There  
*are* negatives to whats going on with OpenMoko; perhaps you don't see  
them because you haven't been attempting to write applications for the  
platform, as I have for a year now.

Certainly, unless there is pressure to address the faults in current  
strategy which are making it /so/ /very/ /hard/ for 3rd-party  
developers to ramp up to productivity in promoting, and using, the  
OpenMoko platform, then it won't happen.  OpenMoko *need* to know that  
there is dissatisfaction in the ranks with the way they are dealing  
with these issues - I'm only one of about 15 people who have shared  
the same views as me, and I'm vocal about it because *I care*;  
sycophants and dilettantes are not going to make it easy for them to  
see they are turning developers away, and making it difficult to get  
behind the platform in a big way.

I do believe we can build a great product with OpenMoko.  I just want  
to make sure that the OM community realises that there are issues at  
hand which *must* be addressed if we want to make it as big as we all  
desire.  Certainly the current fractious nature of the distribution,  
the feature regression and creeping bugs are not making it easier.   
Something must change.

> All this in my personal opinion!
>


Thanks for sharing it in a manner we are all entitled, since this is  
an Open project.  And thank you to all those people who have shared  
their opinions with me privately.  If any of you wish to continue to  
voice an opinion about "Jay Vaughan" and how much time he is wasting,  
please feel free to do so - privately, off-list.

;
--
Jay Vaughan





___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [openmoko-announce] Openmoko on Design

[Michele Renda]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jay Vaughan wrote:
> I'm glad OpenMoko has as many rabid fanboix as other projects, it  
> means there is hope yet ..

Usually I am not too much disposed to moderation in a ML, but now I am
started to think:

In these two days you wrote around 15 email (it is only stimated). Every
email was enought long, to explain why Openmoko suck.

I think this require some hours hour man-time (let suppose 3-4 h)

In 3-4 hours a person can do:

To learn a bit how to write an little application for Freerunner
(To start you need around 2-3 hour of intensive study, if you
 have experience in programming)

To check 10 pages of the Wiki updating old information

Start to know of to make a theme for Openmoko

Go out buy a postcard and to send it to Openmoko team that will be
happy that someone is thinking to them


I am no one to tell to you how to use your time, but I personally thing
that continuing to use your time to repeat how many stupid things
Openmoko do, and complaining how many fanboy there are, is not the best
way to help this project. Then do you what do you think is better!

All this in my personal opinion!

Michele Renda
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkiPIvYACgkQSIAU/I6SkT3eogCfUX7G2mvUJmcg6KH4KOLMWkzi
wGoAnRjT9zbvrCXFFEf/q6I7aeRn8qeU
=kWjH
-END PGP SIGNATURE-

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko on Design

[Scott]

Charles,

While that is a means of bringing the keyboard button back, thats just 
too damn hard!  And I have to do that all over again if I upgrade!


Needs to be a simple configuration setting.

Scott

Charles-Henri Gros wrote:

You mean like this?

http://wiki.openmoko.org/wiki/ASU_Keyboard_Toggle





signature.asc
Description: OpenPGP digital signature
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [openmoko-announce] Openmoko on Design

[Jay Vaughan]

>> This does not work.  That is all.
> As Sean already said. You are only speaking for yourself.
>

I am not alone in my view.

> I am glad that OpenMoko is not just another half-open half-closed  
> effort
> that once thought: "Oh look Linux. It doesn't cost a dime. Let's make
> something that is flashy and blinks and develop it as proprietary as  
> we
> always did."


I'm glad OpenMoko has as many rabid fanboix as other projects, it  
means there is hope yet ..

;
--
Jay Vaughan





___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [openmoko-announce] Openmoko on Design

[Scott]

I have to agree with Kalle & Jay,

While i part of me would like to see a nailed down platform with a clear 
 definition of tools, UI standards, platform support, documentation 
standards(one I've been yelling about recently) I also understand OM's 
struggle to produce a viable open source product in record time.


I hope we can all agree to disagree and take the constructive criticism 
for what it is, constructive


I am heartened by Sean's statement  about OM's mission and their 
determination to "get it right".


I'm also happy to see this open discussion among knowledgeable people 
who are in the trenches and "getting it done".


Rock on Neo!

Scott

Kalle Happonen wrote:

Nkoli wrote:
Jay, your negative posts on this ML do nothing but foster an 
unpleasant atmosphere
Actually I disagree a bit here. Jay is not trolling but just saying 
Kalle




signature.asc
Description: OpenPGP digital signature
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko on Design

[Chris Wright]

2008/7/29 Marek Lindner <[EMAIL PROTECTED]>:
>
> Hi,
>
>> At the same time we heard comments from a key developer who indicated
>> that the decision was made above him by unnamed individuals with whom
>> the community has no obvious means of communication, and who apparently
>> don't even listen to the reasonable technical arguments of key
>> developers.
>
> Openmoko always avoided all kind of formal structures. Thus we don't have such
> a thing as "key" or "core" developer - "a" developer would be better.

But you do have a design team, according to Rasterman.

>> This also seemed to reveal something about the internals of
>> Openmoko that weren't expected: development decisions are not entirely
>> made by the developers, but instead they answer to some people who the
>> community cannot readily identify and who the community doesn't know how
>> to interact with or if they even can interact with these decision-makers.
>
> May be it revealed that Openmoko itself is diverse as well. That some
> developers have different opinions than others.

Out of curiosity, how many of these developers use an Openmoko phone
as their primary phone? Do these differences of opinion tend to fall
on the same boundaries?

Still, nobody has mentioned why the design team can't be contacted or
identified.

>> Openmoko has to trust those members of the community, who prove themselves
>> through actual contributions, to be worthy to give input on larger design
>> issues as well.
>
> You got the point !

Strange, I read this as "Openmoko has not been, but should in the
future, trust those members"

I haven't been here long enough to determine which is the case. Maybe
the company hasn't, either.

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko on Design

[Al Johnson]

On Tuesday 29 July 2008, Marek Lindner wrote:
> Hi,
>
> > At the same time we heard comments from a key developer who indicated
> > that the decision was made above him by unnamed individuals with whom
> > the community has no obvious means of communication, and who apparently
> > don't even listen to the reasonable technical arguments of key
> > developers.
>
> Openmoko always avoided all kind of formal structures. Thus we don't have
> such a thing as "key" or "core" developer - "a" developer would be better.

Whether the term is 'key developer' or just 'a developer' is irrelevant. The 
issue is the total lack of communication over removal of a function many in 
the community, not to mention said developer, have good technical reasons to 
see as absolutely vital.

> > This also seemed to reveal something about the internals of
> > Openmoko that weren't expected: development decisions are not entirely
> > made by the developers, but instead they answer to some people who the
> > community cannot readily identify and who the community doesn't know how
> > to interact with or if they even can interact with these decision-makers.
>
> May be it revealed that Openmoko itself is diverse as well. That some
> developers have different opinions than others.

Diversity of opinion is fine and expected, but we needed to hear what the 
other opinions were!

> > It was this incident with the keyboard that made several people believe
> > option (2) was not available, and even after Sean's message, I still
> > don't believe that we know the answer.  So, I'll ask again: does
> > Openmoko intend to allow direct code contributions by community members
> > to core components of the ASU/FSO frameworks?  If so, will such
> > community members also have a voice in underlying design decisions that
> > guide that/those framework(s)?
>
> if course you can - that is the whole point of Openmoko. The best way is to
> implement a solution, offer a package to install and let the people play
> with it. If your idea is convincing we will include it.

I thought that was the whole point too, but your answer seems only to answer 
one of the two questions. You seem to be saying 'Of course you can submit 
code, and if we like it we'll use it' but saying nothing about whether the 
community has a voice in the decision. It would be helpful to know before 
embarking on implementation whether the idea conflicts with one or more of 
the unstated ideals by which inclusion may be judged.

> > Openmoko has to trust those members of the community, who prove
> > themselves through actual contributions, to be worthy to give input on
> > larger design issues as well.
>
> You got the point !

I think so, but I think the rest of the paragraph, particularly the preceding 
sentence, was at least as important. Since you snipped it I'm not sure you 
feel the same way.

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [openmoko-announce] Openmoko on Design

[Robert Schuster]

Hi,

Jay Vaughan schrieb:
> [snip]
> 
> This does not work.  That is all.
As Sean already said. You are only speaking for yourself.

I am glad that OpenMoko is not just another half-open half-closed effort
 that once thought: "Oh look Linux. It doesn't cost a dime. Let's make
something that is flashy and blinks and develop it as proprietary as we
always did."

Regards
Robert



signature.asc
Description: OpenPGP digital signature
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko on Design

[Stroller]

On 29 Jul 2008, at 09:23, Marcus Bauer wrote:
> ...
> Openmoko should concentrate on kernel and driver work, power  
> management
> and working hardware and a basic set of apps. ...

+1

As Openmoko push more open hardware out the door, people will come  
running to do cool stuff on it.

It's the "blue sky" talk of "evoking innovation", "actualizing  
contributions" and "imagination resources" that is building  
excitement about Openmoko and leading to disappointment.

Honestly, if Openmoko said "the Freerunner is a free, open, Linux- 
based mobile phone that runs Trolltech's good old Qtopia phone  
software" then people would still be queuing up to buy it.

"oh, and by the way we're also developing some software of our own  
and you can try the open alpha if you want to" would be better than  
this "building the future" sort of stuff - although the latter phrase  
strictly indicates "it's not ready yet", it's far more evocative and  
emotional. We think we see our dreams *today* - no wonder people are  
peeved when they're dashed.

Stroller.




___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [openmoko-announce] Openmoko on Design

[arne anka]

> If you need a benevolent dictator to lead, why not become one yourself?
> If you need standards why not make them? This is not a responsibility
> of the Openmoko team. They already gave us the damn thing to build it
> all on. This really is the job of the community. Stop whining and start
> doing the job yourself if you want it done. It's no one else's
> responsibility.

sorry, but that's imho part of the responsibility of om -- if i don't liek  
i don't need to use it but why should i (and everyone else) invent taht  
kind of stuff?
distributors like debian/suse/redhat/... even gentoo create distributions  
so you don't need to worry about all that tedious stuff like installing,  
updating, uninstalling, keeping track of files, creating config files and  
so on.
most users of linux do not use it because the want to create their system  
 from scratch -- the are happy that someone organizes things that need to  
be taken care of and the adjust or modify where needed.

basically the same thing is it i was expecting from om.
i was hoping that these decisions  where made already and i had not to  
care about them -- i am, like probably the most of us, rather  
application-oriented, and i want to focus on managing existing  
applications and -- hopefully in a near future -- developing my own, using  
firm foundations.

those foundations do in no way harm the freedom to create a completely  
different kind of managing the freerunner, like the pure existence of  
debian or slackware didn't hinder the creation and growing up of mandrake,  
suse or redhat.
but the _user_ had a distribution to work with.

i read seans mail rather as a polite way to say "we're pissed off by all  
this criticism".
well, as a ceo of om he can't be that frank as jay or marcus bauer from  
tangogps, but certainly he has a point here.
otoh the hair raising issue of the root login or the thread regarding the  
keyboard toggle of asu prove that those being critical have valid points,  
too.

after all, we're now (imo) at the usual point with projects being so  
overeloaded with ideas and imagination:
people see the realy thing and realize that a lot of high hopes are far  
 from reality -- adapting to these new facts is a lengthy process with a  
lot of criticism until the vision and reality match.
i can fully understand that people like jay, knowing the neo1973 and  
hoping for the fr to fix a lot of shortcomings, _are_ annoyed, in  
particular when they get the impression that everything they say dies away  
unheard.

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko on Design

[Marek Lindner]

Hi,

> At the same time we heard comments from a key developer who indicated
> that the decision was made above him by unnamed individuals with whom
> the community has no obvious means of communication, and who apparently
> don't even listen to the reasonable technical arguments of key
> developers.  

Openmoko always avoided all kind of formal structures. Thus we don't have such 
a thing as "key" or "core" developer - "a" developer would be better.


> This also seemed to reveal something about the internals of 
> Openmoko that weren't expected: development decisions are not entirely
> made by the developers, but instead they answer to some people who the
> community cannot readily identify and who the community doesn't know how
> to interact with or if they even can interact with these decision-makers.

May be it revealed that Openmoko itself is diverse as well. That some 
developers have different opinions than others. 


> It was this incident with the keyboard that made several people believe
> option (2) was not available, and even after Sean's message, I still
> don't believe that we know the answer.  So, I'll ask again: does
> Openmoko intend to allow direct code contributions by community members
> to core components of the ASU/FSO frameworks?  If so, will such
> community members also have a voice in underlying design decisions that
> guide that/those framework(s)?

if course you can - that is the whole point of Openmoko. The best way is to 
implement a solution, offer a package to install and let the people play with 
it. If your idea is convincing we will include it.


> Openmoko has to trust those members of the community, who prove themselves
> through actual contributions, to be worthy to give input on larger design
> issues as well.  

You got the point !


Marek

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko on Design

[arne anka]

On Tue, 29 Jul 2008 10:23:41 +0200, Marcus Bauer <[EMAIL PROTECTED]>  
wrote:

> 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.
> ...

no i finally got what's your problem with fso.
while i in some respects agree with you i otoh are worried by the very  
limited resources of the freerunner.
on my laptop there's plenty of ram, cpu, harddisk to have all kind of apps  
and their daemons coexisting (but, using linux for over a decade now and  
coming from an k5-133 cpu, i am still annoyed and worried by the lot of  
rather needless daemons and background processes, in particular those  
evolution related ones, only for the lighntning calendar app).
the fr is far more limited in this respect, so that same kind of  
coexistence seems hardly managable.
that's where a framework seems sensible to me: a lot of functionality  
common to all kind of apps is put into a framework and there's no need to  
run concurrent processes who do basically the same thing, just because gtk  
uses gconf (or whatever) and etk something else and qt(opia) adds another  
one.

what is your idea to remedy those qualms?

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko on Design

[Marcus Bauer]

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

[snip ]

> 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.




___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko on Design

[Jay Vaughan]

> A keyboard that always automatically knows when it is needed
> sounds great in theory, but prior to that perfect keyboard being
> implemented, what happened here was that users experienced a  
> degradation
> in usability and had no obvious means of restoring the lost
> functionality.  They were understandably frustrated by this.
>


It should be noted, also, that this degradation in usability occurred  
not just with the keyboard panel functionality, but with quite a few  
other things in the OM eco-sphere as well - bluetooth, for example,  
regressed, somewhere in between 2007.8 and 2008.2, as did audio, as  
has SDL support, and I think we could really come up with a list of  
quite a few things that 'sort of almost worked, and then stopped  
completely being usable' ..  It is a sensitivity to this back-stepping  
that leads me to a more vocal opinion about how the base distro  
platform is being managed at this time.

> At the same time we heard comments from a key developer who indicated
> that the decision was made above him by unnamed individuals with whom
> the community has no obvious means of communication, and who  
> apparently
> don't even listen to the reasonable technical arguments of key
> developers.  This also seemed to reveal something about the  
> internals of
> Openmoko that weren't expected: development decisions are not entirely
> made by the developers, but instead they answer to some people who the
> community cannot readily identify and who the community doesn't know  
> how
> to interact with or if they even can interact with these decision- 
> makers.
>

Thus putting lie to the 'its open, so fix it yourself' argument'.


> This led to another set of questions.  Many in the community presumed
> that they would be permitted to contribute code/ideas/design to the
> software stack that Openmoko is developing, i.e., ASU, but if there  
> are
> unnamed designers implementing a private design superstructure that
> overrides even Openmoko developers, then the usefulness or  
> likelihood of
> thinking that an ordinary end user could become an important part of
> that development process seems extremely diminished, if not
> extinguished.  This understandably disappointed developers who had  
> hoped
> to make such core contributions.

I concur with your excellent conclusion and only wish I could've been  
more eloquent on this issue personally.

>
> Sean's email only partially succeeds at this.
>

Actually, it raised alarm bells, in these quarters.  It appeared, to  
me, to be somewhat of a smoke-cloud in an attempt to provide cover  
over a situation that is detrimental to the survival of OpenMoko as a  
whole; not just as a company, but also as a community.  It is a CEO's  
job to provide smoke and mirrors when all else fails.

> "We're building an empty vessel for you to fill with your ideas." and
> "Change anything you want to our interface and we will gladly  
> deliver it
> to everyone." and these suggest that community contributions are
> welcome, even to the interface, and those contributions will  
> sometimes,
> at least, become an officially distributed part of the Openmoko
> interface.  So that tends to counteract those fears.
>

I think this is really more of a feint on the part of an embattled  
CEO, actually.  The two conditions: "we reserve certain parts of our  
system for our own designs", and "you can contribute whatever you want  
and we will distribute it to all and sundry" are not compatible.  Does  
not compute.

> Maybe some people were expecting from day one to use it as their
> everyday phone for push email, calendar, and contacts, and web  
> browsing
> and video/mp3 playback, and GPS applications-galore, all with a
> bluetooth headset that would be operated by accelerometers or  
> something.

This is as good a spec as we're going to get, isn't it?

 >Further, a number of developers have repeatedly asked with respect to
> option (1): How do I design my application to work with so many
> different stacks?  What should I be targeting?  Sometimes this gets
> answered with: "Take your pick!  The ultimate goal is for all such
> applications to work regardless, i.e., FSO is supposedly going to run
> GTK, Qt, or whatever-based apps."  But most developers who ask this
> question don't understand how that is supposed to work and need a  
> little
> more guidance on how to go about things so that they know that they
> aren't wasting their time building something that won't end up  
> working.
> That is, it sounds like these developers NEED some sort of design
> document so that they better understand where things are headed so  
> that
> they can do their part.

For my part I can help with this - I believe that developer tutorials  
that demonstrate how to operate in these environments and still  
produce a viable result are badly needed, so I am continuing the work  
I started with my DraftNotes last year, and will expand this to include:

1. How to set up a compile

Re: Openmoko on Design

[Brian C]

Sean Moss-Pultz wrote:
> 
> Dear Community
> 
> 
> Design.

This is a long, careful response to Sean's "Openmoko on Design" post.

If one goes back to the beginning of the "Terminal for ASU" thread, what
you find is that several users were just getting things set up and
mostly working in ASU and then they upgraded and found numerous things
were broken because they no longer had a means of manually bringing up a
keyboard.  A keyboard that always automatically knows when it is needed
sounds great in theory, but prior to that perfect keyboard being
implemented, what happened here was that users experienced a degradation
in usability and had no obvious means of restoring the lost
functionality.  They were understandably frustrated by this.

At the same time we heard comments from a key developer who indicated
that the decision was made above him by unnamed individuals with whom
the community has no obvious means of communication, and who apparently
don't even listen to the reasonable technical arguments of key
developers.  This also seemed to reveal something about the internals of
Openmoko that weren't expected: development decisions are not entirely
made by the developers, but instead they answer to some people who the
community cannot readily identify and who the community doesn't know how
to interact with or if they even can interact with these decision-makers.

This led to another set of questions.  Many in the community presumed
that they would be permitted to contribute code/ideas/design to the
software stack that Openmoko is developing, i.e., ASU, but if there are
unnamed designers implementing a private design superstructure that
overrides even Openmoko developers, then the usefulness or likelihood of
thinking that an ordinary end user could become an important part of
that development process seems extremely diminished, if not
extinguished.  This understandably disappointed developers who had hoped
to make such core contributions.

When prodded to respond, Openmoko employees indicated a willingness to
answer questions.  At least the following very specific questions were
asked:

1) Who is Openmoko's "design department"?
2) Many in the community believed that Openmoko wanted the community to
contribute code to the core applications/functionality of the software
stack.  Is this not the case?
3) If the design department is operating from a design document, has it
been made public?  If so, where?  If not, why not?

Sean responded with a lengthy email.  It illustrated again why he is the
CEO.  A CEO needs to be focused on the big picture, as was his response.
 A CEO also needs to point his or her team and the customers towards
that vision.  Sean's email was great at this.  However, I think many in
the community just wanted some specific answers to the questions above.
 Sean's email only partially succeeds at this.

We learned:

"Being open doesn't mean we put the essential ideas behind each product
to a public vote." which suggests that there may be some parts of what
Openmoko is developing that the community will not have a means of
directly participating in, and tends to confirm some of the fears
expressed above.

But we also learned:

"We're building an empty vessel for you to fill with your ideas." and
"Change anything you want to our interface and we will gladly deliver it
to everyone." and these suggest that community contributions are
welcome, even to the interface, and those contributions will sometimes,
at least, become an officially distributed part of the Openmoko
interface.  So that tends to counteract those fears.

And while we didn't get any answer to question (1)--who is the design
team?--we were told that an answer to question (3)--is there a design
doc?--would require working as an Openmoko employee for several months.
 I think the implication of this has to be that, No, there isn't a
single design document that can be pointed to at this moment that
explains every decision made or priority had by the Openmoko team.  OK.
 Fine.

Everyone should step back and recognize that the device has not even
been on sale for a full month.

Maybe some people were expecting from day one to use it as their
everyday phone for push email, calendar, and contacts, and web browsing
and video/mp3 playback, and GPS applications-galore, all with a
bluetooth headset that would be operated by accelerometers or something.
 But we all recognize now that it's not there yet.

So, we all should also recognize that there are a million little (and
some big) things that need to be done to get the device to have all the
capabilities that its hardware make possible.

But the community can have (at least) two distinct ways of helping with
that giant TODO list.  1) The community can build applications that run
on a framework delivered to us by the Openmoko team; or 2) the community
can b

Re: Openmoko on Design

[Marcus Bauer]

On Mon, 2008-07-28 at 17:14 -0700, ian douglas wrote:

> And while Openmoko is working on their own framework, I have to agree
> with many other voices: knowing which platform to develop for, as a
> developer myself, is confusing.

This is exactly the point. Openmoko should be like Ubuntu: integrating
what is there and adding here and there a missing link.

Ubuntu wouldn't be there where it stands today if there would be an
"Ubuntu framework".

They are just making nice distributions and that is the key of their
success. There is no real difference between Ubuntu, Kubuntu and
Xubuntu. Gimp (GTK) will run on Kubuntu and Scribus (qt) on Ubuntu and
both do run on Xubuntu.

However, openmoko-messages will not run on "ASU".

The Framework idea is a Microsoft idea. Remember the days when you
couldn't even uninstall Internet Explorer? It was part of the
"framework".

The success of Linux is based on the freedom of choice. No frameworks
there.

Last not least: the phonekit of OM2007.2 is dbus based too and can
therefore be used with qt, etk or whatever else pleases you. This whole
argument that FSO allows "cross-toolkit" is stale.

Well, just lets go back over 99 walls...

Marcus


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko on Design

[Charles-Henri Gros]

Lisa wrote:
> ~   Folks,
> ~ I don't need a major design statement for my phone...I just want 
> a  (mostly) working phone. There is a point where "taking one more thing 
> away" doesn't make it simpler any longer, it makes it hard to figure 
> out/work on. Not having a terminal in ASU ( the general style of which I 
> like) and taking the manual keyboard switch out of ASU (which actually 
> WORKS as opposed to the automatic pop up which doesn't) were bad ideas , 
> at least for as long as this thing is going to be in pre-release. I 
> could understand it in a general release, but the people who have it now 
> are EXACTLY the kind of people who would whip it out and noodle around 
> with the terminal during lunch break if they could. I know I 
> would..or if you HAVE to leave them out could someone post easy to 
> follow directions to replace them in the wiki somewhere?? For those of 
> us not gifted with totally amazing programming skills?

You mean like this?

http://wiki.openmoko.org/wiki/ASU_Keyboard_Toggle

-- 
Charles-Henri


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [openmoko-announce] Openmoko on Design

[Jay Vaughan]

>> Jay, your negative posts on this ML do nothing but foster an
>> unpleasant atmosphere
> Actually I disagree a bit here. Jay is not trolling but just saying
> where he's trying to come from.

Thank you Kalle .. no, I'm not trolling, yes I am voicing a strong  
opinion, yes I do think the Freerunner is a cool device to hack on, no  
I don't have any plans to abandon my work, yes I would like it if  
there was a little more spirited organization towards delivering a  
*finished* system that targets users and which developers can stably  
approach.

> I'm not saying that everybody should
> immideately agree with him, but this is one of the main points of  
> having
> an open community. There NEEDS to be open criticism and discussion,  
> it's
> not like there's only one truth.

Indeed.  Keep in mind people, the Freerunner is not the only open- 
hardware project out there (Pandora, I've got my eyes on you, baby),  
its just one that has a lot of hype going for it because of the  
general interest (Apple) towards beefier cell phone computing .. how  
many times have I looked at iPhone with hungry eyes, goodness ..

> Trying to silence and belittle people
> who see differently is exactly what should be avoided. Trolling is one
> thing, but I think Linus is a great example. Having strong oppinions  
> and
> stating them can be good, even if I don't always agree, but they're
> never at least unfounded.


Linus is a champion.

;
--
Jay Vaughan





___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [openmoko-announce] Openmoko on Design

[Jay Vaughan]

> If you need a benevolent dictator to lead, why not become one  
> yourself?

Because there is one already, he just doesn't have any power to make  
smart design decisions because of some new-age hippy-dippy faff.

> If you need standards why not make them? This is not a responsibility
> of the Openmoko team. They already gave us the damn thing to build it
> all on. This really is the job of the community. Stop whining and  
> start
> doing the job yourself if you want it done. It's no one else's
> responsibility.


I am: building apps (a game, a time tool, a music system), and:  
working on developer tutorials to help my fellows also build apps they  
are interested in.  Stay tuned.

;
--
Jay Vaughan





___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko on Design

[Jay Vaughan]

> And while Openmoko is working on their own framework, I have to agree
> with many other voices: knowing which platform to develop for, as a
> developer myself, is confusing. I don't like the thought of having to
> write multiple versions of an application that caters to GTK and Qt
> separately, although I recall that the FSO framework is trying to  
> bridge
> that gap. But I also don't want to have to market my application as
> "only works on 2007.2/FSO because I use GTK" because that's the  
> route I
> chose to build my app.
>

More important to note is the hassles involved in *testing* for all  
the differing platforms.

I've got lofty dreams that my applications might actually be worth it  
to someone.  But if I have to support them on all 4 different  
platforms, thats 4 more phones I should buy and set up with the  
different environments .. hmm ..

> Personally, I signed up to help manage the wiki to make it a better
> source of information.

I'm working on developer tutorials.


;
--
Jay Vaughan





___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [openmoko-announce] Openmoko on Design

[Jay Vaughan]

> Jay, your negative posts on this ML do nothing but foster an  
> unpleasant atmosphere. Last I checked, no one put a gun to your head  
> and forced you to buy or design for the FR. If you're tired of  
> waiting for the device to become stable, sell the phone and check  
> back again in about a year.
>

What part of 'open' don't you get?  Its open.  I can criticise if I  
think its necessary.

> So once again, if you believe your time and money has been wasted on  
> the project, cut your losses now and go. Develop for another device  
> until the neo becomes more palatable to your tastes.

I'm hacking on Freerunner daily.  Its my chosen platform.  When I  
criticise the strategy and the approach being made to establish a  
platform, its because I intend to stick with it.  Wouldn't make sense  
otherwise.

;
--
Jay Vaughan





___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [openmoko-announce] Openmoko on Design

[Jay Vaughan]

> I think my first project will be called MokoBingo! (with the
> exclamation mark!)! It will check the mailing list on a regular basis
> and the Freerunner will make a squeaky noise when any of the
> following terms are encountered:


heh heh .. please do this! :)


;
--
Jay Vaughan





___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [openmoko-announce] Openmoko on Design

[Kalle Happonen]

Nkoli wrote:
> On Mon, Jul 28, 2008 at 5:22 PM, Jay Vaughan <[EMAIL PROTECTED] 
> > wrote:
>
>
> Having worked in Open-Hardware for over 15 years now, I was, in fact,
> expecting a much more coherent strategy for the software platform on
> Freerunner than just "let the community decide".  Certainly, the
> community aspect of this project is huge; I am not saying that it is
> not valuable to have such great public influence on the design; just
> that: there *has* to be a rigid design approach to guide development,
> or else we end up with a torn map navigating fork-city.
>
>
> Jay, your negative posts on this ML do nothing but foster an 
> unpleasant atmosphere
Actually I disagree a bit here. Jay is not trolling but just saying 
where he's trying to come from. I'm not saying that everybody should 
immideately agree with him, but this is one of the main points of having 
an open community. There NEEDS to be open criticism and discussion, it's 
not like there's only one truth.  Trying to silence and belittle people 
who see differently is exactly what should be avoided. Trolling is one 
thing, but I think Linus is a great example. Having strong oppinions and 
stating them can be good, even if I don't always agree, but they're 
never at least unfounded.

Kalle

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [openmoko-announce] Openmoko on Design

[Yogiz]

> blab blab blab
>
> Jay Vaughan

If you need a benevolent dictator to lead, why not become one yourself?
If you need standards why not make them? This is not a responsibility
of the Openmoko team. They already gave us the damn thing to build it
all on. This really is the job of the community. Stop whining and start
doing the job yourself if you want it done. It's no one else's
responsibility.

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko on Design

[david varnes]

On Tue, Jul 29, 2008 at 4:22 AM, Sean Moss-Pultz <[EMAIL PROTECTED]> wrote:
[snip]
>
> Think of our products as museums. We're building the environment.

I re-read Sean's post a couple of time (like a few people I am guessing  :-)
For some of us 'museum' may have an old/musty connotation.

When I put "art gallery" everywhere he says "museum", it landed in my
my ears very differently   :-)

[snip]
> Like Will already said, by removing a manual keyboard button we are
> forced to self-organize using the resources in our environment.
[snip]

A  lot of re-organizing in the real world comes with some pain ..
but often, less is more in genuinely good design.

This is an interesting ride ... it's good to be able to ride along.

Interesting post Sean,
thanks!
davidv

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko on Design

[ian douglas]

ezuall wrote:
> Potential, that is the first word that comes to mind when I think about and
> play with my freerunner.  I spent months absolutely obsessively waiting for
> the release, but when I first received it I was afraid.

I agree, there's unlimited potential.

To be honest, I was all hyped about the Freerunner, even throughout the
beta testing period before they became available for purchase, and
gladly took the risk of making a purchase for the Los Angeles group buy.

I should admit though, that despite my zeal, I'm still quite confused
myself on the whole ASU/FSO/Qtopia/2007.2 framework splits, as Jay
Vaughan has pointed out a few times.

To some degree, Sean's Email helped ease my confusion -- I see Openmoko
like Linux Torvalds (which Michele brought up) -- Openmoko has an idea
of where they want to get the phone to a basic "usable" state and to
where we community hacker/members can start adding on top of it and
making the device a household name. Openmoko has their tool of choice,
but don't care what other people develop for the phone, I'm sure the
same way Linux Torvalds probably doesn't care whether an end user
utilizes GNOME vs KDE.

And while Openmoko is working on their own framework, I have to agree
with many other voices: knowing which platform to develop for, as a
developer myself, is confusing. I don't like the thought of having to
write multiple versions of an application that caters to GTK and Qt
separately, although I recall that the FSO framework is trying to bridge
that gap. But I also don't want to have to market my application as
"only works on 2007.2/FSO because I use GTK" because that's the route I
chose to build my app.

I guess I personally envisioned the Neo1973 (GTA01) as the base model
for developers and that the Freerunner was going to have a smoother
transition into the mainstream. I agree with Sean (and several others)
that the Freerunner gets them a step closer, but Openmoko still relies
heavily on the feedback (and *participation*) of the community.

As far as "design" goes, I understood Sean's Email to say that they
don't care how we build what we build on the phone, and that even the
design of the phone (ie: case) is open to us on all levels to make it
whatever we want it to be. They're going to focus on their own framework
and hardware issues, and let us do what we do best as a community.

I still hold to a quote from Andy Powell on the community list, which
emphasizes that we all need to pitch in where we can. I agree, not all
of us have super-godlike programming skillz, and not all of us are
fluent in several languages to write the wiki, but we can ALL chip in
here and there if we're on the same page:

"If everyone put as much effort into development as they do into
bitching and whining this phone would be able to cure cancer by now."
- Andy Powell, May 6, 2008


Personally, I signed up to help manage the wiki to make it a better
source of information. I haven't got the time to invest into
kernel-level development or any hard-core programming, but I *do* have
time to review a wiki page or two every single day, and will do what I
can. If everybody had the same level of cooperation, this project would
be radically different.

At the same time, there are always going to be groups of people who are
more likely to be vocal than helpful, that's why someone coined the
phrase about how "10% of the people do 90% of the work". We will
*always* have to deal with the same questions on the mailing list over
and over and have to watch for, and manage, duplicate content on the
wiki because someone doesn't know how to use a search function. That's a
given. Instead of being harsh on these people and speaking negatively,
here's a thought: be helpful. We're only going to alienate people if we
tell people their thoughts are nonsense/worthless and "RTFM n00b".

I feel that Sean has just given us (or perhaps just reiterated what
should have already been known), as a community, the means to empower
ourselves to help on *everything* about the Openmoko project as a whole.
We wanted an open platform, and it's been given to us. We're *all* part
of that design.

Just my $0.02...

-id

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [openmoko-announce] Openmoko on Design

[Nkoli]

On Mon, Jul 28, 2008 at 5:22 PM, Jay Vaughan <[EMAIL PROTECTED]> wrote:

>
> Having worked in Open-Hardware for over 15 years now, I was, in fact,
> expecting a much more coherent strategy for the software platform on
> Freerunner than just "let the community decide".  Certainly, the
> community aspect of this project is huge; I am not saying that it is
> not valuable to have such great public influence on the design; just
> that: there *has* to be a rigid design approach to guide development,
> or else we end up with a torn map navigating fork-city.
>
>
Jay, your negative posts on this ML do nothing but foster an unpleasant
atmosphere. Last I checked, no one put a gun to your head and forced you to
buy or design for the FR. If you're tired of waiting for the device to
become stable, sell the phone and check back again in about a year.

You're complaining that a phone 2 years in the making is still imperfect.
How long did it take the newcomer Apple to complete the iphone? Iirc, they
spent 4 years on iphone v1.0 and the device still needs a lot of work.

It's easy to say 'come up with a plan and follow it through come rain or
shine' when you're a bystander. The OM team had a solid plan when the
project started. Maybe they had loftier goals than what they could
accomplish being amateurs, maybe they should have hired someone with
experience in embedded devices from the beginning, maybe they should have
licensed qtopia, maybe they should have done a lot of other things, but you
have to make mistakes in order to learn.

I think it's more to their credit that the plan has gone through several
changes because they learn what is possible and what isn't as they go. I'm
sure if they knew then what they know now, they would have made different
decisions, but then, hindsight is 20/20. I'd like to think they are a more
coordinated unit than they were 2 years ago.

So once again, if you believe your time and money has been wasted on the
project, cut your losses now and go. Develop for another device until the
neo becomes more palatable to your tastes.
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [openmoko-announce] Openmoko on Design

[Stroller]

On 28 Jul 2008, at 21:31, Jay Vaughan wrote:

>> Sorry to hear it doesn't work for you. But like I said, we each have
>> our
>> own ways of understanding and making meanings.
>> You are free to create your own meanings.
>
> I just can't see how you honestly believe all this panty-waiste
> dilettante waffling about "not having a design because its up to the
> open community" is going to drive things forward.


I read Sean's message quite differently to the way you did, apparently.

I read it as "we do have a design for ASU" and presumably when he  
said "we're not taking votes on piddly little implementation details"  
this is because FIC just want to get on with things and as quickly as  
possible and get ASU to the sate where it's the reference-platform  
(with the nice-looking GUI) that you desire.

Having said that, I had to read the message more than once to arrive  
at these conclusions. From Sean's message & Will's [1] it seems to me  
like people at Openmoko sometimes speak a different language from the  
rest of us, a language with over a thousand words for "blue sky".

I don't want to sound negative (again!) because over the weekend I've  
had a bit of a revelation about Openmoko, and I'm feeling much more  
positive than I was a couple of days ago. I've just spent quite a bit  
of time trying to express that in a reply to "Openmoko on Design"  
that I sent privately to Sean; I've asked him if I can post that to  
the list, but I don't want want to publicly post "my interpretation"  
of Openmoko if he thinks that mischaracterises them. Initially I was  
really angry about the whole removal-of-the-keyboard-button-by- 
shadowy-designers thing, and I've come to realise it's irrelevant and  
that I was stupid to get upset about it.

Nevertheless, the problem with the explanations made by Sean & Will  
is that one shouldn't have to "interpret" statements of official  
policy at all. We shouldn't be "free to create your own meanings"  
from your explanations. I found these posts surprising because they  
seem to have borrowed their manner of response from John McCain's  
recent interview on gay adoption [2]. They approached some clear and  
specific concerns in a way that geometry does not address - had they  
done so tangentially it would have been a vast improvement.

I think my first project will be called MokoBingo! (with the  
exclamation mark!)! It will check the mailing list on a regular basis  
and the Freerunner will make a squeaky noise when any of the  
following terms are encountered:

   Open, free, innovation, imaginative
   creative, community. Resources, sharing,
   imagination, struggle, essential ideas.
   Foundation, openness, art, growth.
   Self-organize,
   building dreams.
   Productive!
   Understanding, the power of open.
   diversity, change.

Actually, you will get two squeaks for "self-organize".

Stroller.




[1] [EMAIL PROTECTED] is an Openmoko employee, right?
[2] http://uk.youtube.com/watch?v=llZuoMXpr4s

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko on Design

[Lisa]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

~   Folks,
~ I don't need a major design statement for my phone...I just want 
a  (mostly) working phone. There is a point where "taking one more thing 
away" doesn't make it simpler any longer, it makes it hard to figure 
out/work on. Not having a terminal in ASU ( the general style of which I 
like) and taking the manual keyboard switch out of ASU (which actually 
WORKS as opposed to the automatic pop up which doesn't) were bad ideas , 
at least for as long as this thing is going to be in pre-release. I 
could understand it in a general release, but the people who have it now 
are EXACTLY the kind of people who would whip it out and noodle around 
with the terminal during lunch break if they could. I know I 
would..or if you HAVE to leave them out could someone post easy to 
follow directions to replace them in the wiki somewhere?? For those of 
us not gifted with totally amazing programming skills?
~Oh, and my general opinion is, if there is no bitching, no drama 
and no complaints...if no one stirs the shit and throws tantrums-it 
ain't Open Source. So get used to it everyone..if NONE of it was 
happening, guess what? We'd all be working for  (shudder) Microsoft or 
something.
~Lisa Waddell
~   :) Queen of the Drama Zone

Sean Moss-Pultz wrote:
|
|
| Dear Community
|
|
| Design.
|
| Many people seem to expect an explanation of "design" from Openmoko. 
This isn't going to happen. At least not today. Design isn't something 
static that I can stop and say here is exactly what Openmoko wants. 1+1 
= 2. We try not to talk so much about features or design styles of 
future products. For the simple reason that we’re not so sure what they 
will look like ourselves. Design, for us, is the process in which we 
start by pursuing a few essential ideas and allow for the final result 
to come into being. Notice that I am not talking about moving pixels. 
Nor I'm not talking about colors or fonts. Design, in my opinion, is not 
about technical skill. It's about personal struggle. It's the process by 
which you relentlessly force yourself to focus on exposing your 
essential ideas. This cannot be patched and merged like source codes. 
Imagine Malevich and Monet each painting half of the same painting. The 
result would surely depress them both. Being open doesn't mean we put 
the essential ideas behind each product to a public vote. Being open 
means we provide you with the tools to change our decisions.
|
| Like anything highly creative, design is always highly subjective. 
Even if I would explain the essential ideas of our products to everyone, 
they would not make sense in the way I want them to. Because you are 
only seeing one part of a very intricate long-term plan. You would need 
to work with us, full time, for many months before Openmoko's vision 
would really make sense. I can only show you the tangible pieces -- 
products. Our company is open. You are always invited into this space. 
Don't forget you are watching serious people work their ass' off. We are 
mechanics and will certainly yell, "Fuck!" when we smash our fingers or 
break things. All engineering is public from day one. It is humanly 
impossible for us not to show you things that are unfinished, 
inaccurate, flawed, and even self-destructive at times. But we have 
faith in what we're doing. Openness is our foundation. It's not a 
marketing buzzword. So my only question for you is, "Do you want to 
watch, or help?". Because if you want to just stand around and criticize 
our work, I will have to ask you to leave the shop. People are working 
here. We're trying to "Free your Phone". Stop bashing things like ASU. 
This is our work and we are in the earliest of stages. We want to share 
it with you. Understand that we are not even close to satisfied with it 
in its current state. But we can see the direction and we love how it's 
coming together. This is the design process in full effect.
|
| Think of our products as museums. We're building the environment. Each 
one different from the next. You'll get all the free art supplies you 
could imagine because we want you to add your own meaning. You choose: 
consume, create, or both. Either way you create your own meaning. It's 
about you. Our design is more like non-design. We try to "remove" 
anything obvious. And focus on what's meaningful. We're not trying to 
launch a carefully crafted message with a bling-filled user interface. 
We're building an empty vessel for you to fill with your ideas. We focus 
on making products that are open and simple. Only products that are open 
can grow as you grow. Only something simple can be used by everyone.
|
| My mom can install Firefox plugins. Can your mom personalize your 
FreeRunner?
|
| Like Will already said, by removing a manual keyboard button we are 
forced to self-organize using the resources in our environment. 
Resources such as our wiki and our Installer are still badly broken. We 

Re: [openmoko-announce] Openmoko on Design

[Michele Renda]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jay Vaughan wrote:
> It is *important* that such things as a usable GUI, which  
> looks nice, are presented very, very rapidly - there is no other way  
> for our projects to snowball than to attract the interest of those who  
> will use the hardware.  So far, nobody is enjoying the usability  
> experience, terribly much, and this is because of this attitude that  
> 'the community will fix it'.

I give you reason. A gui, a wiki are the first things that a user see.

I think a very nice gui, can convince a lot of people to buy a phone in
place of another. Wiki is the first place where a person go searching
for info.

The problem is that to did this has a cost. And big too. An artist cost
a lot and I prefer OM use his resources to take a kernel developer or an
hardware enginer.

This don't mean that OM don't need of skilled graphician and people that
can help Brenda to take care of the wiki.


> Sorry, its one thing to fixup the GPS/SD issue (which is still  
> borked), its another thing entirely to sit down before you commit any  
> further silicon and say "this doesn't work, it is not to our  
> specificaiton, we need to /design/ it better".  Glamo, SD, GPS.  Three  
> things we really do *not* want to talk too loudly about, if we want to  
> continue to attract developers.. and I am fairly convinced that it is  
> the lackadaisical attitude to the qualities of the hardware, which  
> would ordinarily be addressed through a *strong* design ethos, which  
> brought this situation about.

I don't think it was a "we don't care". Error can happen. With lucky
some were possible to be solve.
In the future they will learn by their experience, and we finally we
will have from Linux 1.0 a Ubuntu 8.04 / Fedora 9 with Gnome / Compiz /
KDE4 :)

> 
> ;
> --
> Jay Vaughan
> 
> 
> 
> 
> 
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkiOPBEACgkQSIAU/I6SkT2DIACfRYafShQRhbSz98gMb2TrGWXA
Aj4AmgK6+fuDuVTJzyr1J1PtFvxPz5fp
=/rC9
-END PGP SIGNATURE-

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko on Design

[ezuall]

Potential, that is the first word that comes to mind when I think about and
play with my freerunner.  I spent months absolutely obsessively waiting for
the release, but when I first received it I was afraid.  The gps issue was
all over the mailing list and I was thinking that things weren't working out
exactly as I wanted.  It is embarrassing that it took me some time to
recover from that initial shock (3 days) and to realise that what I held was
truly open. 

Deep down I knew it wouldn't arrive in my hands perfect, but that is the
point.  One closed device can never be perfect for everyone.  Only through
customisation and expansion can each one of us make the device perfect for
him/herself.  And we need not do this in isolation, when we do something
cool we can share it, and then others have the *choice* to implement this
feature/gimmick/personalisation on their own device, in their own way.

I have grown accustomed to companies telling me what looks pretty and how
things should work and that is part of what scares me.  There is no excuse
not to make the freerunner behave exactly the way I want it to.

To start settling into the freerunner I flashed ASU (using VMware) this
weekend and was amazed at how easy it is to customise.  Changed the icons,
created new launcher items and linked these to plain-old shell scripts to
connect to my home network etc.  Installed vte terminal, changed the font
size, to summarise:  Nothing ground breaking yet, but I did it the way I
wanted to and there is a lot of potential.

Rock on freerunners!


-- 
View this message in context: 
http://n2.nabble.com/Openmoko-on-Design-tp587159p587441.html
Sent from the Openmoko Community mailing list archive at Nabble.com.


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [openmoko-announce] Openmoko on Design

[Jay Vaughan]

> I can't speak for anybody else, but what were you actually expecting  
> of
> the Neo FR?  A finished SDK that you can develop against to build your
> app on?

Having worked in Open-Hardware for over 15 years now, I was, in fact,  
expecting a much more coherent strategy for the software platform on  
Freerunner than just "let the community decide".  Certainly, the  
community aspect of this project is huge; I am not saying that it is  
not valuable to have such great public influence on the design; just  
that: there *has* to be a rigid design approach to guide development,  
or else we end up with a torn map navigating fork-city.

>  To me this is Linux pre 1.0 with with no GNOME or KDE or XFCE
> or ... any evolved user interface.  I'm okay with that - it's early  
> days
> yet.  I can just about see what they are doing, but it's very early in
> the game.  Too early to expect a stable platform you can write your  
> apps
> against ONCE.

It may well be too early in the game, but there is definitely the  
desire among the community for a little more leadership on such issues  
as how to deliver the most basic functionality of the device.

Wasn't there some sort of design for what an "open MObile  
KOmmunicator" would try to achieve, or did it get as far as "lets make  
some expensive handsets and sell them without software to people who  
will write the software and do all the hard parts for us so that at  
the end of the day there will be users interested in the experience?"

> Ask yourself: WHY did you buy the Neo FreeRunner?  I'm curious.  Why  
> did
> you buy it after reading the wiki and just about every other piece of
> information about it said "I'm really new, not finished, alpha  
> software,
> may not work, etc, etc.".  I know why I bought it.
>

I bought it because I want to write interesting software for it, and I  
want to participate in the process of designing and developing  
interesting communications applications.  I'm doing that.  But to be  
frank, its not a very fun process when there are too many targets to  
shoot at.  It was terribly frustrating to learn that OM was the wrong  
choice for the phone and that a new start had to be made by those  
involved in delivering the basics of the distro for others - users and  
developers alike - to start targeting and using.


>> Please, for all that is merciful and mighty, *get a design* for the
>> current systems done, and make sure your team of superlative wizards
>> adhere to that design.
> How would you go about doing that?  You ask a lot of questions.  How
> would you start to answer them?


I would at least try to get all the basic phone functions working,  
even if it meant copying the designed functionality from another,  
commercial vendor, and focus on that, and only that, first and  
foremost.  I certainly would not have forked the distro and set things  
adrift vis a vis ASU/FSO/Qtopia/OM2007.2, anyway.

But look, I'm flogging a dead horse here, if only because Seans mail  
raised my ire.  I spent the whole day trying to make and take calls on  
a phone that is over 2 years in the making .. with terrible results.   
So tonight I'll try ASU, and then QTopia, and then .. ;/ and maybe  
I'll go back to OM2007.2, where I at least have a couple apps of my  
own currently, sort of (SDL is broken), running ..


;
--
Jay Vaughan





___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [openmoko-announce] Openmoko on Design

[Jay Vaughan]

> Openmoko is trying to do what can: is trying to build a phone. It is
> trying to build a running open hardware: It will not be perfect but it
> will be open. You will know all the defect and compromise token to get
> it. Then is your choose. And don't tell to me that OM hardware is  
> broken
> because you know it, while other firm's hardware that keep all closed,
> are prerfect because you don't know about defects?
>

I'm fully aware that hardware companies cover their asses with  
software fixups.

Thats not the issue I'm declaring, which is: please can we have some  
attention to the design, so that we're not constantly chasing an  
unknown.  It is *important* that such things as a usable GUI, which  
looks nice, are presented very, very rapidly - there is no other way  
for our projects to snowball than to attract the interest of those who  
will use the hardware.  So far, nobody is enjoying the usability  
experience, terribly much, and this is because of this attitude that  
'the community will fix it'.

> In this situation there is no way to drive a community. We must to  
> stop
> and to think on ourself. What we did on our phone?

I guess this is really the essence of the situation.

> I remmeber when there was the GPS/SD problem, how a lot of person
> outside OM and inside OM started to work togheter and WE did a  
> miracle.
>

Sorry, its one thing to fixup the GPS/SD issue (which is still  
borked), its another thing entirely to sit down before you commit any  
further silicon and say "this doesn't work, it is not to our  
specificaiton, we need to /design/ it better".  Glamo, SD, GPS.  Three  
things we really do *not* want to talk too loudly about, if we want to  
continue to attract developers.. and I am fairly convinced that it is  
the lackadaisical attitude to the qualities of the hardware, which  
would ordinarily be addressed through a *strong* design ethos, which  
brought this situation about.

;
--
Jay Vaughan





___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [openmoko-announce] Openmoko on Design

[Alex Kavanagh]

Jay Vaughan wrote, On 28/07/08 21:31:
>> Sorry to hear it doesn't work for you. But like I said, we each have  
>> our
>> own ways of understanding and making meanings.
>> You are free to create your own meanings.
>> 
>
>
> I just can't see how you honestly believe all this panty-waiste  
> dilettante waffling about "not having a design because its up to the  
> open community" is going to drive things forward.  Are you, or are you  
> not, committed to delivering a working phone platform that *users* and  
> developers alike are going to be interested in?  Then: some standards  
> need to be put forth, and they need to be adhered to.
>   
I can't speak for anybody else, but what were you actually expecting of
the Neo FR?  A finished SDK that you can develop against to build your
app on?To me this is Linux pre 1.0 with with no GNOME or KDE or XFCE
or ... any evolved user interface.  I'm okay with that - it's early days
yet.  I can just about see what they are doing, but it's very early in
the game.  Too early to expect a stable platform you can write your apps
against ONCE.
> Because at this point, it seems to me that you've just pissed in the  
> koolaid.  Basically, you're just selling incomplete, mediocre hardware  
> in order to cash in on the "Open Community" meme, or what?
>   
Ask yourself: WHY did you buy the Neo FreeRunner?  I'm curious.  Why did
you buy it after reading the wiki and just about every other piece of
information about it said "I'm really new, not finished, alpha software,
may not work, etc, etc.".  I know why I bought it.

> Please, for all that is merciful and mighty, *get a design* for the  
> current systems done, and make sure your team of superlative wizards  
> adhere to that design.
How would you go about doing that?  You ask a lot of questions.  How
would you start to answer them?

Cheers
Alex.

>   Provide, at the very least, a reference  
> platform for your daily bread.  Lead this community, don't just throw  
> its fates to the winds of its own desire; that is *doom* for all who  
> have invested so far in the hopes that the platform grows sufficiently  
> to make the not insignificant effort to play along, worthwhile.
>   

>
> ;
> --
> Jay Vaughan
>
>
>
>
>
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community
>   

-- 
Alex Kavanagh
Home: http://alex.kavanagh.name, [EMAIL PROTECTED]
Work: http://www.tinwood.com,[EMAIL PROTECTED]
MSN : [EMAIL PROTECTED]
XMPP: [EMAIL PROTECTED]/Gaim


___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [openmoko-announce] Openmoko on Design

[Michele Renda]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Jay Vaughan wrote:

> Because at this point, it seems to me that you've just pissed in the  
> koolaid.  Basically, you're just selling incomplete, mediocre hardware  
> in order to cash in on the "Open Community" meme, or what?

Hi Jay. First person that installed Linux 1.0 was installing a very
usable system where all the periferical was full running? Linus Torvalds
was receiving every day a lot of email where people was telling that
their new IPod was not running?

Openmoko is trying to do what can: is trying to build a phone. It is
trying to build a running open hardware: It will not be perfect but it
will be open. You will know all the defect and compromise token to get
it. Then is your choose. And don't tell to me that OM hardware is broken
because you know it, while other firm's hardware that keep all closed,
are prerfect because you don't know about defects?


> 
> Please, for all that is merciful and mighty, *get a design* for the  
> current systems done, and make sure your team of superlative wizards  
> adhere to that design.  Provide, at the very least, a reference  
> platform for your daily bread.  Lead this community, don't just throw  
> its fates to the winds of its own desire;

The problem is if the community need to be lead or if want the food ready.
When in every day I read a lot of email: This is not running, this is
bad, why to use this toolkit, why it must be so.
In this situation there is no way to drive a community. We must to stop
and to think on ourself. What we did on our phone?

I remmeber when there was the GPS/SD problem, how a lot of person
outside OM and inside OM started to work togheter and WE did a miracle.

OM "alone" couldn't be able to solve the issue, but togheter we did what
was impossible. There is still a lot of work to do. There is the need of
very talented developer, passioned people to make this project possible.

There is a Wiki, that need a lot of work, may be of a complete
restruction, there is the need to understands why umts cards doesn't
run, how to have SMS working, etc.

I am sure outside, in these ML there are a lot of very talented people,
people that can make the difference. We need them, not people that
reming we produce a mediocre hardware and incomplete software.

Freedom is hard to get

> that is *doom* for all who  
> have invested so far in the hopes that the platform grows sufficiently  
> to make the not insignificant effort to play along, worthwhile.


> 
> 
> ;
> --
> Jay Vaughan
> 
> 
> 
> 
> 
> ___
> Openmoko community mailing list
> community@lists.openmoko.org
> http://lists.openmoko.org/mailman/listinfo/community

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkiOMqcACgkQSIAU/I6SkT1ZuwCgjtAyHAK9PieUo5T4gEIgwsvp
NZ0AoINAvfbumPgD90UuYzoebrDXZv7q
=b7LD
-END PGP SIGNATURE-

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko on Design

[George Brooke]

On Mon, 28 Jul 2008 22:21:28 +0200
Jay Vaughan <[EMAIL PROTECTED]> wrote:

> > Let's start simple. And grow. I know we can get there!
> 
> 
> Get where exactly?  Got coordinates for that destination?
Maybe Tango GPS can help trace the route?

solar.george


signature.asc
Description: PGP signature
___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [openmoko-announce] Openmoko on Design

[Jay Vaughan]

> Sorry to hear it doesn't work for you. But like I said, we each have  
> our
> own ways of understanding and making meanings.
> You are free to create your own meanings.


I just can't see how you honestly believe all this panty-waiste  
dilettante waffling about "not having a design because its up to the  
open community" is going to drive things forward.  Are you, or are you  
not, committed to delivering a working phone platform that *users* and  
developers alike are going to be interested in?  Then: some standards  
need to be put forth, and they need to be adhered to.

Because at this point, it seems to me that you've just pissed in the  
koolaid.  Basically, you're just selling incomplete, mediocre hardware  
in order to cash in on the "Open Community" meme, or what?

Please, for all that is merciful and mighty, *get a design* for the  
current systems done, and make sure your team of superlative wizards  
adhere to that design.  Provide, at the very least, a reference  
platform for your daily bread.  Lead this community, don't just throw  
its fates to the winds of its own desire; that is *doom* for all who  
have invested so far in the hopes that the platform grows sufficiently  
to make the not insignificant effort to play along, worthwhile.


;
--
Jay Vaughan





___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [openmoko-announce] Openmoko on Design

[Sean Moss-Pultz]

On 7/29/08 Jay Vaughan wrote:
> [snip]
> 
> This does not work.  That is all.

Sorry to hear it doesn't work for you. But like I said, we each have our 
own ways of understanding and making meanings.

You are free to create your own meanings.

   -Sean

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko on Design

[Sean Moss-Pultz]

Hi Alex

On 7/29/08 Alex Kavanagh wrote:
> Thanks for an excellent post.  It gives me an even better insight into
> OpenMoko's vision.

Glad it helps. We will be building from here in near future. I know 
things have been a bit chaotic in the past. But we're really starting to 
come together now.

Look for more comments from everyone (including myself and the rest of 
the "mysterious design team" ;-)).

We'll get there!

> Thanks for all of the hard work!

Thank you for the complements. It really means a lot to us!

   -Sean

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko on Design

[Jay Vaughan]

> Let's start simple. And grow. I know we can get there!


Get where exactly?  Got coordinates for that destination?  By the  
sounds of it, not really ..

;
--
Jay Vaughan





___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: Openmoko on Design

[Alex Kavanagh]

Thanks for an excellent post.  It gives me an even better insight into
OpenMoko's vision.

Thanks for all of the hard work!

Cheers
Alex.


Sean Moss-Pultz wrote, On 28/07/08 19:22:
> Dear Community
>
>
> Design.
>
> Many people seem to expect an explanation of "design" from Openmoko. 
> This isn't going to happen. At least not today. Design isn't something 
> static that I can stop and say here is exactly what Openmoko wants. 1+1 
> = 2. We try not to talk so much about features or design styles of 
> future products. For the simple reason that we’re not so sure what they 
> will look like ourselves. Design, for us, is the process in which we 
> start by pursuing a few essential ideas and allow for the final result 
> to come into being. Notice that I am not talking about moving pixels. 
> Nor I'm not talking about colors or fonts. Design, in my opinion, is not 
> about technical skill. It's about personal struggle. It's the process by 
> which you relentlessly force yourself to focus on exposing your 
> essential ideas. This cannot be patched and merged like source codes. 
> Imagine Malevich and Monet each painting half of the same painting. The 
> result would surely depress them both. Being open doesn't mean we put 
> the essential ideas behind each product to a public vote. Being open 
> means we provide you with the tools to change our decisions.
>
> Like anything highly creative, design is always highly subjective. Even 
> if I would explain the essential ideas of our products to everyone, they 
> would not make sense in the way I want them to. Because you are only 
> seeing one part of a very intricate long-term plan. You would need to 
> work with us, full time, for many months before Openmoko's vision would 
> really make sense. I can only show you the tangible pieces -- products. 
> Our company is open. You are always invited into this space. Don't 
> forget you are watching serious people work their ass' off. We are 
> mechanics and will certainly yell, "Fuck!" when we smash our fingers or 
> break things. All engineering is public from day one. It is humanly 
> impossible for us not to show you things that are unfinished, 
> inaccurate, flawed, and even self-destructive at times. But we have 
> faith in what we're doing. Openness is our foundation. It's not a 
> marketing buzzword. So my only question for you is, "Do you want to 
> watch, or help?". Because if you want to just stand around and criticize 
> our work, I will have to ask you to leave the shop. People are working 
> here. We're trying to "Free your Phone". Stop bashing things like ASU. 
> This is our work and we are in the earliest of stages. We want to share 
> it with you. Understand that we are not even close to satisfied with it 
> in its current state. But we can see the direction and we love how it's 
> coming together. This is the design process in full effect.
>
> Think of our products as museums. We're building the environment. Each 
> one different from the next. You'll get all the free art supplies you 
> could imagine because we want you to add your own meaning. You choose: 
> consume, create, or both. Either way you create your own meaning. It's 
> about you. Our design is more like non-design. We try to "remove" 
> anything obvious. And focus on what's meaningful. We're not trying to 
> launch a carefully crafted message with a bling-filled user interface. 
> We're building an empty vessel for you to fill with your ideas. We focus 
> on making products that are open and simple. Only products that are open 
> can grow as you grow. Only something simple can be used by everyone.
>
> My mom can install Firefox plugins. Can your mom personalize your 
> FreeRunner?
>
> Like Will already said, by removing a manual keyboard button we are 
> forced to self-organize using the resources in our environment. 
> Resources such as our wiki and our Installer are still badly broken. We 
> need to fix these. We need to make them accessible for "normal people". 
> Every element "removed" is a chance to organize information in ways that 
> are meaningful for others. Whether you like our design or not isn't even 
> the question. You have all the tools you could possibly want to change it.
>
> At Openmoko, we're trying as hard as we can to not over design. Could 
> you imagine walking into a museum where the museum itself looked better 
> than the artwork? We're trying to give you the environment to 
> self-organize. Your code. Your ideas. Your emotions. And then share them 
> back with others. The entire point of our "Installer" is to provide a 
> simple way to bring the excitement and energy of our community into the 
> Neos of normal people. Why else would we invest so much time and money 
> into things like our framework? Or even the little things like opening 
> our CAD files and our schematics? We're building you a museum to 
> showcase the wonderful diversity of this community. It's a foundation 
> for you to stand on. We want your

Re: Openmoko on Design

[Sean Moss-Pultz]

On 7/29/08 Michele Renda wrote:
> There is a lot of work to do, and OM can't all this alone.

Exactly. This is really the essense of what I want to say. We need your 
help to organize our environment. We need to focus on this. Flashy 
design can come later if that's what's wanted.


We are open. This is the true uniqueness of our project. From the iron 
to the eyeballs. We need to make it easy to understand what this means. 
We still haven't begun to really focus on these questions. What does 
open mean to normal people? How does Openmoko make open valuable?

Let's start simple. And grow. I know we can get there!

   -Sean

___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community

Re: [openmoko-announce] Openmoko on Design

[Jay Vaughan]

[snip]

This does not work.  That is all.

;
--
Jay Vaughan





___
Openmoko community mailing list
community@lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community