In depth interview: Ubuntu Touch aims to learn from Android's mistakes
This article may contain personal views and opinion from the author.
With the right partnerships, if it's on your phone, I don't think [consumers] will care. They won't know. They may know it's Ubuntu, but they didn't know what Android was before they got an Android phone. We have to get to a point where it's not necessarily Linux per se, I think. On the desktop, it's always, ‘Oh, that? That's Linux.’ Well there's a lot of difference between Ubuntu and how it presents Linux and some other things. The fact that it's Linux, at some point it's not the important part for the consumer. It's important for us, because we know what gets us in terms of being able to build the system. But, I think that's branding. It's Ubuntu, it's not anything else.
The Genesis of Ubuntu Touch
Ubuntu began in 2004 and quickly generated interest within the Linux community. Developers gathered around the product, and more importantly the ethos of the distribution. At the time, Linux distros were the realm of the tech elite, and were not accessible to average users. Mark Shuttleworth gathered developers from the Debian community to change that. The goal was to create a Linux distrobution that was easy-to-use, easy to obtain, and held to a strict update schedule. The first two parts of that strategy were the real keys of course, because accessibility opened up a much wider user base for the OS.
Unity brought the two features that have become the core of Ubuntu Touch: the Unity launcher, with its larger touch-friendly icons, and the Dash, which is a highly pluggable Scopes system that blends the desktop with the web, and uses search to expose any and all content that you may want. The adoption of Unity did cause some dissidence in the user base, because some preferred the traditional desktop; but, despite that, Ubuntu has continued to grow, and is now one of the largest Linux distros around.Building Ubuntu Touch in the open
One of the biggest quagmires when talking about Android in relation to Ubuntu is in the idea of “openness”. Both platforms are “open source”, meaning that the source code is free for anyone to download, modify, and redistribute; but, we have to say that Ubuntu follows the open source philosophy much more closely, where Android has some exceptions.
Because it's distributed, we use tools that allow us to work in that distributed environment. We extensively take advantage of IRC (internet relay chat) and we're all working on a number of channels at the same time, even to the point where if you're in the same office talking to somebody in that office, you might do the conversation on IRC so that other people can participate.
No matter where you are, no matter if you're with people or not, you should be working in a public way. Either public within the company or public on the Freenet channels, so there's participation and people can read back and see what's going on. We use Google Hangouts a lot. We use an open-source VoIP client called Mumble, so we have a lot of Mumble rooms that we use. But, the idea is that it's just second nature for people to work together even though they're not co-located.
It's good and it's bad. It's also easy for people to keep working and go beyond a normal day. We try to counsel those working at home to still keep normal hours to some degree and try to stick with it, because if somebody in some time zone is just coming online and would love to talk to you, you have to be careful. You can't be on all the time, it leads to burnout.
No matter where you are, no matter if you're with people or not, you should be working in a public way. Either public within the company or public on the Freenet channels, so there's participation and people can read back and see what's going on. We use Google Hangouts a lot. We use an open-source VoIP client called Mumble, so we have a lot of Mumble rooms that we use. But, the idea is that it's just second nature for people to work together even though they're not co-located.
It's good and it's bad. It's also easy for people to keep working and go beyond a normal day. We try to counsel those working at home to still keep normal hours to some degree and try to stick with it, because if somebody in some time zone is just coming online and would love to talk to you, you have to be careful. You can't be on all the time, it leads to burnout.
Another reason for working in the open is because of all the contributions that Canonical receives from the Ubuntu Community. While Canonical does most of the work on the Unity interface and the big features of Ubuntu, the Community is critical to the process. The Ubuntu Community is made up of thousands of developers around the globe who contribute in a number of ways.
The bulk of development comes from Canonical, because we are the producers of the solution. The Community contributes in a lot of other ways, like all the translation activity comes from the Community. A lot of the quality assurance testing for various devices has always been that way for the desktop, they've acted as a huge testing resource. There's a lot of bug triage that goes on in the Community. So, even if they're not developing directly, which some do, they're contributing in a lot of other ways as well.
It isn’t all just informal Community input though, Canonical works hard to corral the Community efforts and focus the work into key areas as needed.
In some cases we've organized efforts, like in the Core Application development, the guys put a call out to get people to pick an application that they want to sign up and work for, and these individuals or teams formed to work on them. We just provided design input for the user experience, and helped run meetings and organize blueprints. So, there's that list of applications that are all being written by the community, which is great to see.
The Core Applications being developed by the community include: calendar, clock, calculator, weather, e-mail client, RSS reader, file manager, document viewer, terminal, Facebook, YouTube, and music apps. The list originally included a Twitter app, but Twitter’s new terms of service squashed that plan. The Community and the XDA Developer community have also been instrumental in helping to get Ubuntu Touch working on a number of Android devices.
Any open source product will always face the same issue of having its code forked into a completely separate product. Ubuntu was born as a fork of Debian. Kindle Fire was born as a fork of Android. As McGowan says, “That’s just the nature of open source.”
McGowan sees the answer to the issue as being similar to the tack taken by Google, saying:
The idea is, there's so much value added with it being Ubuntu and us being able to bring it all together. It's a hard job to do. So, people say, ‘Oh, it's all open and some company could just start up and do that.’ And, they have in the past. But, they can't do it to the degree and with the longevity, I think. You really have to have that process and engine behind it. It's hard to maintain a distribution year in and year out, and every six months update it. I think that people who grabbed open source have found it dead-ended a lot, because you have to have that discipline to keep it going, and most don't seem to have that. It's a risk that somebody can take it and repurpose it.
But, ultimately, as much noise as tech blogs tend to make about the spectre of forking, it all amounts to little more than fear mongering. For every Ubuntu and Kindle Fire that you find, there are dozens of failed forks, or forks that haven’t gained much more than a small amount of traction. For example, while Linux Mint was born as a fork of Ubuntu, it has really only attracted the faction of users that refused to accept the Unity interface as its main user base. And, for all of the talk about the potential of companies to fork Android, Amazon is the only company to do it successfully, since the Nook has been pulled back from fork status to getting access to the Google Play Store.
The far more difficult issue to tackle is that of carrier and manufacturer customization, but Canonical believes it has the solution to that issue as well. The answer here is two-fold: first, McGowan doesn’t believe that the overt customization of the UI is something that carriers really want; and, second, Ubuntu will be pushing forward the power of Scopes.
I'm not an expert, but I don't think the carriers really want to see the market segmented like that. I think they've had a hard time with Android, because of the fragmentation. So, hopefully we can have a slightly different model that's a little bit more unified and leverages what Ubuntu has been before for other systems, so it doesn't get fragmented like that. Ideally, an update to an Ubuntu Touch device can go to all of the devices. It may funnel through the carrier in some way, but it should be able to go to all of them and not have their version of Ubuntu so different that that's not possible.
Part of the solution may be in implementing a unified theme layer (something we have often lobbied for with Android), which would allow manufacturers to customize some of the UI, but would not allow for completely disrupting the feel of Ubuntu.
We do talk about what is that (theme) layer and we're still defining it. We're working on that now, so it is just: here are the 10 buttons you can dial differently, but it still has to have that same look and feel essentially, otherwise all that user experience work and usability testing gets lost. It still needs to look like Ubuntu, but have areas where they can customize it. One of the key areas is in the Lenses and the Dash, and the Scopes that can expose data from different sources. That can be very much driven by that specific product and that operator, so their content can surface there, but still come through in the same way that the user is used to consuming it on an Ubuntu device. We think that providing content in the Dash is a key area, and that's a lot of what the operators care about. What value are they adding there for their applications or their content feeds.
Scopes are the key feature that Canonical is betting on to give manufacturers the control they want while still offering users a consistent UI, and the idea is an extremely compelling one. For those who haven’t used Ubuntu, a main part of the Unity UI is the Dash, which is essentially a universal search box that can draw content from a number of sources, which are organized by data type tabs, called Lenses. Each Lens draws content from a dedicated engine, called a Scope.
The interesting part to Scopes is that the entire system is pluggable, meaning any service can hook into it, and thus almost any content can be surfaced. On a user level, this means that your Google Drive files can be surfaced just as if it were a local file, or other services like Spotify and even The Pirate Bay can be hooked in to make the barrier between you and the content you want as thin as possible.
We assume that some of the operators are going to want to have their own music store, so we have this nice mechanism that makes it very easy using the APIs provided to easily tie in a back-end service like that and pull it into the user experience. That's mainly what they care about and it's not something they can really do today. The design here is all about search and exposing that content directly in the main view there.
Surfacing content becomes extremely easy using Scopes; and, that is the key, because while the Dash and the Scopes tabs are essentially a universal search box in the desktop iteration of Unity, the Dash is your entire homescreen in Ubuntu Touch. So, the content being pulled in isn’t hidden away in an app, but prominently displayed as large, image-heavy pages front and center on your device.
While Scopes will go a long way to bringing various types of content to your Ubuntu device, you will obviously still want apps to handle that content. As we mentioned earlier, the Core apps for Ubuntu Touch are being developed by the Community, but Canonical is also working to attract developers to bring more apps to the platform.
McGowan says that the platform has already been building steam in that regard, and has been bringing in developers who don’t normally develop for Ubuntu. There have already been a number of apps from developers who had been working on Android and MeeGo, and best of all the apps are mostly written in Ubuntu’s native Qt code rather than HTML5.
Not surprisingly, a lot of the work in this regard is still in the future. Right now, Canonical’s focus is on getting the OS software ready, and work is still being done to sort out a lot of the details for app development, like the tools and documentation to help developers port apps. But, McGowan is clear that while Canonical wants the process to be easy, the apps need to become Ubuntu apps.
The tools are also on the way to really allow for the “write once, run everywhere” plan for apps. Because Ubuntu Touch is really the same OS as Ubuntu for desktops, the plan is to allow developers to write their apps once, and the app will be able to scale as needed between the different screens.
It's our goal that a developer with an Android app can easily bring it to Ubuntu, so we're working to define how we make that as easy as we can. It's probably some combination of us supporting a similar API set and a lot of it could be good documentation. It's not our intention to let an Android app run as is. It needs to become an Ubuntu app, but we want to make that process to be really easy.
That's the stated goal is to make it easy, but not automatic. An Android app in this user experience is not going to be right. There has to be at least enough effort by the developer to say, ‘There, now it looks like an Ubuntu app and it behaves along the model that you guys have specified.’ And, we want to make that work all they have to do.
The tools are also on the way to really allow for the “write once, run everywhere” plan for apps. Because Ubuntu Touch is really the same OS as Ubuntu for desktops, the plan is to allow developers to write their apps once, and the app will be able to scale as needed between the different screens.
Once you see the operating system can run on all the different platforms, if you're an application developer, you can write it once for all those targets. It's pretty compelling. That's the secret sauce I think. It's the thing that's unique about what we're doing versus what you know like Apple is doing. They're definitely a thought leader though.
So, an app can be written with the phone layout and screen size in mind, and scale up to a 7” tablet. But, when it gets to a larger screen, the developer will be able to choose whether to have the app continue with the phone layout and be displayed in the Side Stage on a 10” tablet, take on a larger layout, or give the user the choice between the two.
App permissions and approval process
There is also work to be done to sort out nagging problems like app permissions, and the Software Centre approval process. Again, he makes it clear that the details are not yet set, but he gives some indication as to where the conversation is going, including the possibility of having permissions surface on a case-by-case basis for certain functions.
If you want it to scale, you can't necessarily touch and test every application, so I expect we'll have ways so if there's a bad apple out there, there's a way to disable it, stop it from propagating. I think early on, we'll probably do a fair amount of oversight and validation, but over time as it scales up. My understanding is that we'd like to avoid something like [Apple's approval process]. It's understandable why they do it, you want to have that quality.
The design will support application isolation inherently, so we will have that as part of the system design. We've spent some time thinking about this whole permissions thing when you install an app that says, ‘Can I do these 92 bad things?’ And you say, ‘Sure,’ because why else are you installing it? That's not really useful for people. We're trying to do a nice compromise that makes sense. We'll provide some inherent isolation and then some reasonable user interface that says, ‘This is about to access your contacts information. Is that what you wanted?’ For certain restricted things, permissions will probably pop up as needed, and then you'll one time say, ‘Yeah, I'm okay with that.’
A lot of the work so far seems to be pointed at helping developers who want to bring Android apps over. McGowan is clear to say that Android apps will not be natively supported in Ubuntu Touch, but the links to Android are apparent because the early devices that support Ubuntu Touch are all Android hardware.Hardware
The kernel is a bit of a hybrid at this point. It's an Android kernel to some extent, but it's got all the Ubuntu configuration. In order to get it to work on the hardware, we don't have access to a lot of the source code for all the hardware drivers; so, we have to run the Android binaries to get these devices to work. The binaries that are built for Android are not compatible with binaries you would build for Ubuntu; so, we have to do this mapping layer to help the communication.
That creates this boundary right now. If we have access to all the source code, that goes away. We want to make it very easy for manufacturers to bring Ubuntu onto their devices, and if they've already got Android running, it's very easy to get Ubuntu on, because we'll use the same graphics driver, the same camera driver.
Unfortunately, we couldn’t coax any information about what carriers or manufacturers Canonical has been in talks with about bringing Ubuntu Touch to market. What we do know is that the aim is to have the phone software complete by the release of Ubuntu 13.10 in October, so that after manufacturers have time to put devices together, and carriers have time for the testing phase, the hope is still to have Ubuntu phones on the market at the beginning of 2014. Then, the tablet version is expected to be complete for the April 2014 release of Ubuntu 14.04, and devices should be out soon afterwards, since there will be no carrier delays for testing. Ubuntu 14.04 will also bring the code to a "single stack" that can run on any device from a phone all the way up to a TV.
Ubuntu Touch will scale to all handsets. The team expects the platform to start on mid-range phones (which were the high-end devices from late last year, like the Nexus 4), but it will scale to high-end smartphones, and low-end smartphones. Of course, the real secret sauce for the future of Ubuntu is in convergence. As we mentioned earlier, the tools are on the way to allow developers to write apps that scale to every screen size from phones all the way up to TVs, because that is the vision for the Ubuntu platform as a whole.
We're working towards this big idea of convergence. I really love the idea that my laptop and my phone become one thing. When that happens, I think that's tremendous. And, it extends so it just works on a TV as well and I can stream content to a big screen or something. Anything beyond the whole convergence set of possibilities, your guess is as good as mine. [Canonical founder] Mark [Shuttleworth] probably thinks about it though.
Conclusion
Ubuntu is an ancient African word meaning “humanity to others”, but it also means “I am what I am because of who we all are”. Both inside Canonical and out in the larger Ubuntu Community, the developers and engineers are finding a fairly unique work environment. Canonical has been able to pull together people from all over the globe, and truly seems to live up to the Ubuntu name.
Although he can’t confirm it, McGowan gets the feeling that Canonical has less turnover than most companies, because “the sense of community, combined with a lofty set of goals and some very interesting technology... brings together so many people from different countries and backgrounds”. We suspect that may also be why Ubuntu users have a certain loyalty to the platform.
And, for those who already know and love Ubuntu on desktops, the convergent dream of having the same OS on all of your devices is a powerful draw, not to mention the fact that Ubuntu Touch simply feels like Ubuntu in a way that many other mobile platforms don’t feel like their desktop counterpart. While they are becoming more similar, there is still a large disconnect between iOS and MacOS. Windows 8 and Windows Phone 8 have gone a long way to bringing together desktops, tablets, and phones, but Microsoft hasn't shown the true convergent future of Ubuntu. And, while Android and Chrome may be organizationally combined under Sundar Pichai, the two platforms are nowhere near being functionally linked.
The daily images of Ubuntu Touch are just about ready to be “usable” daily drivers, but there is still a long way to go before October and the software will be considered feature complete. There is a lot of work to be done in attracting the ecosystem of manufacturers, carriers, and app developers, not to mention the daunting task for the marketing team in making the platform visible in a market dominated by Android and iOS. But, the vision of Ubuntu Touch is one that has always fascinated us, and we will continue to follow the work of Canonical and the Ubuntu Community.
Ubuntu is an ancient African word meaning “humanity to others”, but it also means “I am what I am because of who we all are”. Both inside Canonical and out in the larger Ubuntu Community, the developers and engineers are finding a fairly unique work environment. Canonical has been able to pull together people from all over the globe, and truly seems to live up to the Ubuntu name.
And, for those who already know and love Ubuntu on desktops, the convergent dream of having the same OS on all of your devices is a powerful draw, not to mention the fact that Ubuntu Touch simply feels like Ubuntu in a way that many other mobile platforms don’t feel like their desktop counterpart. While they are becoming more similar, there is still a large disconnect between iOS and MacOS. Windows 8 and Windows Phone 8 have gone a long way to bringing together desktops, tablets, and phones, but Microsoft hasn't shown the true convergent future of Ubuntu. And, while Android and Chrome may be organizationally combined under Sundar Pichai, the two platforms are nowhere near being functionally linked.
FCC OKs Cingular\'s purchase of AT&T Wireless
Things that are NOT allowed: