Thank you for this post. It seems to be helpful.

Do you know how to download/install FSO milestone IV now? Download link disapeared some days ago from http://wiki.openmoko.org/wiki/OpenmokoFramework/Status_Update_4.

as for FSO: The new framework initiative overview wiki page is actually one of the first links from the mainpage, they even include my framework picture on the main page. From the overview page in the wiki there are links to the documentation and issue tracker sites. So, I don’t think it’s not documented.

as for ASU: I’m not involved with that. It will eventually appear factory-installed.

I tried the latest image and got ASU, which confused me quiet a bit. I also tried Qtopia, and then went back to 2007.2 and updated. It wasn’t the fastest, but it seemed stable and was pretty well documented, where the others either were super buggy or lacked openness or documentation.

One thing I look for in opensource is documentation. 2007.2 is well documented, and clearly 80% of the openmoko site is geared toward it.

I found this site accidentally via the list serve, and have to say I’m not happy with the documentation on ASU (and didn’t even know FSO existed until now…) FIC just shipped hundreds of new Freerunners with 2007.2 on it. I got news for you: Unless others hear about ASU and FSO, they’re going to be confused and hop back to the 2007.2 platform and start developing there. If you want people to be using ASU/FSO, you have to get that out there where someone’s going to see it and document what you’re doing. Nobody is going to switch to a new platform that’s not documented.

@Jorge E. Gomez
That is correct. The “2007.2 GTK Image” which ships with the freerunner is not being developed on, and is in its current state very buggy and almost unusable.

About the other available stacks:

ASU: No recommended release yet, but shows promise. It is still unusable as a phone. Some things are very buggy/slow/chrashes.

FSO: On alpha state. The only thing working is the dial-a-number function.

Qtopia: Actually mostly works! When I feel like using my Freerunner as a phone this is the stack im using. Feels fast and responsive. No one in the community is developing for it, so very few extras are available.

From what I know so far, Likely openmoko really put a huge concern on building software stack rather than reliable hardware.
And every developer can free express their creativity without any limitaion or what we can call strict framework like many other vendor. I think in the spirit of open source, this is good. Fracture is open source nature, since everybody often has different point of view and different way of though.
As developer, it will be good if we can create our unique and differentiating value in this condition rather than just following “platform from vendor” as we did in closed phone.
But as a buyer, what we buy from openmoko is mostly a hardware. I think buyer whose mostly developer will be more satified if they have good and reliable hardware to develop software with. We can change software if it’s not reliable, but hardware?
So, hopefully openmoko team will put more effort to make strong and reliable hardware.

Now, I sympathise somewhat with Jay about all the confusion around the different software stacks, what people should be running, and so on. I’m an outsider who is considering getting a FreeRunner, but I’m concerned that I’ll need to spend huge amounts of time setting it up before I can even attempt to write any software for it. I imagine that some people are worried that they’ll end up having to buy another phone to “replace” the FreeRunner if there’s not enough movement towards having something that works and is usable within a certain timeframe.

My attempts at getting started in advance of the release of the hardware didn’t really amount to very much because there seems to be a load of different pages on the Wiki recommending all sorts of different things…

The MokoMakefile was convenient initially but apparently fragile and not that well documented, in my experience, but definitely a move in the right direction. The apparent fragility came about when trying to change certain files residing alongside the downloaded and built components, and quite some digging was necessary to find files in the filesystem layout that people were mentioning in other contexts. I also had to browse around to find out which qemu-related Makefile targets I needed and which other targets I should avoid.

The “manual” approach (one of them, anyway - there are probably several) worked well enough until trying to get qemu to talk to the host, which apparently required the ridiculous exercise of entering commands in the terminal application of the emulated device using the on-screen keyboard. I’m sure I could “remaster” the images to just switch such stuff on automatically if I had the tools, but this didn’t seem to be particularly easy.

(There are also flavours of host-based development which require the installation of huge numbers of packages. I can understand this, but I was starting to doubt the use of it as different preferred graphical toolkits started to shine in the continually moving spotlight.)

I don’t care about there being many software stacks - I’d probably want to go my own way to an extent, anyway - but there has to be a lot more coherent information about getting started. It doesn’t help that a lot of pages seem to be out-of-date or incomplete - things may be moving quickly, but if that prevents people from getting involved, priorities should arguably change so that what should be a routine part of people’s existing workflow can be written up for others to follow.

Anyway, I look forward to whatever comes out of the FSO developments, and hope that a straightforward path to getting involved emerges for those of us who like to concentrate on “user space” matters.

For me, its quite simple. No phones carrying the OpenMoko brand ought to be being shipped, period, without the latest official build from OM being put on it.

This means, yes, people can burn whatever image they want - that is the nature of things - but OM has one and only one image it puts on the phone, and it works to service the *hardware* being sold.

All Open Source projects must bow to one, common, undefeatable reality: hardware comes first. Nothing gets shared, unless its on a machine and running in the first place.

So, put the beef of your hardware manufacturing arrangements at the forefront of the effort to contain fracture. Make the machines that you ship, run the absolute latest build, and have your entire company running the same common weekly builds on products, too.

It starts with the guys making hardware, and right now thats you. Us developers, the ones who want to target software to the platforms and are not making a dime of profit from hardware sales, can bring a lot to the table to make your hardware worth the pennies. But there has to be support, and you should use your strengths: nobody running OpenMoko today, or writing apps to target it as a platform, can do anything until the hardware is out there, running a common reference platform (software and hardware) that we all can depend on.

@jay: Fracture is inevitable on an open system, where everyone can just start a new distribution at will. I agree though, it’s annoying for lots of people, but it’s not like we _planned_ to do that. It happened anyways, but with the new framework initative we hope to contain the damage and have a plan towards convergence.