Ubuntu Core Desktop on the Nexus 7: Getting Involved

Ubuntu Core Desktop on the Nexus 7: Getting Involved

A little while ago I [talked about our goals to get the core Ubuntu Desktop running on the Nexus 7](https://archivedblog.jonobacon.com/2012/10/26/ubuntu-core-on-the-nexus-7/). Again, just to be clear: the goal here is to get the lower level foundations of the Ubuntu Desktop running efficiently on the Nexus. This work is focused on optimizing the kernel, X, networking, memory consumption etc of the core of Ubuntu and *not* focused on making Unity into a tablet user interface. You can’t build a great house without a solid foundation.

Like many of you, I installed Ubuntu on my Nexus 7 that arrived yesterday and the [installation instructions were a breeze](https://wiki.ubuntu.com/Nexus7/Installation):


You can always revert back to Android if you need to, so come on, give Ubuntu a whirl!

Currently Ubuntu on the Nexus 7 boots and Unity runs, albeit a little slowly, but with the core touch gestures working. So far the desktop, networking, suspend/resume, and sound works, but things such as a the camera, accelerometer and other bits are still not working. The goal is to optimize the stack to run more efficiently and ensure all the hardware functions work in due time.

One of the questions many people have been asking is if these performance improvements will benefit Ubuntu in general. While some improvements will be specific to the Nexus 7, most should benefit Ubuntu in a more general sense in terms of improving performance, lowing memory consumption etc. So yes, if you contribute to helping this work, your contributions will likely benefit Ubuntu on desktop machines, servers, cloud, and elsewhere too. Also, given the nature of how our flavors are built on the foundations of Ubuntu, many of these improvements should also help our flavors too. If you are not picking up the subtlety of my prose, *this is all valuable work for everyone*. 🙂

## Growing Community Participation

As part of this work we are really keen to work with our wider Ubuntu community and over the last few weeks I have been working with *Daniel Holbach* on my team as well as *Alex Chiang* on the Nexus team to identify the different ways in which community members can help. This is on-going work, but I wanted to sync you up on what is going on.

We want to provide a means in which everyone can help with these efforts, but there are two core types of contribution here:

1. **Development** – helping to optimize software, package bug-fixing, and otherwise contribute to the core distribution running on the Nexus 7.
2. **Testing** – testing different parts of the Nexus 7, running benchmarks to to see how the development work is progressing, and reporting bugs.

Now, some of you may be interested in helping with other areas such as advocacy, translations, documentation etc. We will get to those parts soon, but right now we want to get developers and testers up and running and then we can widen the net of potential contributions further after those folks are up and running. We are definitely keen to ensure that everyone can help though.

Now, in terms of the former (Development) we are working to put the following resources in place:

* Instructions for how to contribute as a developer, and areas of focus each week.
* Details for how to learn the skills to participate.
* A common list of bugs that we can point developers too.

We already have [some documentation availabe](https://wiki.ubuntu.com/Nexus7/Developers#Things_to_get_involved_with) where you can find out how to work with patched packages and test the PPA. The other documentation needs above will be added soon.

## Testing

For latter much of this work will focus around benchmarking. We want to identify parts of the system that are slow and inefficient and optimize those parts to work better. Part of this optimization work will involve creating new builds of these different components and inviting community members to test them, and run benchmarking tests to see what efficiency benefits we get.

To help with this we are working on the following:

* Instructions for how to test the Nexus 7 and what kind of bug reports we need.
* Getting benchmarking suites that we can use to track the effiency of different parts of the stack.
* Provide a good workflow that benchmarking results and bugs can flow into the development pipeline so our development community can fix these issues.

A lot of this work is starting to land, and if you want to help with bugs be sure to read [Matt’s blog entry about how to get involved](https://www.mattfischer.com/blog/?p=307).

If you are interested in helping with measuring and debugging, see [this documentation](https://wiki.ubuntu.com/Nexus7/Developers#Measuring_and_debugging) where you can find out how to [measure power consumption](https://wiki.ubuntu.com/Nexus7/MeasuringPowerConsumption), [measure memory usage](https://wiki.ubuntu.com/Nexus7/MeasuringMemoryUsage), and [simulate realistic usage when benchmarking a browser](https://wiki.ubuntu.com/Nexus7/BrowsingSimulation).

More documentation and resources will be available soon.

## Meeting and Support

To get the ball rolling we have scheduled a weekly meeting every Friday at 4pm UTC in `#ubuntu-meeting`. The goal of the meeting is to discuss progress being made, identify areas of focus, and provide a means for our community to get involved in this work. The meeting will be chaired by *Alex Chiang*.

To get in touch with the development team, be sure to join `#ubuntu-arm` and `#ubuntu-devel` on Freenode, and you can also ask questions on Ask Ubuntu [right here](https://askubuntu.com/questions/ask?tags=mobile). If you have been using Ubuntu on the Nexus 7, also be sure to [go and answer any questions you can](https://askubuntu.com/questions/tagged/mobile); that is a great contribution!

## Moving Forward

We are still very much at the beginning of this journey but we are determined to be successful in making Ubuntu rock on the Nexus 7. For us to do a great job here we will need lots of help from our community to get involved, and we want to make this as simple as possible, so please do share your feedback about how we can make this easier. A great place to share this feedback is in the weekly meeting too; we can then note down suggestions and work on solutions.

Ubuntu has made tremendous progress in recent years on the desktop and in the cloud, and we think we have a real shot at making a real change on devices too. Together we can bring Free Software to more people across the desktop, cloud, servers, and devices, and every contribution from our community edges us another step further. Please be sure to ask any questions that I can help with. Thanks!


VPSs, Ubuntu, and Juju

VPSs, Ubuntu, and Juju

Recently I had a bit of a nightmarish experience that we might be able to transition into an opportunity. Let me share it with you.

For many years now I have been running my personal website at [archivedblog.jonobacon.com](https://archivedblog.jonobacon.com/). The site is nothing special, just my blog and some other content, and I have been running it on a dedicated host alongside some other sites (including [Stuart Langridge’s homepage](https://kryogenix.org/days/)). Stuart and I shared the server and paid nearly $1400 a year for the hosting.

Recently we discussed shutting the server down and migrating our sites to shared hosting providers; we are tired of having to take care of a server and we wanted to cut costs. Stuart and I both run WordPress for all of our sites; I used to write and maintain my own CMS many moons ago, but moved to WordPress for convenience. We both wanted to end up in a position where we didn’t have to maintain the OS and WordPress and have to deal with upgrades, backups and other related sysadmin work. As such I started the process of exploring hosted WordPress providers. This is when the pain started.


Computing can be fraught with pain and danger.

At first I thought…[wordpress.com](https://wordpress.com/). Perfect! Taking a quick look at their site I could pay for my domain to point there and I could also pay to not have ads. There were two downsides though: I could not use my current theme (which is a premium [WooThemes](https://www.woothemes.com/) theme), and I couldn’t use my own plugins. Unfortunately I need two key plugins: [phpmarkdown](https://michelf.ca/projects/php-markdown/) and [Disqus comments](https://wordpress.org/extend/plugins/disqus-comment-system/) and I may need additional plugins in the future. I would have happily compromised on the theme, but it seems that getting comments back out of Disqus and into WordPress is a pain, and converting years of mixed HTML and markdown blog posts was going to be a pain, as well as not having flexibility in the future. I looked at other WordPress providers but they all had similar problems.

Knowing I didn’t want a dedicated server due to the expense (and this would be just me paying this time, Stuart had already moved his site), I started looking into alternatives.

Now many of you will be screaming “*use the cloud, Jono!*”, but my worry here is that while my normal traffic is generally pretty consistent and predictable, every so often my site gets hammered into the ground with traffic, and I didn’t want to get stuck with a big bill. I wanted to instead just pay a monthly fee and know it wouldn’t extend beyond that in cost.

## Getting All Virtual

As such it seemed my best option was going to be a *Virtual Private Server* (VPS). These are dedicated machines that share multiple virtual machines and you pay for a set of resources. If you want more resources, you simply upgrade your plan. This gives you the flexibility of a dedicated host but cheaper and without the risk of ballooning cloud costs.


Pictured: ballooning costs.

There are basically two types of VPS: *Managed* and *Semi-Managed*. The *Managed* plans include full technical support, backups, managed OS upgrades etc. *Semi-Managed* means you are basically on your own with a root shell, but many semi-managed plans also include a control panel that you can use to manage different parts of the server.

*Managed* was a little more expensive than I wanted to pay, but the idea of *Semi-Managed* was interesting, particularly if I could use a control panel to take care of the things on the server I didn’t want to care about (such as backups). So I started looking into different providers.

This is where I hit a roadblock. Ubuntu was a non-negotiable requirement for me in choosing a server, but irrespective of whether I went managed or semi-managed it seemed like these were my options with pretty much most of the VPS providers:

1. cPanel Control Panel running on CentOS.
2. Plesk Control Panel running on Debian.
3. Ubuntu with no Control Panel.

From what I read, cPanel is considered the better panel, so I was optimally hoping for cPanel on Ubuntu, but it seemed I would need to compromise on both the panel (Plesk) and the OS (Debian). Now, don’t get me wrong, I *love* Debian, and most things in Ubuntu are the same in Debian, but not quite everything is and I would probably get caught up in those details. Also, I love the LTS support for Ubuntu.

With my Ubuntu requirement it seemed like the last option in the list above was my only real step forward, and this basically meant I was going to have to take care of the server manually. Now, I know some of you folks love doing that, but I don’t. It is not that I don’t have the knowledge to administer a server, and Ubuntu definitely makes it easier, it is just that I don’t really want to spend my time fiddling with Apache and MySQL; I just want it to work. Despite this I sucked it up, registered with a provider and a little while later I was all set up and running.

## What I Want

One of the reasons I love Ubuntu is that it makes my computing experience easier. Ubuntu on my desktop lets me work quicker and more efficiently, and Ubuntu on the server lets me install what I need quickly and efficiently.

On the server though I still need to keep up to date with how to configure, manage, and maintain these components in my service. I care more about simply deploying a service, and ideally I would have an expert in the tools I use to make the specific configuration and performance decisions, but I am not an expert. As such using Ubuntu on the server in a VPS without a Control Panel relies on me learning the skills to run my service well.

This is why I want [Juju](https://juju.ubuntu.com/) to be able to control my VPS.

Juju has been focused on providing a fantastic deployment service for the cloud. It lets you set up and configure a comprehensive deployment in just a few commands, and a core design goal with Juju charms is to infuse the knowledge of deployment experts into the charms so that Juju users benefit from this knowledge and expertise when they deploy their service.


Knowledge flowing from a deployment expert into a charm.

Unfortunately I can’t currently use Juju with my VPS; it is currently focused on the cloud. I think however that Juju could benefit VPS hosting needs in a number of ways:

* **Simplifying Deployment** – ideally I want to subscribe to a hosting plan, get my machine provisioned and then simply deploy WordPress with just a few Juju commands. This would save me having to poke around configuration files, setting up databases etc.
* **Scale Out** – for those times when my site gets hammered by traffic I want to be able to scale up my resources to cater for the traffic. I would love Juju to be able to speak to my hosting provider’s API to be able to provision either more memory, CPUs or additional machines to cater to these needs.
* **Transitioning To The Cloud** – if I could use Juju right now with my VPS it would make it simple to re-target my service to the cloud. With the sheer scale and focus of the cloud I will no doubt move to cloud hosting in the future, and Juju could simply that transition significantly.
* **Lower The Bar** – if we provided support for VPS providers this would provide a means in which many more people would be able to play with, try, and experiment with Juju. This would in itself continue to grow Juju adoption.
* **Juju GUI** – while I currently lack a panel, Juju GUI would be my panel. This would ease management of my service tremendously.
* **Great For Providers** – the margins in hosting are low due to the competitiveness of the industry, and from what I could see in my research lots of people want to use Ubuntu as their server OS, but the lack of a panel makes it a complicating issue in some cases. Offering Juju and Juju GUI would make Ubuntu an even more attractive option for hosting providers and also likely reduce support costs.

After I went though this process I reached out to the Juju team to see what would be involved in bridging this gap. I talked with *Mark Ramm* who is managing Juju, who was resonant to the idea, but was also conscious that Canonical engineers are busy working on other parts of Juju. Fortunately there has been [some work going on](https://lists.ubuntu.com/archives/juju/2012-September/001883.html) that could support this goal, and Mark suspected that it would not be a tremendous amount of work to build this support into Juju. I thought that this could be a fun project that our community could work on.

I have asked Jorge to coordinate with Mark to put together a list of what would need to be done. Jorge is going to follow up with a blog post and some next steps. Stay tuned if you are interested in contributing to this. Thanks!

**UPDATE**: See [this page](https://juju.ubuntu.com/the-juju-unprovider/) for what needs to be done and [this discussion](https://lists.ubuntu.com/archives/juju/2012-November/001985.html) to get involved (you can join the `juju` mailing list [here](https://lists.ubuntu.com/mailman/listinfo/juju)).

Ubuntu Advocacy Development Kit

Ubuntu Advocacy Development Kit

As I [mentioned last week](https://archivedblog.jonobacon.com/2012/11/01/loco-teams-communication-and-community/), our [LoCo Teams](https://loco.ubuntu.com/) are a core part of the Ubuntu community. They provide wonderful contributions in spreading the word about Ubuntu, introducing users in how to get started with the desktop/server, and providing a fantastic support safety net for new users. I want to help to better support the work of LoCo Teams in the 13.04 cycle.

One idea I was discussing with my team the other day was the idea of an Advocacy Development Kit (ADK). Let me explain…

In the software world, if you want to write applications for a particular platform you typically use an official *Software Development Kit* (SDK). This is a downloadable collection of tools that provides everything you need to get started writing software for that platform.

I would like to explore the notion of creating a similar downloadable kit but focused on the needs of LoCo Teams to perform advocacy. This kit would be used to organize and run outreach projects, represent Ubuntu at events, and spread the word further and further afield about Ubuntu and Free Software.

## How It Would Work

Imagine this scenario. You go to [https://loco.ubuntu.com](https://loco.ubuntu.com) and you download the ADK as a `.zip` file. When you unzip it there is the following content included:

* **Promotional Materials** – we include a set of posters, signs, banner ads, and other materials that most teams will use in their advocacy. Teams can then print out this content quickly and easily.
* **Assets** – we include the assets teams need to create their own materials. This would include our logos, color palettes, pictograms, and other content.
* **Organizational Materials** – if teams want to organize outreach campaigns, organizational efforts and other projects, we can include things such as organizational spreadsheets that ease this work, lists of things you should bring to staff a booth etc.
* **Documentation** – we would include some written guides for performing different types of advocacy such as organizing jams, booths, giving out CDs etc.

At the top level of the ADK would be a `README.html` file that provides a summary of the content included so it is easy to find what you need.

I think providing an ADK would fulfill a number of benefits:

* This would be an active project that would benefit all LoCo Teams. It would provide a single concise place to find everything you need to perform great advocacy and get great results.
* It would be a fun project to participate in and open to everyone to contribute. This would be a Launchpad project with branches, translations, milestones etc. I think having a project such as this that our wider LoCo Teams community can rally around would be useful and and fun.
* The ADK would not serve to provide a library of promotional materials ([SpreadUbuntu](https://spreadubuntu.org/) already does a great job there), but instead pick a small number of the very best materials to include and point people to *SpreadUbuntu* if they want more choice. This is similar to how we build Ubuntu; the default install ships the best text editor, web browser etc, but then you can access other options in the *Ubuntu Software Center*. We would likewise deliver the best content in the ADK and point people to SpreadUbuntu for more choice.
* This project could be useful for other flavors and projects too. Imagine that a Kubuntu LoCo Team wants to perform some specific Kubuntu advocacy; they could take the ADK, switch out the Ubuntu assets with Kubuntu ones, but keep most of the content the same. This could also be useful to other projects outside of the Ubuntu world to take the Ubuntu ADK and patch it with their own content.
* We could write the documentation and guides in RestructuredText (this is how the [Ubuntu Packaging Guide](https://developer.ubuntu.com/packaging/html/) works) which is simple to write, and this would make it easier to (a) generate additional output formats (e.g. HTML and PDFs) as well as (b) support translations so that teams can have documentation available in their own language. Translating these docs for different languages would be a tremendous contribution.
* We would give the project a release cadence and release a new version every six months; this would match Ubuntu releases and provide fresh content for all of our teams.

## Feedback Welcome!

So, I wanted to share the idea with you folks and encourage you to share your ideas in the comments. Specifically:

* Do you like the idea?
* What kind of content do you think should go in the ADK?
* Would you be interested in helping?

I have asked *Daniel Holbach* to put together a first cut of the ADK and put it in a Launchpad project and then we can use some of the ideas discussed here (please let us know if you are volunteering to help too) and then we can start working on a shared branch to build a first iteration of the ADK.

Thanks for reading and thanks in advance for your comments!

Unite

Unite

A little break from the norm…

*Can’t see the video? [See it here](https://www.youtube.com/watch?v=_sPVPxvvcm4)*

This is a song I wrote a while back, that is broken into three “acts” if you will. The song is composed from multiple layered acoustic music pieces as well as some bass guitar and strings (that’s right, folks, no metal here). The song is a little long, but it is intended to tell a story as opposed to being radio-friendly.

When I wrote *Unite* I knew it needed some kind of spoken words on top of the music to flesh out the meaning of the song and provide atmosphere. I spent hours scouring the net trying to find the right speech that told the right story and met the tenor of the music as it progresses through the acts. I wanted the song to speak to the nature of the world today.

After an extensive search I discovered that the greatest, most inspirational speech was given by [Charlie Chaplin](https://en.wikipedia.org/wiki/Charlie_Chaplin) of all people; a comedic actor famous for his *silent* movie work. Until I saw this speech I had never actually heard Charlie Chaplin speak; I had only ever seen him waddling around with a cane doing slapstick.

His speech in this song is from [The Great Dictator](https://en.wikipedia.org/wiki/The_Great_Dictator) released in October 1940 and distributed by United Artists. It is a beautiful, perfectly written and powerfully acted speech and when I first saw it it made the hairs on the back of my neck stand on end. My inclusion of this speech is not only intended to tell the story of the song, but it is a tribute to a truly wonderful comedy and drama actor and his contributions to cinema and culture in the form of his acting, production, composition, and writing.

I hope you enjoy it.

Ubuntu Core Desktop on the Nexus 7: Getting Involved

Ubuntu Desktop Core on 32GB Nexus 7 Tablets

As many of you will know, there is a lot of work going on to get the [core Ubuntu Desktop running on the Nexus 7 tablet](https://archivedblog.jonobacon.com/2012/10/26/ubuntu-core-on-the-nexus-7/).

Thus far we have focused on the 8GB and 16GB tablets, but now the [32GB Nexus 7](https://play.google.com/store/devices/details?id=nexus_7_32gb_hspa) can be used too. This tablet is available for around $299 if you don’t have one.

We want to encourage as many of you to test Ubuntu on the Nexus 7, report bugs, and get involved in making Ubuntu rock on it. To get involved, simply [follow the installation instructions](https://wiki.ubuntu.com/Nexus7) (don’t worry, you can roll back to Android if you need to) and be sure to [ask for help](https://askubuntu.com/questions/ask?tags=mobile) if needed.

If you find bugs, be sure to report them with `ubuntu-bug`, [here’s how](https://help.ubuntu.com/community/ReportingBugs).

Thanks for helping!

Preparing UDS Proceedings

Preparing UDS Proceedings

With so much going on at UDS it can be difficult to get a crisp summary of the key decisions, plans, and goals for the next release. Even if you are attending in person, you only get to see a small sliver of everything that is going on, so a broad set of summaries is useful for those both at UDS and those who could not attend.

I have created [this wiki page](https://wiki.ubuntu.com/UDS-R/Summaries) where we can document these summaries, decisions, and conclusions. Please go and contribute to this page – if we can divide and conquer in getting most of the content landed this week we can then tidy it up next week and release it.

Thanks!

VPSs, Ubuntu, and Juju

LoCo Teams, Communication, and Community

It has been interesting listening into the [UDS sessions](https://summit.ubuntu.com/uds-r/) remotely (find out how to join remotely [here](https://uds.ubuntu.com/community/remote-participation/)) this week. While I wish I could join more sessions (unfortunately the timezone difference is pretty brutal) there have been a number of key topics and themes discussed this week, of which a few in particular have caught my attention in the *Community* track.

Two topics in particular appear to be *[LoCo Teams](https://loco.ubuntu.com/)* and *Communication*. In a nutshell some of the feedback from UDS is that our LoCo Teams provide tremendously valuable advocacy for the Ubuntu project and but we could do with helping and harnessing these teams more. In terms of communication there is a desire for better communication regarding how announcements are made and how widely news is disseminated across the project. There was also feedback about improving community involvement in Canonical projects but I will dedicate another blog entry to that.

I am in full agreement with both of these points of feedback, and I agree these are valuable areas for us to focus on in 13.04 and I am going to commit my team to help drive improvements in both of these areas.

Next week when UDS is finished I will be spending a few days syncing up with my team to get more details about the discussions that I could not be part of due to the timezone, and then I am keen for us to put together a plan with our community. These plans will naturally take into account the discussions and suggestions put forth at UDS and we will coordinate with many of the participants in the sessions around the plans for 13.04.

I would also like to put together a small community team that my team can have a regular call with to check in and ensure this work is on track, make any adjustments and improvements as we execute it, and be able to bounce ideas and discussion points off. We may break this into two teams: one to coordinate around the LoCo work, and one to coordinate around the communications work.

I do have a few thoughts about these two areas I wanted to share below as points for further discussion. If you are at UDS please do discuss these topics there and feel free to share your thoughts in the comments below.

## LoCo Teams


The Myanmar Loco Team.

There is no doubt that our [LoCo Teams](https://loco.ubuntu.com/) are a tremendous part of our community. There is also no doubt that we can help Loco Teams more to help and support their teams in being successful.

From the perspective of the Canonical Community Team I feel a bit guilty about this. In previous cycles we have spent more time on LoCo Teams, but the last few cycles we have not had as much time to devote to helping teams be successful (the last few cycles have been hectic to say the least). As some of you will know, I used to have weekly calls with some LoCo Leaders and I want to get that back on track in 13.04.

In my mind there are three strands of LoCo Team work that we can focus on in 13.04:

* **Leadership** – as with previous cycles I think there is a great opportunity to continue to support, inspire, and motivate great leadership in our LoCo Teams. There is no doubt that a team with a great leader (if not a formal leader, someone who inspires work and contributions and coordinates projects) typically ends up being a happier and more motivated team. As such, for us to increase the number of happy, motivated teams, helping our LoCo Teams to develop great inspirational leaders is a great area to focus our efforts.
* **Participation** – one area in which I think we have done a pretty poor job in recent cycles in involving our LoCo Teams in activities surrounding the next release. As an example, on my team Nick Skaggs is going to be growing the number of manual testers, Daniel Holbach will be working with Nick to grow the number of Automated testers, and Michael is going to be growing the number of people participating in the skunkworks project. These are great areas in which we can reach out to our LoCo Teams for active participation, to share skills, and take part in wider campaigns. All to often we have focused on the specific communities in that work (e.g. the testing community in the QA work) and we should widen this to involve our wider LoCo Team community. As an example, I can see Nick reaching out to and support LoCo Teams to participate his his regular cadence testiing every two weeks.
* **Sharing Stories** – when a community reads awesome stories of LoCo Teams doing great work, it inspires and encourages great work too. A few cycles back we implemented changes to [loco.ubuntu.com](https://loco.ubuntu.com/) to highlight many of these stories and I think it would be wonderful for us to continue this work and make the site a hub of exciting storytelling and discussion. I would like to get this back on track.

Do you think these are valuable areas of focus? What other areas do you think we can help make LoCo Teams be more successful?

## Communication

Communication is definitely an area in which we can drive some improvements. Within the context of the discussions at UDS, it seems the primary concern here is to improve (a) how new features, policies and information is communicated to the wider community and (b) improve how that information is disseminated so as many people as possible see it and people don’t miss it because they didn’t read a particular mailing list, blog, Twitter feed or otherwise.

In terms of (a) you can break these announcements down into (1) announcements from the community (e.g. governance voting, CoC changes etc) and (2) announcements from Canonical (e.g. new features that might be landing, changes in policies etc).

For (2) this is something I am passionate about improving in the 13.04 cycle. I have already reached out to Mark Shuttleworth and the Product Strategy / Online Services leads about improving how these big new features and changes are messaged outwards. As part of these improvements I am maintaining an internal spreadsheet with when these features and policy changes are going to be ready. This will give my team more time to prepare for this work, help us to provide other community teams with a heads up (e.g. the Community Council and the News Team), be able to plan resources and documentation, and be able to plan the discussions and feedback loop better. I am confident that this will improve significantly in the 13.04 cycle. Mark and the Product Strategy/Online Services leads are all on board to participate in this work.

For (b) we started getting into this discussion in the community roundtable yesterday and I think that this deserves a longer discussion. Ideally we want to find a way in which we can utilize existing communication channels but be more efficient in how we message out to our wider community. As an example, the Fridge serves a useful purpose as a community orientated blog, but we need to ensure that the information and announcements get posted there more often (something that we can improve in my team). We also have other potential resources such as mailing lists and Twitter/Google+ feeds and we need to find the best way of merging these different resources together into a more scalable strategy for how we message outwards.

I am keen to hear of any further discussions on this topic at UDS and for us to continue the discussion next week and put in a place a plan. Comments and feedback are welcome!

Ubuntu Advocacy Development Kit

Join Us At the Ubuntu Developer Summit This Week!

This week the [Ubuntu Developer Summit](https://uds.ubuntu.com/) is taking place in Copenhagen from **Monday – Thursday**. This is the event where we plan the features and goals for the next release of Ubuntu, Ubuntu 13.04 Raring Ringtail.

Unfortunately I won’t be there in person this week in person as my wife, Erica, and I are expecting a stork to fly into our house and deliver a baby (at least that’s how I understand how it works), so I am at home in California on stork duty. I am not going to deny that although being here is absolutely the right thing to do, I am pretty bummed that I can’t be there in Copenhagen with our community.

Some of you may not be able to attend in person too, but fortunately you can still participate in every session at UDS by joining in remotely.

## How do I Remotely Participate?

You can find all the details of how to remotely participate [right here](https://uds.ubuntu.com/community/remote-participation/), but in a nutshell you can [view the schedule here](https://summit.ubuntu.com/uds-r/) (obviously all times are in local European time) to see the list of sessions and which rooms they are in and then [hear the session audio feed](https://icecast.ubuntu.com:8000/status.xsl) from the appropriate room. You can communicate with the room by connecting to the Freenode IRC network and then joining one of the following rooms that corrospond to the session you are in:

* `#ubuntu-uds-b3-m1`
* `#ubuntu-uds-b3-m10`
* `#ubuntu-uds-b3-m2`
* `#ubuntu-uds-b3-m3`
* `#ubuntu-uds-b3-m4`
* `#ubuntu-uds-b3-m5`
* `#ubuntu-uds-b3-m6`
* `#ubuntu-uds-b3-m7`
* `#ubuntu-uds-b3-m8`
* `#ubuntu-uds-b4-m5`
* `#ubuntu-uds-b4-m6`
* `#ubuntu-uds-b4-m7`

If you connect to a room and can’t hear people loudly enough, don’t hesitate in asking the room to speak up or certain speakers to sit closer to the microphone.

## How do I Watch the Plenaries?

Every day there are a series of plenaries; these are short presentations that are presented to the full UDS audience. Apart from the keynote plenary on Monday at 9pm, the main plenaries take place every day at 2pm and then a final set of track summaries is presented in the last hour of UDS on Thursday at 5pm.

You can watch the plenaries every day by viewing the [live video feed](https://video.ubuntu.com/live/).

This is the schedule of plenaries:

### Monday

* 9.00am – Jono Bacon – Introduction to UDS
* 9.10am – Mark Shuttleworth – Keynote

* 2.00pm – Ivo Weevers – Design and Community
* 2.15pm – Drew Bliss – Valve
* 2.30pm – David Planella – Ubuntu and App Developers
* 2.45pm – Nick Skaggs – Growing The Ubuntu QA Community

### Tuesday

* 2.00pm – Chris Kenyon – VP of Sales and Business Development
* 2.30pm – HP

### Wednesday

* 2.00pm – Flavors Roundtable
* 2.30pm – Evan Dandrea and Matthew Paul Thomas – Reliability and Ubuntu

### Thursday

* 2.00pm – Lightning talks (an hour of short, topical talks covering a range of areas).
* 5.00pm – Track Summaries – each of the track leads will summarize the key decisions and findings from their tracks. This provides a great summary of the topics discussed at UDS throughout the week.

I hope you all have a wonderful and productive week at UDS, and I hope many of you can join in remotely too!

Preparing UDS Proceedings

Ubuntu Core On The Nexus 7

A core goal for Ubuntu 13.04 is to get Ubuntu running on a Nexus 7 tablet. To be clear, this is not going to be a tablet Unity interface running on the 8/16GB Nexus 7, but instead will focus on getting the current Ubuntu Desktop running on the Nexus so that we can ensure pieces such as the kernel, power management and other related areas are working effectively on a tablet device.

Topics such as battery life, memory footprint, and support for sensors are all areas in which needs and expectations vary widely between a PC and a mobile devices. The 13.04 cycle will very much be focused on this exploration and learning and this is why we want to focus our efforts on getting the existing Ubuntu Desktop running on the Nexus 7. This will mean that some user-facing parts of the experience won’t make a lot of sense on the tablet, but we want to get the foundations optimized before we focus on these higher level challenges.

Naturally we want our community to be involved throughout this exploration and I want to talk more about how you can get involved both as a tester and as a developer.

## As a Tester

To help with testing you will need an 8/16GB [Nexus 7](https://www.google.com/nexus/#/7) tablet and be willing to replace the Android Operating System with Ubuntu (as such, please be sure to back up any valuable data on your tablet).

You can follow instructions of how to install Ubuntu on your device by reading the instructions at [https://wiki.ubuntu.com/Nexus7](https://wiki.ubuntu.com/Nexus7).

If you have any questions about the installation and setup, please [post on Ask Ubuntu](https://askubuntu.com/questions/ask?tags=mobile); we will use the [mobile](https://askubuntu.com/questions/tagged/mobile) tag to track these questions. The Mobile development team will be regularly monitoring the questions, and we would like you folks to help answer the [list of questions](https://askubuntu.com/questions/tagged/mobile) too if you have the answers.

When you find bugs, please use `ubuntu-bug` to file the bug (more details about using `ubuntu-bug` can be found [here](https://help.ubuntu.com/community/ReportingBugs)). Please also tag the bug with `mobile` so we can find them more easily.

You can also get in touch with our wider testing community in #ubuntu-testing on the Freenode IRC network.

## As a Developer

If you are interested in contributing to making Ubuntu work flawlessly and optimizing the Ubuntu Desktop core for the Nexus 7, we would love to have you participate in this work.

You can find details of many of the areas that we would like to focus on over at [Victor’s blog](https://victorpalau.net/2012/10/25/what-does-it-take-to-run-ubuntu-desktop-on-mobile-devices/); this provides some great food for thought for performance and functionality goals.

Much of this work will be discussed at the upcoming [Ubuntu Developer Summit](https://uds.ubuntu.com/) taking place in Copenhagen from **29th Oct – 1st Nov 2012**.

If you are unable to participate in person you can join the sessions remotely. For instructions of how to participate remote, see [this page](https://uds.ubuntu.com/community/remote-participation/) for instructions. You are also encouraged to join #ubuntu-arm on Freenode to discuss this work.

The following sessions are scheduled. Please note times may change, so be sure to click the link below to ensure the date/time is up to date. You can also find the appropriate blueprints linked from the links below too:

### Monday – 29th Oct 2012

* 10:00 – 10:45 in B3 – M8 : [Setting your Ubuntu Mobile Dev environment](https://summit.ubuntu.com/uds-r/meeting/21392/setting-your-ubuntu-mobile-dev-environment/)
* 11:00 – 11:55 in B3 – M9 : [How do I know my code is not consuming too much power?](https://summit.ubuntu.com/uds-r/meeting/21396/how-do-i-know-my-code-is-not-consuming-too-much-power/)
* 12:00 – 13:00 in B3 – M8 : [How do you debug your environment in a target?](https://summit.ubuntu.com/uds-r/meeting/21393/how-do-you-debug-your-environment-in-a-target/)
* 15:00 – 16:00 in B3 – M4 : [Boot & Resume time measurement and improvements for ARM devices](https://summit.ubuntu.com/uds-r/meeting/21321/foundations-r-arm-boot-resume-speedup/)
* 16:15 – 17:00 in B3 – M8 : [How do I know my code is not consuming too much memory?](https://summit.ubuntu.com/uds-r/meeting/21394/how-do-i-know-my-code-is-not-consuming-too-much-memory/)
* 17:05 – 18:00 in B3 – M6 : [Reduce footprint on arm devices](https://summit.ubuntu.com/uds-r/meeting/21290/desktop-r-arm-reduce-footprint/)

### Tuesday – 30th Oct

* 09:00 – 09:55 in B3 – M6 : [Trying to reduce session footprint for better battery life and RAM usage](https://summit.ubuntu.com/uds-r/meeting/21289/desktop-r-reduced-power-ram/)
* 09:00 – 09:55 in B3 – M5 : [Improve the cross-compilation story in Ubuntu](https://summit.ubuntu.com/uds-r/meeting/21268/foundations-r-improve-cross-compilation/)
* 17:05 – 18:00 in B3 – M5 : [Discussion of methods for measuring and testing power consumption in arm devices](https://summit.ubuntu.com/uds-r/meeting/21147/hardware-r-arm-power-measurement/)

### Wednesday – 31st Oct

* 10:00 – 10:45 in B3 – M9 : [How do I write a test and get the test into the test suite?](https://summit.ubuntu.com/uds-r/meeting/21397/how-do-i-write-a-test-and-get-the-test-into-the-test-suite/)
* 11:00 – 11:55 in B3 – M9 : [What does it take to run Ubuntu Desktop on mobile devices?](https://summit.ubuntu.com/uds-r/meeting/21407/desktop-r-targets-for-embedded/)
* 11:00 – 11:55 in B3 – M5 : [Startup Disk Creator support for flashing fastboot images](https://summit.ubuntu.com/uds-r/meeting/21322/foundations-r-arm-usb-creator-fastboot-support/)
* 12:00 – 13:00 in B3 – M9 : [How do I report a bug for the Mobile OS, what is the process?](https://summit.ubuntu.com/uds-r/meeting/21398/how-do-i-report-a-bug-for-the-mobile-os-what-is-the-process/)

### Thursday – 1st Nov

* 10:00 – 10:45 in B3 – M5 : [Support generating Android ROMs on cdimage.u.c](https://summit.ubuntu.com/uds-r/meeting/21280/foundations-r-android-image-builds/)
* 16:15 – 17:00 in B3 – M8 : [Compiling Ubuntu binaries for mobile](https://summit.ubuntu.com/uds-r/meeting/21395/compiling-ubuntu-binaries-for-mobile/)

Thanks for reading!

The Genesis Of Free Software Projects

The Genesis Of Free Software Projects

Regarding [Mark’s post about participating in private projects](https://www.markshuttleworth.com/archives/1207), I just wanted to weigh in on a few things.

First, let’s take a look at how Ubuntu is developed today.

Like other Linux distributions, we take a range of upstream components and assemble them together into an integrated system. Throughout this integration work our community actively participates in a range of different areas – development, testing, bug-fixing, translations, documentation, and more.

Now, over the years Canonical has invested extensively in building components to help grow and improve the Ubuntu experience. Examples of this include Unity, Juju, Launchpad, Bazaar, Ubuntu One, and various other projects. The majority of these projects are fully open and anyone can participate in them.

In *some* of these projects Canonical prefer to keep some new features secret until they are released. Now, I know some of you have a fundamental ethical objection to this, and a subset of those folks deem this so reprehensible that it warrants an abandonment of Ubuntu.


Just don’t abandon Ubuntu gangnam style.

As part of my job, I have had consistent feedback from a small number of unhappy people about these private projects, and I have communicated these concerns to Canonical as appropriate. Now, like many of you, I always like to opt for an *open by default* approach to Free Software, but in some cases there is reasonable justification for keeping things secret until they are ready. Examples of such reasons can include keeping the development and design focused to get a first version together, having a big splash with the feature (and thus waiting for the splash), or if the feature is being created for a partner product and then later added to the main platform if appropriate.

Now, I can hear some of you balking at these reasons, and you have every right to disagree. I have personally always seen it this way though: when sometime decides to create Free Software either as an individual or as a company, they have the right to create the first iteration of that feature *however they choose*. Their investment of time, money, or both in building Free Software earns them a right to put together a first cut that meets their needs…this is the very nature of *scratching an itch*.


Taking the analogy too far…choose your own tree, or bear.

## Contributing Earns Decisions

Let me give you an example. Some time ago I built the first cut of [Ubuntu Accomplishments](https://wiki.ubuntu.com/Accomplishments). I spent a few weeks hacking like mad getting the vision into a runnable form that I could then share with others. Now, as soon as I mentioned it publicly, some people were very complimentary of the work, and some decided to question every decision I made. Why did you use Ubuntu One as the back-end? Why are you not supporting Mozilla Open Badges? Why are you using GTK3 for the client? Why don’t accomplishments allow you to do XYZ?

The way I saw it was pretty simple. I took a few weeks out of my life to build Free Software that I would share with others, and as far as I was concerned, I had earned the right to make my own decisions about the project and how it would be constructed.

Importantly, this right does not extend to the full history of the project; the social expectations change when you release a project and want people to participate. Continuing my *Ubuntu Accomplishments* example, as soon as I had released my first cut and was asking people to participate, I could no longer just make unilateral decisions as I could when it was just me; for me to attract others to my project I needed to be *collaborative*.


Collaboration…gangnam style.

Shortly after I announced the project, *Rafal Cieslak* joined and started contributing code. Rafal and I had a series of discussions about the core system, discussing every decision I had made previously. I considered Rafal’s feedback on this strategic focus of the project as an equal to my own; Rafal deserved the right to have a say because he too had now taken time away from his family and friends to contribute to this Free Software project.

For new Free Software feature development, Canonical (or Red Hat, or Collabora, or Xamarin etc) has every right to keep things private to get the project in shape if they wish to. If the company is investing in hiring people to write a new piece of Free Software, they have *earned* the right to decide on that first cut. When the company then releases the project and if they want to have the community participate, the company then has a responsibility to be *collaborative* in their work with these active contributors.

## Ubuntu Will Always Be Open

Getting back to Mark’s post, Ubuntu is not becoming less open; you can still participate in pretty much every part of Ubuntu if you choose to. The point of his post is that there are indeed some projects (*some*, certainly not all) in which Canonical is creating new features in which these projects are private, and we want to open up and include community participation in those projects. This is a step towards increased community participation, not less.

Now, again, I know some of you will be boiling in your boots about the fact that these projects are not open from the beginning. You are welcome to slam me in the comments if you choose to, but I don’t make the decisions on keeping those projects private, so you might as well save your fingers.

What I *am* going to be responsible for is helping to get these private projects in a position where community folks can participate, where participating is fun and enjoyable, and and helping to get the right community people connected to the right projects. As Mark mentioned in his post, *Michael Hall* (who is `mhall119` on IRC) is going to be the point-man if you want to take part in these projects, and Michael sits on my team. We have already fleshed out an on-ramp for how community members can express interest in this and we will be following up more this week about how to get involved.

Thanks for reading!