Lessons learned from the failure of Ubuntu Touch

With the death of yet another open source/free software/Linux-based mobile platform, Ubuntu Touch, clearly it is time for us to sit down and have a frank discussion about what we in the free software world can reasonably accomplish in a mobile platform. 

One of the biggest issues—if not THE biggest issue—with Ubuntu Touch was that it simply had goals that were far too aggressive to reasonably achieve. It suffered from the all-too-common malady known in software development as feature creep. 

Ubuntu Touch was not simply a project to bring the existing Ubuntu system to mobile hardware and add functionality specific to that hardware (such as phone dialing, cell data, etc.). The project also contained: 

• An entirely new desktop environment (in Unity, which had already undergone one major rewrite in its short life)
• A brand-new packaging and container system (Snappy)
• A brand-new display server (Mir)
• A new application store
• A new SDK
• All new applications utilizing that SDK (everything from the terminal to the web browser was new) 

In short, just about everything.

This is a huge—nay, mammoth—undertaking. One that Canonical, even with the help of the existing Ubuntu community, simply did not have the resources to accomplish. It absolutely, without a doubt, was never going to succeed without an engineering executive coming in and taking the axe to a significant portion of those goals. 

[In my past life I was the vice president of engineering for a few game companies. Finding ways to ship overly ambitious software projects is what I did—before I decided to be snarky for a living.]

That said, I absolutely understand why features weren’t chopped. The people in charge had a vision—and they stuck to it. That, in a way, is admirable. Certainly very understandable. But it also had a very slim chance of actually hitting a high-quality “1.0” release with all of those features intact.

Make no mistake, while a few Ubuntu Touch-based devices certainly did ship, the system was not “finished” enough to keep people wanting to use it on a regular basis. For proof of this, look no further than the fact that many of the people who worked on this system didn’t use it on any regular basis.

Canonical is not the first company to fail with a Linux-based mobile software stack. Nokia had multiple tries at, it as well. We have plenty of examples to look at. The road-side is littered with the corpses of mobile Linux system roadkill that had far too ambitious plans to succeed considering the resources at their disposal.

How to create a Linux-based mobile system that succeeds

So, what do we do now? How do we build a Linux-based, free-software mobile system and actually—you know—ship it in a usable, viable state? 

To start with, we need to scale back the goals. Big time. 

For version 1.0, no app store. No new SDK. No re-writing every application. No new container formats. 

The goal, if it’s going to succeed, needs to be simple and clear: Take an existing Linux distribution (there are plenty of great options), and get the darn thing running on a singular, existing mobile device. 

• Pick a phone or a tablet—something commonly available in abundance that already runs Android (maybe a Samsung or Google device). Just one. Don’t get distracted by expanding to multiple devices. One. Focus.
• Get the Linux distribution up and running on that device.
• Work on support for the key hardware components: Wi-Fi, touchscreen, cellular data, cellular voice, IO.
• Find existing software to manage voice calls (there are several already), and modify them (if necessary) to get them technically working.
• Come up with a fairly straightforward system for installing/flashing the image onto the phone.
• Stop. Stop right there. Don’t do anything else. Declare it 1.0. 

At this point we, as a community, would have a phone (or tablet) that runs Linux.

Would it be “optimized for touch input”? Nope. 

Would it have cool “convergence” features? Nuh-uh.

But it would run. And it would work. And it would be a base that we could continue to work from—and that others could utilize to build new systems from that focus on different needs and workflows. 

You know what? It would, right there, be pretty awesome. Even if the project never went any further, we’d have a phone/tablet that we could easily run desktop software on. Maybe not ideal for everyone, but pretty spectacular just the same. I sure would use it. And I know a whole slew of others who have been jonesing for exactly the same thing. 

At that point we, as a community, could turn our attention to “2.0” and plan out which specific features are most critical to us. What are the pain points and how do we alleviate those pains? 

Whenever possible, those pain points should be solved by utilizing existing projects. Does this phone system need an app store? There are several “app store” like software projects out there. Choose one, and contribute patches to it to help with any unmet needs. Everyone wins. No starting from scratch here. 

The key here is to focus and not get distracted by shiny possible features. When that happens, the project as a whole almost always suffers—just like what we saw with Ubuntu Touch.

This isn’t a new problem. It’s existed as long as software has. I just wish we’d hurry up and learn it already so I could have a sweet phone/tablet that runs a regular Linux distribution reasonably well.