I happened to see a link to a study made by visionmobile (http://www.visionmobile.com), a market analysis and research company, made in July 2011 comparing different open source projects amongst a variety of predefined factors that constitute on how “open” a project is.

This is by far one of the most balanced studies I’ve seen comparing successful (and unsuccessful) well-known open source projects. Incidentally, visionmobile’s clients include HTC, Sony Ericsson, RIM, Microsoft, Intel, etc as part of it’s well known client lists.

Their quantification of “openness” between selected mobile open source projects (both successful and unsuccesful, single sponsor and multi sponsor) is called as the “Open Governance Index”.

The results were particularly interesting:

Among the 8 open source projects listed, Eclipse was the most “open” of all the projects, and Android was the last in the list. The research paper however noted that Android is also one of the most successful projects in the history of open source. It was contradictory enough that the paper called it the “Android Paradox”.

A number of interlinking factors were cited what made Android successful:
1. Google’s financial muscle and marketing.
2. Android’s “zero cost” subsidy by Google, since Google’s ultimate purpose is to drive more eyeballs to it’s ad inventory, which results to cheap handsets and low cost internet connectivity.
3. The adoption of the Open Source project by different manufacturers in order to compete against Apple’s iphone. The OEM industry generally poured billions of dollars into Android in order to compete with the Cupertino company’s product.

In retrospect, the research paper acknowledged that in the long term, platforms with the most open governance will be the most successful. Cited success stories are Eclipse, Linux, WebKit and Mozilla. Meego has the capability to become a successful project in the long term, in my opinion.

It also went to suggest that making a project open doesn’t necessary warrant a successful community builder. They stated that Software developers are human in nature and self-centered; and will only take interest in such a project if it provides value or addresses a common need – citing Linux, GTK or Webkit as an example (need for a vendor-neutral operating system, graphics software stack, browser engine). Symbian failed in this aspect; they failed to target developers (besides this, no proper development tools, complex contributions structure, etc).

What does this mean for Android and competing open source projects such as Meego?

Android was successful because aside from the factors stated above, when Android was released to the developers, the product was already a very advanced, and complete project (by and large due to Google’s famed engineering team):

However, there are some very good lessons for us to learn from how Google has managed the Android
open source project. First, Android was released as an open source project at a point in time where it
was already a very advanced, complete project. OEMs, operators and software developers could more
or less immediately use it to create derivative handsets and applications. Second, Google kickstarted a
developer buzz around the project with the $10 million Android Developers Challenge. Alongside
financial incentives, Google provided a very strong emotional message: that of opening application
development within a previously inaccessible mobile industry. Finally, Google’s speed of innovation
(five platform versions across 2010) outpaces any external innovation, and makes the ecosystem
entirely reliant on Google.

On the other hand, when Meego was announced, it was basically starting from scratch (okay, not exactly scratch, but the earliest versions of Meego were in the command line from my perspective) – try to imagine that they essentially went from a deb-based packaging solution (Maemo) to an rpm based one, and shifted from GTK/clutter to mainly Qt. This was one of the disadvantages I saw with the early development of Meego, and I have to say most likely hampered it’s early adoption (I do like the very open way the meetings are held though – I’ve been in one of the developer meetings in the past; but due to time zones it’s really difficult for me to attend it). It has gotten way better though; with the inclusion of non-Nokia/Intel people into the upper build team, the development process is getting to a point where I believe that this operating system will likely pick up pace and steam in the very near future (it has a bright future ahead in IVI systems in vehicles for example, and the upcoming N9 is positively received by many).

Quick short post.

Day One has arrived, and both intel and nokia have released sources and is opening up Meego for development. What is now available? Everything from the kernel to the middleware stack was released today.

The UI Experience Framework will be released later in May; this is when Meego actually goes for it’s first release.

Also, for downloads (images of the base system, terminal only) of Meego for N900, Intel Atom Netbooks and the Intel Atom Handset (Moorestown), they are now available at http://meego.com/downloads

Full details are here.

A few days ago, we heard of the big news that Intel and Nokia have started consolidating their Moblin and Maemo codebases and have come up with a new distribution named Meego.

From the blog, it states that they “are taking the best pieces from these two open source projects and are creating the MeeGo software platform. Both teams have worked for a long time to support the needs of the mobile user experience – and MeeGo will make this even better.”

As I knew that Maemo’s interface was more suited for the mobile phone area for Meego, I decided to look into Moblin itself and see how it would serve the role of addressing the netbook part of the new platform.

As we see it currently, the pre-built Moblin live image is a largely Fedora 10 based distribution. It can however be built from Fedora 12, and Ubuntu 9.10. It is interestingly enough that the resulting build with be rpm based, not deb based.

Installing the live image to harddisk on my Benq Joybook was simple enough – it was actually similar to the Fedora/RedHat installs that I am used to.

Booting up was a treat: compared to Ubuntu Netbook Remix, the interface was intuitive and smooth.

The Miser interface upon first boot shows practically a wonderful display of your tasks, favorite apps, documents opened and other stuff that you’ve just used.

Different tabs allows the user to navigate through different sections of Moblin – easily categorized into media, internet, status, applications, zones, people and pasteboard.

The way that Moblin is organized is, in my opinion, one of the best interfaces that I’ve seen in a linux distribution for netbooks. It simply is the best optimization of space for 8″ to 12″ screens.

There are drawbacks however.

For one thing, NTFS is not supported in moblin. And due to licensing issues, the MP3s and H264 video is not supported out of the box, as well as proprietary codecs.

Another thing is that Moblin’s repository is still rather small. Understandable though, because this distribution is meant for netbooks.

There are a number of hacks you can do though, one is you can use the Fedora 10 (and sometimes 11) repository to download other programs.

Another option is to compile the source rpms from the fedora repositories yourself. The trick is to enable the development tools of moblin by typing in the command:

sudo yum groupinstall “Development Tools”

If you’re a little lazy to compile gstreamer yourself, you can use a repository created by a Moblin user named Matthi. The repository, albeit small, includes some nice programs to install for Moblin, such as WINE, Blender, and the gstreamer plugins to make your Moblin distribution run codecs supported by ffmpeg. You can get instructions for his repository here.

What is the Moblin’s future as Meego? I would say, rather bright. Seeing how the interface really compliments the Intel Atom netbook specifications nicely, I believe that most of the GUI Moblin has implemented will be carried on in the netbook versions of Meego. A possible challenge will be on how to implement the user experience on the Qt toolkit (Meego will be based on it, rather on GTK that Moblin uses). Since Moblin uses the Mozilla codebase for it’s integrated browser, it is not farfetched to assume that Meego will implement the Webkit browser as it’s integrated browser for the Qt for it’s WM/Miser interface.

As Qt has integrated media, browsing, APIs, as well as a compositing engine compared to GTK (Gnome still uses Compiz as it’s compisiting engine), we would probably see a more integrated architecture internally, when Meego reaches it’s final stages of development into stable.

Nokia and Intel would benefit each other, because for one reason, Nokia has a netbook. Also, Nokia’s design principles are horrible and clunky (see the S60 interface on symbian as an example) and is also seeing pressure on their interface designs from competitors like Google and Apple. One thing that Nokia has, is that they’re great at hardware R&D (especially mobile), and it is my belief that Intel is also looking into the mobile sector, especially considering that OSes like chrome, and android run on ARM processors and are indirectly competitors with Intel on this space.

All in all, I would say that if both Intel and Nokia play their cards right, Meego will be a very good competitive platform for mobile and netbook apps in the future.

An interesting development happened during the release of the 2.6.33 linux kernel and generated some heated discussions on the lwn comments section. The android code in the linux kernel tree was deleted.

Why was it deleted? Greg Kroah-Hartman in his blog stated in a nutshell that:

In short, no one cared about the code, so it was removed. As I’ve stated before, code in the staging tree needs to be worked on to be merged to the main kernel tree, or it will be deleted.

There was a more serious problem though, as stated by Greg:

Now branches in the Linux kernel source tree are fine and they happen with every distro release. But this is much worse. Because Google doesn’t have their code merged into the mainline, these companies creating drivers and platform code are locked out from ever contributing it back to the kernel community. The kernel community has for years been telling these companies to get their code merged, so that they can take advantage of the security fixes, and handle the rapid API churn automatically. And these companies have listened, as is shown by the larger number of companies contributing to the kernel every release.

But now they are stuck. Companies with Android-specific platform and drivers can not contribute upstream, which causes these companies a much larger maintenance and development cycle.

On the lwn comments section, Greg further stated that a number of hardware companies approached the kernel development community for help due to this problem.

Apparently part of the problem is the problem is that Google created a new kernel core infrastructure which in order for it to be placed into the mainline kernel, numerous changes in kernel and userspace have to be done. Google has essentially created a fork of the kernel.

Cris DiBona stated:

To sum up: I think that Android is an unusual use of Linux that doesn’t match up with what is normally done, and I think that a fork isn’t unwarranted in these cases. I should point out we didn’t use glibc , either, or a ‘standard’ VM. We built android.

The aforementioned fork was mostly in the implemention of wakelocks, a process of bringing a system out of various low power states.

Google found the current implementation inefficient, and due to time constraints and pressure to produce a product, made their own API implementation.

The downside of this is that in order for linux drivers new and current ones to work on Android, one has to hook up to the new wakelock mechanism. This causes lots of distress in maintaining current userspace and kernelspace development.

It was generally agreed that the problems of power management was an issue that needed to be solved. However, a number disagreed on the way that Google handled the solution, including the kernel developers.

The reason mainline hasn’t accepted the wakelock infrastructure is that Google has still failed to demonstrate why it’s necessary. Almost identical benefits can be obtained using the kernel’s existing range timer functonality, which has the added bonus of removing the need for the strong userspace/kernel tying that Android requires right now.

Interestingly enough, Nokia handled the problem more maturely than Google. Whereareas, Google basically sent a large number of patches and left it hanging, one user noted:

I can’t remember significant interaction between Google Android developers and mainline kernel developers before early 2009. Contrast that to Nokia who have been *all over* the kernel upstreaming their OMAP patches for the N8xx and N900.

It was further noted that:

But they both have to solve the same problems (power management) and the fact that Nokia seems to get good battery life out of their devices appears at first glance to be a counterpoint to the necessity of wakelocks.

The discussion went on, without resolution. Time will tell if the Android code will be resubmitted back to the kernel, and the issues that hamper it being in the mainline kernel tree will be resolved and taken care of.

Here’s an interesting take into how to make an open source program. This should make a good case study on how to plan out and develop a program for distribution to the open source community.

Presenting Binary Clock – a GPLed java program which shows the time in binary. This is a simple java midlet made for nokia phones (from what I’ve heard, it runs on samsung phones too).

Anyways, here are the steps (illustrated):

1. Decide on what you want to do with the program.  You can then make a mock drawing on a piece of paper on how the program will respond like what is shown below:

2. You would also have to determine the target audience for your program.  In this case, we target mobile phones, mainly nokia phones.  To do this, you would have to have appropriate tools for the job ready.  Shown below are the tools used to make the program (testing and design).  Note that all these tools run in linux (although there are windows versions available, except for Fireworks which is a windows program); Fireworks was run in wine (yes, it does run, for those who are curious).

The final design from the Fireworks layout is below:

3. Since we have tested this in our emulators/sdk, it is now time to test it by ourselves with our available hardware.

Click to Watch!

Click to Watch!

Click to Watch!

4. When you feel that it is more or less ready to be distributed, you announce it to the world, and allow other people to modify and enhance our code.

Many thanks to Daniel Rindt of Visetics (http://www.visetics.com) for sharing the development workflow and the actual program with me.  To get the actual source code, please get it here.

SmartBro Prepaid is a mobile broadband solution which consists of a HSDPA capable modem and prepaid sim card.  There are two type of these modems available, I am going to talk about the second, newer modem (the smaller black usb dongle), as the first one already has howtos available in the internet.  For the curious – this dongle is called the Longcheer, and is based on the Alcatel OT-X020 modem chipset.

Although this writeup is based on setting it up on Ubuntu Intrepid, the following steps should be applicable to other distributions as well.  You may want to improve on these steps by placing these commands on a bash script, but what I’m giving you is the staightforward way of doing it.

Here are the steps:

Download the usb_modeswitch binaries and the latest usb_modeswitch.conf file here:

http://www.draisberghof.de/usb_modeswitch/#download

Extract the usb_modeswitch binary and place it in a place like /usr/sbin.  usb_modeswitch.conf goes to the /etc folder. Comment out the lines which has the headers Alcatel OT-X020.  You have to disable the other modem enabled on this config file, or usb_modeswitch won’t work.

Edit your wvdial.conf file (located in /etc) to look like this (As a bonus, I added a default dialer section for your nokia cellphone – I have a Nokia E61i to connect to the smart internet network):

[Dialer Defaults]
Init1 = ATZ
Init2 = ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
Init3 = AT+CGDCONT=1,"IP","internet"
Modem Type = USB Modem
ISDN = 0
Phone = *99#
Modem = /dev/ttyACM0
New PPPD = yes
Baud = 460800
Idle Seconds = 3000
Auto DNS = 1
Stupid Mode = 1
Compuserve = 0
Dial Command = ATDT
Ask Password = 0
FlowControl = NOFLOW

[Dialer smartbro]
Init1 = ATZ
#Init2 = ATQ0 V1 E1 S0=0 &C1 &D2 +FCLASS=0
Init2 = ATE1
#Init2 = ATE0V1&D2&C1S0=0
#Init3 = at_opsys=0
#Init2 = ATQ0 V1 E1 S0=0 &C1 &D2
Init3 = AT+CGDCONT=1,"IP","smartbro","",0,0
Modem Type = USB Modem
ISDN = 0
Phone = *99#
Modem = /dev/ttyUSB0
New PPPD = yes
Baud = 912600
Idle Seconds = 3000
Auto DNS = 1
Stupid Mode = 1
Compuserve = 0
Dial Command = ATD
Ask Password = 0
FlowControl = NOFLOW

Write down this code and save it as initmodem.sh and place it in /usr/sbin:

#!/bin/sh
modprobe usbserial vendor=0x1c9e product=0×6061 && usb_modeswitch
sleep 3

Plug in your SmartBro USB dongle and run:
# sudo /usr/sbin/initmodem

To connect to the internet, just type in:
# sudo wvdial smartbro

and to disconnect, just press CTRL+C, or kill the pppd process

I think this should work also with SmartBro 1500 as well.  Enjoy your smartbro connection!