On Brainstorm
Recently the Technical Board [made a decision to sunset Brainstorm](https://wiki.ubuntu.com/TechnicalBoard/TeamReports/13/May), the site we have been using for some time to capture a list of what folks would like to see fixed and improved in Ubuntu. Although the site has been in operation for quite some time, it had fallen into something of a state of disrepair. Not only was it looking rather decrepit and old, but the ideas highlighted there were not curated and rendered into the Ubuntu development process. Some time ago the Technical Board took a work item to try to solve this problem by regularly curating the most popular items in brainstorm with a commentary around technical feasibility, but the members of the TB unfortunately didn’t have time to fulfill this. As such, brainstorm turned into a big list of random ideas, ranging from the sublime to the ridiculous, and largely ignored by the Ubuntu development process.
Now, some folks have mused on the decision to sunset brainstorm and wondered if this is somehow a reflection on our community and our openness to ideas. I don’t think this is the case. While it is always important to build an environment where ideas are openly discussed and debated, ideas are free and relatively simply to come by, and the real challenge is converting that awesome vision in your head into something we can see and touch and deliver to others; this is not quite so free and simple. While Brainstorm provided a great place to capture the ideas, and we had no shortage of them, the challenge was connecting brainstorm to the people who were happy and willing to perform the work, and it didn’t really serve this purpose very well.
There were two problems with this. Firstly, picking up other people’s popular ideas is not how Open Source traditionally works. Open Source is built on a philosophy of *scratching your own itch*, traditionally fueled by programmers fixing their annoyances and building features and applications they want. Now, this is not to say a non-programmer can’t rally the community around their idea and build momentum around an implementation, but doing this requires significantly more effort than a fire and forget submission into brainstorm. In other words, just because an idea is popular doesn’t necessarily mean it is interesting enough for a developer to want to implement it. Secondly, brainstorm started to garner an unrealistic social expectation that popular ideas would be automatically added to the TODO list of prominent Ubuntu developers, which was never the case.
Today at UDS we had a discussion about these deficiencies in brainstorm in traversing the chasm between idea and implementation and Randall Ross had an interesting idea. With brainstorm retired we should re-focus the brainstorm URL and provide some guidance for tips and tricks for how to take an idea and rally support around it to develop an implementation. As an example, over the years I have discovered that taking an idea and building a well formed spec with detailed UI mock-ups and architectural diagrams, a detailed blueprint, regular meetings, and burndown charts, all significantly help to taking ideas from fiction to fandom. Equipping our community with the skills and tools to bring these ideas to fruition is a better use of our time.
So, the TL;DR of all of this is…brainstorm was a great idea at the time, but it didn’t effectively drive the most popular ideas in our community to fruition and delivery in Ubuntu. We want to help provide guidance and best practice to help our community be more successful in converting their ideas into development plans and getting people interested in participating.
Unity 8 Running on Mir on a Galaxy Nexus
Hot on the heels of [my last post](https://archivedblog.jonobacon.com/2013/05/14/video-demo-of-unity-next-on-mir/) showing Unity 8 running on Mir on a Macbook Pro Retina, there were some folks who were curious about how well Unity and Mir work on a phone.
Well, thanks to your friend and mine, *Kevin Gunn*, you can see a video of Unity 8 on Mir running on a Galaxy Nexus (which is by no means a super-powerful smartphone these days):
*Can’t see the video? [See it here](https://youtu.be/_wKJvvR0oag)!*
Again, just to emphasize, this has not been through a round of performance optimizations, so you can expect additional performance improvements in the future, but I think this demonstrates that we are heading in the right direction. 🙂
If you are interested in participating in Mir development, [click here](https://unity.ubuntu.com/mir/) and if you are interested in participating in Unity 8, [click here](https://unity.ubuntu.com/getinvolved/development/unitynext/).
Video Demo of Unity 8 on Mir
Recently the [Mir](https://wiki.ubuntu.com/Mir) and [Unity Next](https://wiki.ubuntu.com/UnityNextSpec) teams got Unity 8 up and running on Mir. Now, this work is still very early in development and neither Mir nor Unity Next are finished yet, but I reached out to *Michael Zanetti*, who is on the team, and asked him to put together a short video demo to show the progress of this work. This demo shows the phone/tablet part of the Unity 8 codebase; the final desktop version will come later.
Here is is:
*Can’t see the video? [Click here](https://youtu.be/E9AzRxsnfTE)!*
As you can see, impressive progress is being made; this demo is running on a MacBook Pro Retina utilizing the full resolution of 2880×1800 pixels and using Intel HD 4400 graphics. The performance is already looking great, and the team haven’t done a deep dive into performance optimization yet.
If you are interested in participating in Mir development, [click here](https://unity.ubuntu.com/mir/) and if you are interested in participating in Unity 8, [click here](https://unity.ubuntu.com/getinvolved/development/unitynext/).
On Simplicity
As a pretty simple-minded person, I am a big fan of simplicity. The world is filled with too much complexity and too much detail. Many often feel the detail is necessary for particular outcomes or to solve particular problems. The lesson I have learned as I have gotten older though is that while the skill is in matching the level of detail to the mind of the observer, the real elegance is in delivering the same level of detail but in a way that feels simpler than expected to the observer. This results in *delightful* experiences.
Ross Gardler recently quoted Einstein who said “*everything should be made as simple as possible, but not simpler*”. This so beautifully summarizes my view of the world; life should be as simple as we can make it, but we should not compromise in our goals merely to make things simple. In other words, if we can boil our projects, processes, interfaces, and ideas down into simpler parts that still let us be productive, they become more enjoyable to engage with and thus more successful. Of course, making complex things simple is…complex. It is though, worthwhile, and for many (myself included), a fun challenge. I am sure I am not alone.
As we step into our [Ubuntu Developer Summit this week](https://archivedblog.jonobacon.com/2013/05/14/ubuntu-developer-summit-this-week/) I would like to encourage everyone to think about ways in which we can simplify all aspects of how create and deliver Ubuntu to others as a means to further the project and experience. This doesn’t just apply to user interface design though. How do we make our teams easier to navigate and participate in? How do we make it easier to create your first app, charm, bug fix, translation, document, mailing list post, question, answer, or otherwise? If we can make in-roads this week in simplicity, I am confident it will continue the bold stride Ubuntu is making into the future of devices and the cloud.
Ubuntu Developer Summit: This Week!
Just a quick note to remind everyone that our next [Ubuntu Developer Summit](https://uds.ubuntu.com/) is taking place this week on *Tuesday, Wednesday* and *Thursday*, and is open and available to everyone to participate. This is the event where we get together to discuss, debate, and plan the next three months of work.
The event takes place online from **2pm – 8pm UTC**. All sessions will run using a combination of Google+ streaming video hangouts and IRC, and you can see the full schedule on [summit.ubuntu.com](https://summit.ubuntu.com). Consequently, for those who cannot attend or might miss certain sessions, all sessions will be available pre-recorded from the session pages when the session is complete.
The event kicks off on Tuesday at 2pm with our keynote. We hope to see you there!
Sprinting In Oakland
Last week I traveled to Oakland to spend a week with my colleagues at Canonical for the Client Sprint. The aim of the sprint was to ensure the many different teams working on Ubuntu Touch at Canonical are in sync and working as efficiently as possible. This largely involves ensuring that the management teams are planning their work effectively, and that everyone is singing from the same hymn sheet.
To provide a little context, at Canonical we are working consistently to deliver a 1.0 Ubuntu Touch platform that is ready for October so it can then be delivered to customers for deployment on handsets in Q1/Q2 2014. This involves a wide variety of design, engineering, and service-delivery projects that currently involves 15 engineering teams, 5 design teams, and 5 services teams, totaling 150+ people. The aim of the sprint was to ensure these 150+ folks are aligned.
Now, *some* cynical people (who I suspect may need more hugs) think that the sprint is merely a Canonical-only UDS where we make a bunch of private decisions by explicitly excluding the community. Sorry, drama fans, this is not true. We spend our time discussing and managing Canonical staff and resources, talking about product review documents, staff assignments, hardware/IS requirements, reporting structures, stakeholder and customer requirements, and wading through endless spreadsheets to track all of this. We don’t do this at UDS as UDS is not a good event for this kind of team alignment work as we are all spread across multiple tracks (and most of our community would have little interest in these team discussions anyway), hence we have always had sprints to do this.
The sprint had a very definitive format. Every team has a defined set of responsibilities and projects and each team lead prepared a summary of their work, achievements, and blockers. As an example, one project my team has been working on is the skunkworks and core apps projects, and wider app development community growth. I gave a presentation that summarized this work and it provided an opportunity to update the wider team and identify areas in which we can work more efficiently (e.g. one outcome was opening up a more regular communication between myself and the head of the SDK team).
The good news is that things are running really well. The teams were well prepared, great progress is being made on the road to October, and any inter-team and inter-project issues that we did find were quickly and efficiently resolved. For such a large project with so many inter-connecting parts I was pleasantly surprised with just how coordinated everyone seems to be, and I want to thank the many engineering, design, and services managers and leads for their (often understated) leadership and planning. It is complex to coordinate so many moving parts when everyone works in the same office, let alone for such a widely distributed company working from home with so many different timezones.
Of course, there were many topics and projects discussed at the sprint, but there was one topic that resonated throughout the week: getting Ubuntu Touch into a form in which our community can start dog-fooding as soon as possible. In other words, right now you can [download the daily Ubuntu Touch images](https://wiki.ubuntu.com/Touch/Install), but you can’t really use it as your main phone; it still comes with a bunch of dummy data, some radio functions don’t work, and there is no way of saving data when you re-flash the device. In the next few months the teams agreed to expedite their work to make the Ubuntu Touch images ready so we can use them as our daily devices, thus opening more opportunities for testing, feedback, functionality edge cases, and more.
I have another sprint coming up this week (the Cloud sprint), but I have asked a number of people who joined the sprint to blog about their progress and updates. Keep your eyes peeled for more.
Life Changing Mistakes
I have a theory (I know, I am full of them). Like most of you, as I have gotten older I have also tried to improve as a person. I am not just talking about being better at what I do with my career and hobbies, but I want to be a *genuinely good person* across the board; a good husband, father, son, friend, colleague, and dude who you bump your shopping cart into when buying milk. My theory is that people fundamentally improve by (a) making mistakes and (b) understanding and learning from those mistakes to not only prevent making the mistake again, but to also uncover the cause and effect of why the mistake was made, thus improving your life.
Now, the (probably illogical) logical continuation of my theory is that to make improvements (a) you need to make more mistakes (which opens up the opportunity for learning), and (b) you need to develop CSI-like capabilities in assessing those mistakes and their root causes. Continuing the theme, if we can figure out ways to identify ways of triggering making more mistakes in a way that doesn’t get you arrested and we can identify ways to help us understand why we screw up the way we do, we should have a golden ticket for rocking our lives. Incidentally, this theory was boiled in my head while driving out to pick up Thai food on Saturday night, so this is no *Einstein’s Theory Of Relativity* in terms of completeness.
While I am rather thin on the ground in terms of what is the next logical part of my theory, I suspect that the way in which we invite more none-life-threatening mistakes is to break out of our molds and *take more risks*; if we never take chances, we lower the opportunity for risk and mistakes, but also lower the opportunity for learning. Likewise, for the latter *understanding our mistakes* part I suspect the key is not figuring out ways to prevent the mistake (“I got angry and shouted at my dog today so I will try to keep my cool”) but more about understanding the cause of the mistake (“I am stressed from work and bringing that stress home and taking it out on people and animals”). Much as I love dogs, the goal here is not to stop shouting at the dog but to repair the root cause. So I ask you, dear friends, does my theory wash with you, and if so, how can we increase the number of mistakes and the quality of our self-assessment of those mistakes?
Ubuntu 13.04 Released
Ubuntu 13.04, the Raring Ringtail, was [released today](https://www.ubuntu.com/). Go and download it for [Desktop](https://www.ubuntu.com/download/desktop), [Server](https://www.ubuntu.com/download/server), [Cloud](https://www.ubuntu.com/download/cloud), and for our Chinese friends, download [Ubuntu Kylin](https://www.ubuntu.com/download/desktop/zh-CN). You can find all the details of what is new in Ubuntu 13.04 on [www.ubuntu.com](https://www.ubuntu.com/).
Ubuntu 13.04 is a fantastic release, and I just want to offer thanks to the many people around the world in our community who helped make it happen. Folks such as developers, app/charm authors, designers, testers, triagers, translators, sys-admins, support providers, governors, docs writers, advocates, and more, all contributed their brick in the wall to delivering Ubuntu 13.04 across Desktop, Server, and Cloud, and continuing to bring freedom and elegance in technology to more people. But this is only part of the story, as behind the scenes, but in [full public view](https://archivedblog.jonobacon.com/2013/04/25/ubuntu-touch-progress/), we are continuing to evolve Ubuntu towards our convergence goals. This will be a common theme as we march forward to Ubuntu 13.10, the [Saucy Salamander](https://www.markshuttleworth.com/archives/1252).
I know many of us are tired after a hectic release schedule, so take some time to enjoy the release, get together with other Ubuntu friends, and celebrate Ubuntu 13.04! I will certainly be blowing the froth off a few cold ones tonight. 🙂
Ubuntu Touch Progress
Ubuntu is on an exciting journey, a journey of convergence. Our goal is to build a convergent Operating System that brings a uniformity of technology and experience across phones, tablets, desktops, and televisions, and smoothing the lines between those devices in terms of interoperability and access to content. It is a bold vision, but Ubuntu has a strong reputation both in terms of our heritage in the desktop, server, and cloud, and with our passionate and capable community. I just wanted to provide some updates on work that is going on in delivering this vision.
There has been significant work going on in building Ubuntu Touch (the overall name for this convergent platform). The team have marked October in their calendars as the goal to have most of the primary components in the Ubuntu Touch code-base complete so we can deliver a fully converged system in Ubuntu 14.04. The Unity team have been working to centralize the different form factors into Unity Next, which you can [play with now](https://unity.ubuntu.com/projects/unity/) (weekly updates on progress coming soon [here](https://lists.launchpad.net/ubuntu-phone/)), the [Mir](https://wiki.ubuntu.com/Mir) team are making good progress in getting Mir ready for deployment on handsets with a technical preview on the desktop in 13.10 (see the [weekly updates](https://lists.ubuntu.com/archives/mir-devel/)), and the [Ubuntu SDK](https://developer.ubuntu.com/get-started/gomobile/) team are working towards delivering a beta in the next few months. We have also been working with our community to build the 11 [core apps](https://wiki.ubuntu.com/Touch/CoreApps) (of which three them are already shipping in the [Ubuntu Touch daily development image](https://wiki.ubuntu.com/Touch/Install)), the Ubuntu Touch code-base has been [ported by our community](https://wiki.ubuntu.com/Touch/Porting) to and working on [40 handsets, with 25 handsets in progress, and across 19 different brands](https://wiki.ubuntu.com/Touch/Devices) (of which the 4800+ posts in the [XDA Ubuntu Touch forum](https://forum.xda-developers.com/forumdisplay.php?f=2068) has helped drive this work), and our app developer community has already grown to 1650 members [on Google+](https://plus.google.com/communities/111350780270925540549) with a huge variety of apps in development, many of which we are pulling together in [a PPA](https://launchpad.net/~ubuntu-touch-coreapps-drivers/+archive/collection). We have also been working to [automate the app submission process](https://wiki.ubuntu.com/AppDevUploadProcess) with a series of AppArmour sand-boxing improvements and tooling changes, we have an [eight part tutorial series](https://mhall119.com/2013/04/building-an-ubuntu-sdk-app-rev-1/) for writing an app from scratch, and have multiple training events and an Ubuntu App Showdown contest planned. On the business side we have seen tremendous interest from handset manufacturers and carriers, and the business team are in a marathon set of meetings across the world moving the discussions forward.
There is a lot to do, but we have an awesome team and community committed to the opportunity that lays before us. If we stay focused, stay on the ball, and take an organized and pro-active approach to problem solving, we could bring real technological change to the world with Ubuntu delivered via the very devices that form the fabric of most people’s lives. Let’s do it.
Three Point Blogging; An Experiment
I have an interesting idea I wanted to share that I am calling *Three Point Blogging*, and I am keen to get your input on this. Feel free to use that daintily prepared comment box, rummaging around at the bottom of this post, to share your feedback and ideas.
Blogging has lost some of its luster to me somewhat. I don’t enjoy nor have the time to read large swathes of text, and I don’t have the time to produce large swathes of text either. I suspect others feel this way too, hence the promulgation of `tl;dr` summarizing these wordy manifests. It is common theory too that most people take three points away from a presentation or article, and as such these textual overlords are somewhat overloading readers, who are often dipping into your blog in-between emails or meetings.
As such, I am inviting you folks to join me in a little experiment I am calling *Three Point Blogging*. Inspired by Twitter, and with a focus on content as opposed to word count, TPB blog entries should make *three core points*, spread across *three paragraphs*. This keeps entries short and sweet, focused on the core points, and more digestible. What’s more, this might encourage a little more playful word-smithing that is often lost when constructing the Berlin Wall of text. Now, this won’t apply to all posts, but I think it could apply to the majority of them, so I am giving it a shot. Anyone else interested in trying?