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

I’ve been too busy these days to compile a kernel module for android.

For those who want to compile a tun.ko kernel for Android (a commtiva z71 variant), here are the general steps. You need a linux environment to compile this module.

1. Download the kernel and supporting files for commtiva z71 devices here: https://opensource.motorola.com/sf/frs/do/viewRelease/projects.quenchxt/frs.xt5.xt502 and extract it to a directory of your choice.
2. Download the SDK and NDK for android: http://developer.android.com/sdk/ndk/index.html and http://developer.android.com/sdk/index.html
3. Copy config.gz from your phone and place it into your kernel source folder. To get it from your phone, type:
adb pull /proc/config.gz .
gunzip config.gz
mv config .config
4. Edit .config so as TUN module will be included into the kernel:
CONFIG_TUN=m
5. Run uname to get running kernel version of your phone:
uname -a
Linux localhost 2.6.32.9 #7 PREEMPT Tue Jan 4 16:51:45 CST 2011 arv61 GNU/Linux
6. If there was some extra characters in your kernel version, like 2.6.32.9-063c4d24, you’d have to edit the Makefile to use the corresponding version:
EXTRAVERSION = -063c4d24
7. Set your environment variables:
export ARCH=arm
export CROSS_COMPILE=arm-eabi-
export PATH=$PATH:~[path of your arm-eabi compile toolkit binary in android ndk]
8. cd to your kernel folder and make modules
cd ~[path of your kernel source]
make modules

Resulting tun.ko should be in the drivers/net folder of your kernel source.

Just beware, it is not for the fainthearted.

Further information:
http://android-dls.com/wiki/index.php?title=Build_a_custom_kernel
http://forum.androidcentral.com/htc-hero-rooting-roms-hacks/8072-how-build-your-own-kernel-package-source.html

Finally got myself a month ago an android phone, a cheapo commtiva z71 variant (cherry mobile nova)

Thoughts about it? Really cool, but android by itself is somewhat unpolished compared to iOS, or even Symbian for that matter.

Stay tuned for more.

Posted from android.

Hi there guys,

I noticed moblin’s repository of packages are quite limited. Yes, I know, moblin is gonna be meego in Q2 2010, but for the moment, I need my application fix.

Presenting a little moblin rpm repository until I meego comes, or whatever…

Two applications are in there, GFtp and Gnumeric. Those applications fitted my requirements for a useable netbook system.

To use the repository, just enter this as ostalks_moblin.repo in the yum.repos.d folder (updated to ibiblio):

[ostalks_moblin]
name=OStalks Moblin Repo $releasever – $basearch
baseurl=http://mirrors.ibiblio.org/pub/mirrors/ostalks/moblin/RPMS/
enabled=1
gpgcheck=0

I am also willing to compile applications for you guys, when I do get the time – I’m doing this on my own free time.

Have fun installing!

Well, it’s a short post.

Since I was around the area and was more or less free during the time, I attended a short meeting with a local Linux Users Group at the G2iX Techbar, IT Park, Cebu City, of which I am a member.

There was basically a short talk on Liferay, an Open Source Portal, Collaboration, Social Networking tool written in Java. After the talk was a discussion between the members about activities within the year.

Like I said, nothing much. People like Tom Wickline, head of the Bordeaux Group (a front-end to WINE), and writer to Wine-Reviews attended the meeting.

It also allowed me to show off my netbook running Moblin.

For those who don’t know who G2iX is, they’re a company headquartered in Manila, and specializes in Ruby on Rails development, Java, Dev Automation and Cloud Platform Deployment. They have also received awards like the Top Asian TechnoVisionary Awardee for 2006/2007 by ZDNet Asia, Top 20 Open Source Companies by Red Herring, among others.

There’s an interesting writeup by Gabriel Forster in his blog on how he implemented linux on the Christian School that he was teaching in.

He started: “Like many other people, our church and, more importantly, our Christian school, ran the Windows operating system on all computers.”

Basically the computers he had in the school amounted to 40 computers initially, with some 65 computers donated a year ago. The problem that came about was of licensing all those computers. Although they had 100 licenses of Windows 2000, the software was obsolete and unsupported already, and basically, all of their computers don’t have enough processing power in them to handle Windows 7.

In short, they replaced their Operating Systems with Ubuntu, and run their windows software (Rosetta Stone, an online language program for their students in learning new languages, and Firefox) in WINE.

All in all it’s a really pragmatic and practical way to avoid lock-ins and costs. If you want to see the details on how he did it, read about it more in his blog.

Apparently, Linus Torvalds, the creator of Linux, apparently caved in and bought a Nexus One last week, as he stated in his blog.

He initially bought a G1 (aside from other phones in the past), a Motorola phone running Linux, but admitted not using it because as he states “I generally hate phones – they are irritating and disturb you as you work or read or whatever – and a cellphone to me is just an opportunity to be irritated wherever you are. Which is not a good thing.”

After he heard that the Nexus One had pinch-and-zoom, he decided to take the leap and bought one and found it to be a gadget device (actually found it useful), with a secondary purpose of being a phone. In short, he loved it.

Some commenters asked him about the current status of the android kernel fiasco not being merged into the mainline kernel, in which he replied that the merge would most likely be a few years away. He cited the case of the SGI extreme scalability code as an example.

Here’s to seeing more linux developments on the mobile space!

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.

On my free time, I like testing out and playing games.  This is because, as a wine applications maintainer in the past, I had to cross test between distributions (mainly PCLinuxOS, and sometimes slackware at the time) and new updates to wine (particularly before it reached version 1.0).  Unfortunately, as work went more demanding, I had to leave all these behind.

** Sigh **

I was even surprised when my name came up on the ubuntu forums one time (archived already of course), regarding wine:

They always say I’m from Canada, even if that’s my Last Name (Distrowatch got my name wrong too)

Back to the topic, I’m getting offcourse…

Anyways, as I’m mainly in windows for testing games now, I’ve noticed an error in my Vista box lately after I updated my Batman: Arkham Asylum game through Windows Live:  800705b4.  This happens when I log into Windows Live, after which, the game would totally become unresponsive and has to be shut down from Task Manager.

After looking for a solution (this was a very cryptic error message, and many users don’t know what to do with it), I found a solution which works for me: open up the command prompt in administrator mode and type in the commands:

netsh winsock reset

and

netsh int ip reset

and reboot your pc.

This should fix your Windows Live problems.  As a side note, I find this one to be the best of all the superhero games I’ve seen so far (good story, albeit not for young audiences – stays mostly true to the Dark Knight stories in comics, depth and actually lets you feel you’re Batman – LOL) – and I’ve played quite a number of Batman games for the NES and SNES and Genesis, and a very nice game to see graphically – it puts the Unreal game engine to good use (which is quite impressive because this game is not a First Person Shooter, which I’m not fond of).

I’ve been thinking.  I think there’s a small window of opportunity here.

Mainly because since I’m researching on some things, and I’ve got a little spare time on my hands, why not make a Chromium Build?  I’ve got the newest Ubuntu version, some modest harddisk space allocated to it (20Gb), and I’m also curious on how this baby works on my BenQ joybook (I personally have 3 netbooks, BenQ Joybook, Neo Vivid 1100, and the Blue H1).

Should be interesting to see how this would work out, especially on the Blue H1 (which is essentially an One Mini A110 netbook), which is basically a 1st generation netbook (7″ screen), and a Via processor.

So what do you guys think?  It’s a go?  If I have made builds for the Chromium OS, I might become generous enough to upload this for you to tinker and test out.

By the way, if any of you guys have the Blue H1, you should find the A110 wiki interesting enough.  This was made by a Debian developer.  Warning: these are geeky stuff.

http://www.a110wiki.de/wiki/Main_Page