Comparing Maemo & Ubuntu
May 3, 2010 5:49 pm community, freesoftware, maemoWhile I’ve occasionally been critical of Ubuntu as a project, it is a distribution with very open processes, for the most part.
I’d like to compare the experience of a casual Ubuntu user, an engaged Ubuntu user, an Ubuntu developer, and an upstream application developer to the equivalent MeeGo or Maemo experiences.
The casual Ubuntu user gets regular stable updates on a predictable schedule, with long-term supported versions less frequently, but still on a predictable schedule. Stability, releases, this user doesn’t want to know what happens behind the scene, he wants to get software when it’s “done”.
The engaged Ubuntu user can activate an unstable development distribution, and see the work going in as it’s being done! He updates daily, gets the latest and greatest, and occasionally stuff doesn’t work, but he doesn’t mind. The information how to do this isn’t on page one of ubuntu.com, but it’s there, and engaged users tell each other about it.
The Ubuntu developer can participate in the creation of the process by packaging his favourite software, pushing it through a public (although occasionally real-time & in-person) process for inclusion in the holy grail – default installation, or presence on the install CD. He can take care of packaging, shepherd the package through QA, ensure that problems get reported upstream and in general ensure that his package is a good Ubuntu citizen. Even if he doesn’t get the package in the default install, which is quite tough, he can follow public community processes to have it available in the Universe, available to every single Ubuntu user through a simple search of available applications.
The upstream developer doesn’t really care that much about Ubuntu. He develops his application, sees bug reports coming in from users & developers & downstream packagers. He adds features, and concentrates on what he loves best – coding the best app he can.
Now, compare that experience to Maemo, to see how we compare:
For the casual user, not much changes. He gets the software on a device, when it’s “done” (and the definition of done is considerably different for a phone than a PC distribution).
For the engaged user, who wants to follow the bleeding edge, the story gets murkier. In the Maemo world, hardware and software releases have been closely related. Without a Beagleboard or a prototype N900, Fremantle wouldn’t have been very useful. But even operating system updates like the upcoming long awaited PR1.2 are not packaged and prepared in public, so even existing N900 owners can’t follow along with the cutting edge.
There is a promise that the first release of MeeGo will work well on the N900, so potentially there is an opportunity for the engaged MeeGo user to follow along with unstable development – on condition that, like the engaged Ubuntu developer, they’re prepared for the occasional bricking & reflash. But the UX software for MeeGo is being prepared for release – we are told that some closed components are being opened, some others are not ready for release yet. So it is not (yet) possible for an engaged MeeGo or Maemo user to follow along & install a base alpha or beta distribution and update or reflash regularly.
For packagers who would like to propose their software for inclusion in the default repository, or even on the default install, of MeeGo or Maemo, there is not (yet) a clear path to get involved in the process. I could start working on a Maemo port of QuteCom, Shotwell or some other software, but if I did, there’s no way for me to get that software included by default. The current Extras/Extras-testing policy of Maemo has been heavily criticised by some developers – so it might not even be easy for me to make my software available to a large number of Maemo issues.
The upstream developer experience doesn’t change that much. Upstream developers still shouldn’t care about what packagers are doing, and should be concentrating on making the best apps possible. But for major parts of the MeeGo platform, namely the UX projects, the upstream and downstream will be hard to separate. As an upstream developer, I care about being able to follow commits, read Changelogs, do code review, develop and propose features, fix bugs and so on, in the open. For unrelated upstream projects, things also change – due to form factor and UX guidelines, the developer really needs to do a tailor-made UI for MeeGo or Maemo, requiring effort not being spent on features. And because you’re doing embedded development, your development environment becomes that much more complicated, with emulators and cross compilers and SDKs.
The embedded world is a special place, a lot of things change from desktop development, and some of those changes come with the territory. You’re going to have to work with a device emulator, and anything that requires a SIM card, the GPS, camera, accelerometer or any other hardware features, well, you’re going to have to wait for a device to make 100% sure those work. But we can certainly bear in mind the Ubuntu user experience(s) when we are designing the MeeGo community, and ensure that their experience is just as open.
That means open code, and more importantly open processes. It means an engaged user being able to use software that isn’t ready, a packager being able to propose software for inclusion in the OS and ensure its availability to all users of the distribution by following a well defined process, and a developer having a great experience helping to develop great applications.
May 3rd, 2010 at 7:46 pm
I hope meego doesn’t make the same mistakes maemo has done. The leaked pr1.2 firmware is a disaster IMHO also, having to wait for Nokia to relase a new firmware to fix bugs in the opensource part of the stack is also quite unfortunate.
May 3rd, 2010 at 9:58 pm
Hi Dave,
As an upstream developer I’m actually rather frustrated with Ubuntu. Far from offering users stablity, Ubuntu ships outdated software contained bugs fixed in stable point releases because they bring themselves to upgrade to a new point release within 2 months of a new cycle.
As a user and developer I’m much happier with Fedora which ships the best software upstream developers have at any point in time.
May 4th, 2010 at 8:44 am
@Martin
I would like to disagree with you there. Sure some of the softwares shipped with ubuntu are buggy and some of this buggs fixed before the next release. But for those who seek stability then Ubuntu has what is called the LTS release which is supported for 4 years and which is ideal for business and average users. Like every single OS in the world (as we are experiencing with maemo) The best time to upgrade to use it is a couple of months after release when most of the initial release bug would have been ironed out. hence even for my work place we usually wait like 4 months after the release of an LTS before upgrading.
Fedora is a bleeding edge distro and its not as stable as you try to make it sound. Fedora ships the latest and greatest libraries, applications and tools which are not necessarily stable. even updates with fedora can be quite tricky has noted in this proposal http://fedoraproject.org/wiki/Stable_Release_Updates_Proposal
In the end we all use what works for us
May 4th, 2010 at 12:16 pm
@bigbrovar: What Martin is pointing out is that Ubuntu does not consider new upstream packages for inclusion after a certain cut-off point, preferring to concentrate on its own integration & bug-fixing work. This means that if, for example, a major Abiword bug gets fixed after this cut-off point, Ubuntu users will potentially not benefit from it for several weeks or months.
Given how many batch updates I get on my Ubuntu laptop, I know that it is definitely possible to see point releases go out during a stable release cycle, but perhaps Martin’s experiences are different for a give package (could it be a packager issue?).
Cheers,
Dave.
May 4th, 2010 at 1:21 pm
I can’t agree with maemo end user experience. N900 looks more like a development platform than a finished product. It lacks too many features we expect from a hi-end smartphone. So end user must be prepared to go without USSD, MMS, different ringtones for contacts, and so on.
And I’m one of that rare animals who like Extras QA procedure. It’s far from perfect, but it’s good enough for maemo community resources.
And don’t forget that Extras repository is on every N900 out of the box. So it’s like the “main” repository in Ubuntu, because the user don’t have to select an item in HAM to use it.
Sorry for ugly English.
May 4th, 2010 at 1:44 pm
Hi Nick,
You’re right, the Extras repository is on by default. But it takes a lot of effort to get an update or a new application in there. For packagers, it is something of a trial by fire, and not as straightforward as the Ubuntu policy.
May 4th, 2010 at 2:49 pm
I’ve passed this way with my “Time Workshop” utility. It’s yet another (the sixth) stopwatch/countdown timer so you can figure out that it wasn’t very popular in extras-testing.:)
But there is a big problem with updates: I don’t know what I’m supposed to do if I’ll find a critical security bug and want to fix it ASAP. How should I bypass that 10-days testing quarantine?
May 4th, 2010 at 8:33 pm
[…] Comparing Maemo & Ubuntu While I’ve occasionally been critical of Ubuntu as a project, it is a distribution with very open processes, for the most part. […]
May 4th, 2010 at 11:21 pm
Ubuntu issue is backporting. Ok upstream releases a new version to fix secuirty problem. To keep version the same in Ubuntu some Ubuntu maintainer works makes a different patch and applies it to an old verison of lib.
Now as a poor application developer I am screwed. Reason if that patch breaks some function in the old version I depend on my program fails. Problem is version numbers look about right to what I tested with.
I have been long side a few other distribution mainatiners. Yes full distributions with as many packages as Ubuntu.
Most of the time moving forward version of a binary compadible library breaks nothing. The funny part is the items that break will break in all cases I have seen with backported patches. Yet simpler to spot if packaging includes information on what libs application was built against. Ie this was built against X version lib we now have Y Lets chroot and try with X hmm now it works. Problem solved.
Version locking is bad causing backporting of patches bad. Increases defective package rate.
Binary compatibility locking is good so programs work. Ie Version and Binary compatibility are too different things. Lot of stupid people think they are related 1 to 1.
May 6th, 2010 at 8:58 am
I would very much like if Maemo took the Ubuntu way of realeses. Much better.
For the Fedora fanboys… Ubuntu are more stable and in much cases easier than Fedora. I choose to use a PPA repo for my most preffered apps and get the latests and best without compromising the whole system.
AND PLEASE MAKE A PORT OF SHOTWELL!! 😉
May 6th, 2010 at 7:39 pm
don’t forgot that nokia releases more devices then the PC market.
and that they discontinue their products or break them for no reason (e.g. you can use mail for exchange with GMail if you use nokia’s MfE <2.9 but upgrade to 3.0 and the only new feature is that GMail won't work)