Canonical Voices

Posts tagged with 'canonical'


Our community is at the heart of how we build Ubuntu. Recently there were some concerns expressed about some aspects of our community and I have been working with various community members and internally at Canonical to resolve some of these issues to make things smoother.

I just wanted to summarize some updates:

  • Regular, transparent planning – we want to improve how we plan the delivery of work items, and make that planning more nimble. While the major decisions are reserved for primary discussion at UDS, we want to regularly and transparently checkpoint progress on those projects, and ensure things are moving along. To do this the engineering managers at Canonical will perform this planning on a monthly basis with our community. An an example, with my team, we will decide at UDS what major projects we will work on and document the work items in those blueprints, and every month I will ask the team to commit to delivering an agreed set of work items that month and update the blueprints accordingly. This will make it easier to understand who is working on what, what needs to be done, and areas in which people can participate. This entire process will be completely open and transparent and I would like to encourage our wider community to use the same approach. As an example, this could be a useful technique for our LoCo community to use for planning their work too around advocacy campaigns. All of this work will continue to be tracked openly in
  • Training our engineers – our engineers at Canonical are expected to openly and transparently perform all work that is not considered customer/company confidential. While this expectation is clear, there are sometimes cases when this doesn’t happen (e.g. if someone joins Canonical without the experience of working in an open environment and isn’t really sure how to do this). I have prepared an internal slide deck with these expectations and workflows clearly laid out; my team will be working to ensure everyone gets the deck, reads it, and gets an answer to any of their questions.
  • Regular leadership problem solving meetings – one problem we have today is that we don’t have a regular problem solving meeting in our community in which our governing leaders are present at. Instead our different leadership boards (e.g. Community Council, Forums Council) tend to resolve issues pertinent to that specific board. We think it could be useful to have a meeting every two weeks that has representatives from our different governance boards and our community can join and raise topics for discussion. We are going to run the first one of these sessions tomorrow (Tue 19th March 2013) on Ubuntu On Air at 8pm UTC. We invite you to bring your topics there on IRC for discussion.
  • Online UDS refinements – as I blogged about last week we have released a survey to gather feedback about how to refine and improve UDS. We have already made some plans for some improvements but I plan on organizing a community meeting to discuss this more next week (I can’t later this week as I am at an event). I think there is an opportunity to refine the format of UDS into a form that becomes a useful and repeatable way of coordinating meetings in a community.
  • Weekly Updates – I have reached out to the engineering managers on some of the core projects at Canonical and asked them to provide weekly updates of work going on. We have already seen the first updates for Ubuntu Touch and Mir.
  • Prepping announcements better – while the major announcements are now out, one piece of feedback I received is that our community felt ill-prepared around things such as the Ubuntu Touch announcement, and people such as our IRC/Forums/Community councils were inundated with questions and didn’t have good answers to those questions. If we need to make future announcements in the same way again, I am going to ensure our core governance boards are clued up first and we provide a FAQ for our community to refer to when getting these kinds of questions. This should relieve this concern.
  • Improving our community on-ramp – one area where I want to drive some improvements is making it easier for people to join the community. We started some work a while back to improve the community landing page on and I have asked Daniel Holbach to drive that work to completion. I am also working with the Ubuntu Touch and Mir teams to ensure that they have awesome documentation and guidance for how people can participate. A good example of the progress being made here is the Mir documentation. If you would like to help improve these docs, then feel free to dig in and help, or share your ideas on the mailing lists.

I want to get as much feedback on these steps moving forward as well as other ideas and areas in which we can focus. You can always grab me on IRC on freenode (my nick is jono) and I hang out in #ubuntu-community-team. Also feel free to drop me an email and join my regular Q+A session every week. Unfortunately, this week’s Q+A session is canceled as I need to be at an event, but I will be back in the regular slot next week on Wednesday at 7pm UTC on Ubuntu On Air.

Read more

Recently there has been some fire flowing about Canonical in the community. These concerns started off as sporadic at first and then we saw a small blog avalanche (blogalanche, if you will) as a number of folks piled onto the ride.

I feel somewhat trapped in the middle of all of this. On one hand I work at Canonical and I believe Canonical are acting in the honorable interests of Ubuntu in helping to build a competitive and forward-looking Free Software platform, but I also feel a sense of personal responsibility when I see unhappy members of our community who are concerned with different aspects of how Canonical engages. Essentially, I sympathize with both sides of this debate; both have the best interests at heart for Ubuntu.

From my perspective there is a balance that needs to be struck. Our community needs to be transparent and open, but also nimble to react to opportunities (such as the convergence story), but also Canonical play an important role in helping us to drive Ubuntu to the masses. We need to be able to work in a way that maintains our Ubuntu values but also gives Canonical the opportunity to get our platform out to the market effectively to reach these users.

I believe one cannot exist without the other; Canonical cannot deliver this vision without our community and Ubuntu would be significantly debilitated if there was no Canonical providing staff, resources, and other investment into Ubuntu. Canonical is not evil, and the community is not entitled; we all just need to step back and find some common ground and remember that we are all in the circle of friends.

This symbol is as potent to me as it was back in 2004.

When I got interested in Linux back in 1998 and wanted to make it my career, my primary motivation was to bring freedom of technology to everyone. This is what attracted me to Ubuntu and ultimately working at Canonical. I don’t want to be rude to other distros who are quite happy within their remit of making a great OS for Linux enthusiasts, but I frankly don’t want to settle for that. I want Ubuntu to be the choice for Linux enthusiasts, but for us to not stop there and also bring Free Software to people who have not yet been blessed by it, and who may be new to technology and the opportunities it provides.

Achieving that goal is not just as simple as making the source code available for the platform and setting up a bunch of mailing lists. It means delivering simple and elegant user experiences built for the needs of our users, consistent and beautiful design, professional-grade quality, strong hardware and software partner relationships, certification across a range of hardware profiles, training, responsive security, diverse marketing and advocacy campaigns, and many other areas. Both Canonical and the community contribute extensively to provide these things that we need to get over that chasm, and importantly, each provides things that the other cannot.

It turns out that building this simple, ubiquitous Free Software experience for everyone is hard. We can’t just settle for the tried and tested approach of pulling the latest upstream software and integrating it into a single Operating System. That is tough, intensive and grueling work in itself, but to achieve the goals I mentioned above we need to be constantly challenging ourselves to innovate and go faster in how we deliver this innovation to our users. We need to always challenge the status quo…not for the sake of being different, but for the sake of not restricting ourselves to tradition and instead helping us to be better at what we do, and ultimately achieve our goals of getting Ubuntu into the hands of more people.

We saw this challenge with Unity: that was a tough, but necessary decision. While we suffered over the firestorm around Unity, I think it ultimately put us in a better position, and now we have a single convergent user interface that spans across multiple devices and we will soon have a single convergent Unity code-base across these devices too. In an era where desktop shipments are down due to the impact of phones and tablets, we are no longer trapped in a form factor that has had a decreasing scope of opportunity for us; the desktop is just one part of our wider convergence vision. This opens up the market for Ubuntu and the Free Software and Open Source values we encompass. While some people in some comment boxes will still bring the hate about Unity, I think that overall it has put us in a position to get Free Software in the hands of more people than if we didn’t make that difficult decision, and the sheer level of interest in Ubuntu for the phone, tablet, TV, and desktop is testament to that.

Put it in my pocket, on my lap, on my desktop, and hang it on my wall.

While making tough decisions is important, it is also important that we maintain our Ubuntu values too. One core value is that our platform and community are open for discussion and participation, so everyone is welcome to help put their brick in the wall. Our archive has long been open and there are many ways to contribute, and while some of these projects were secret before-hand, now everything is out in the open and available for participation. Some may disagree with the rationale of keeping things private, but particularly in the case of Phone and Tablet, the “big-reveal” helped us to have a big splash and generate more press interest and partner inquiries, and thus help us along to our vision.

Importantly though, we made the source and community on-ramp available as soon as we feasibly could. The code for Unity, Ubuntu Touch, and Mir is publicly available, and we are eager to invite people to join and shape those projects. This week we also ran our very first online UDS, with the goal of making the Ubuntu planning process as open and accessible to all as possible, not just those who could travel, and on a more regular cadence. All of the videos, notes and blueprints from that event are archived here. I am confident for the next event we will have an even smoother, better-run UDS, with even more participation.

We are now in a position with a clearly articulated vision around convergence and cloud orchestration, full source availability, daily builds of images, and public mailing lists and IRC channels to have those conversations. Everything is available in public blueprints and tracked at, and we have many outreach campaigns to help our community participate in this vision, such as the core apps project, port-o-thon, regular cadance testing, charm quality improvements, SDK participation, and other areas. Our community should expect our projects to be open, accessible and collaborative, and if they are not, please raise your concerns with the Canonical engineering managers, or talk to me either publicly on my weekly Q&A video hangout at 7pm UTC every Wednesday on Ubuntu On Air, or privately at, or by contacting me on Freenode IRC – my nick is jono. My door is always open.

Things are never perfect in a community, and I am not suggesting we are perfect either, but I believe we are at the cusp of an incredible opportunity to get Free Software and open technology into the hands of the masses, not just by wishing it to be true, but because there is genuine market opportunity for it to be true.

Read more

Some of you may have seen the news about us transitioning to an online Ubuntu Developer Summit and running the event every three months. If you didn’t see the news, you can read it here. I just wanted to share my personal perspective on this change.

For a long time now I have been attending Ubuntu Developer Summits as part of my work, but for the last event in Copenhagen my wife was about to give birth and so I attended the event remotely. As someone who has been heavily involved in the planning and execution of UDS for the last 10 or so events, I was intimately aware of the remote participation features of the event, but I had never actually utilized them myself. I was excited to dive into the sessions remotely and participate.

For the sessions I dialed into I found the remote participation worked well, but not as well as it could. Sometimes it was a little difficult to hear people (despite us alway encouraging speakers to sit near the middle of the fishbowl), and for the sessions I wasn’t able to actively participate in (due to the timezone differences), only some of those sessions had videos available that I could review after the session had ended. As such, this made it something of a challenge at times to get an overall view of the event; it depended on attendees taking good notes (which generally happens), but I missed the specifics of the discussions.

Remote participation has always been a critical part of UDS and I think it worked efficiently as it could, but these issues were primarily due to the challenge of delivering an in-person event to an online audience and the practicalities therein.

Of course, the real challenge is getting you people to eat these things.

The move to an online event effectively solves the majority of these issues: every single session will be recorded and available for viewing after the fact (which is awesome for not only attendees, but also for the press, partners and others), and with everyone in the hangout facing a webcam and a microphone, the quality of the content should be better too.

For those people who can’t join the session hangout video stream, IRC participation is available, and those IRC discussions will be logged too and provided in addition to the video of the session and the Etherpad notes. This provides a great overview of all the content and discussion in the session.

An online event is also going to open up the event to more potential participants. There are many folks who either can’t physically travel or justify the travel expenses or time away from their work and family commitments who can now participate in the event by simply opening their web browser. With the wide focus in Ubuntu across the desktop, devices and the cloud, we need more specialists rather than fewer to guide us on our mission, and the online event will make it easier for those folks to attend. I think that this will result in wider and more diverse discussion, ultimately helping us to do a better job planning UDS.

Some folks have expressed a concern about not having as much face-to-face time as in a physical event. Of course, video-conferencing will never ultimately replace being in the same room as someone, but I think much of that personal connection is still shared via hangouts. As an example, my team at Canonical used to have team meetings on Skype or a Conference Call and ever since we switched to Google+ Hangouts the sense of personal connection and team spirit has skyrocketed. Sure, it doesn’t replace being in the same room, but when we balance out the benefits of an online event for the reasons I mentioned earlier, it seems like a reasonable trade-off to me.

Iterative Improvements

One thing that many folks don’t see from behind the scenes of planning the physical UDSs is that we have always taken an really rigorous approach to improving and refining the event. This not only includes the structure of the event, but we have iterated after every detail to improve room layouts, A/V needs, timing, remote participation requirements, scheduling patterns, and more. Every detail of UDS has been scrutinized after every event, and the survey we send out is reviewed with a fine tooth comb, all with the goal of squeezing out as much efficiency as possible so the time everyone commits to UDS is as worthwhile as possible.

We are still exploring the alleged productivity-enhancing benefits of light ping-pong.

With UDS previously happening every six months this has helped us to build a pretty bullet proof formula for the physical event, and many attendees comment at each UDS about just how efficient it is and how much gets done. This is largely due to this iterative refinement process.

The first online UDS takes place next week and I think we have a pretty good plan for it, but we are going to go through exactly the same process for reviewing how each event goes and buffing off the rough edges so that works better and more efficiently each time. With us now doing a UDS every three months it should not take too long to get us into a winning formula, and our community are an essential part of helping us to refine these different pieces. As I mentioned in the announcement blog, after the second event we are also going to take a general look to see if an online UDS is serving the needs of the project well in terms of how we plan Ubuntu development.

Got Questions?

I am sure many of you will still have questions about the new format of UDS. Tomorrow (Wednesday) at 7pm UTC. I will be doing my usual weekly Q+A videocast on Ubuntu On Air and will dedicate part of the session to covering how the online event will work and answering your questions. Feel free to bring your UDS and any other questions to the session!

Read more

A few days ago we announced Ubuntu for Tablets; the next piece on our wider Ubuntu convergence story. The tablet joins the Phone, TV, Ubuntu for Android, and the Desktop. See an excellent hands-on video review of the current developer build from Engadget.

Today the source and images for Ubuntu for Phones and Tablets (collectively known as Ubuntu Touch) was released.

I know there is some anticipation regarding this release and I just wanted to share a few facts to ensure we are all on the same page:

  1. Both Phone and Tablet code and images are available – today we are releasing two things for both the phone and the tablet. Firstly, if you simply want to run the software on a spare device, you can install the images on your device without caring about the code. If on the other hand you want to see the code (and contribute to it) we are also making this available too so that you can build, explore, and hack on it.
  2. This is unfinished and in-development software – it is important to remember that this is in-development software and as such is not finished yet. You are going to find that some features and applications are missing, and you will likely find bugs. We wanted to release the code and images early so that our community can try the software, provide feedback, and be able to join the development effort. With this goal to get the content out early we just want to ensure everyone fully understands that this is not yet a final product. I strongly recommend you only install the code/images on a spare handset/tablet and not your main phone/tablet due to the fact it is in-development code.
  3. A limited set of devices are supported – the images are only available for the Galaxy Nexus, Nexus 4, Nexus 7, and Nexus 10; these are the devices that our development team has been working towards. We appreciate that you may have a different phone or tablet, but unfortunately support for other devices is not currently planned. We will however be kicking off an outreach campaign soon to encourage and support our community in porting the code to other devices. Stay tuned for more!
  4. A new SDK is available also – in addition to the release of the code and images we have also released a new version of the SDK which includes a number of new features, most usefully the ability to deploy a QML app to a device so you can run it!
    • Ubuntu SDK application templates and wizard
    • QML2 UI designer
    • Templates for testing framework and internationalization
    • Deploy QML applications on an Ubuntu Phone/Tablet device
    • Basic terminal (ssh, adb) connectivity tools to the device
  5. Know where to find help – if you have questions or queries you should post your questions to Ask Ubuntu by clicking here.

I am sure you are now chomping at the bit to grab the images, check out the code, and get the new SDK release! Go and find all the details here.

Read more

After missing my weekly live Ubuntu and Community Management video Q&A last week due to exhibiting at CES, I will be doing this week’s live video Q&A on Monday 14th January 2013 (tomorrow) at 7pm UTC (click here for the time in your location). The day is different this week as I need to join a sprint later this week.

I will be kicking off the session with a summary of Ubuntu at CES and a summary of the response to Ubuntu on phones in general as well next steps. We will then get into the Q&A, and as ever, you are welcome to ask me absolutely anything on the show.

To join, head over to Ubuntu On Air at 7pm UTC on Monday 14th January 2013 and you can ask your questions in the embedded chat box.

Look forward to seeing you all there!

Read more

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 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). 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… 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 theme), and I couldn’t use my own plugins. Unfortunately I need two key plugins: phpmarkdown and Disqus comments 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 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 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 for what needs to be done and this discussion to get involved (you can join the juju mailing list here).

Read more

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.

Thus far we have focused on the 8GB and 16GB tablets, but now the 32GB Nexus 7 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 (don’t worry, you can roll back to Android if you need to) and be sure to ask for help if needed.

If you find bugs, be sure to report them with ubuntu-bug, here’s how.

Thanks for helping!

Read more

It has been interesting listening into the UDS sessions remotely (find out how to join remotely here) 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 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 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 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 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!

Read more

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 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

If you have any questions about the installation and setup, please post on Ask Ubuntu; we will use the 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 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). 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; 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 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 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

Tuesday – 30th Oct

Wednesday – 31st Oct

Thursday – 1st Nov

Thanks for reading!

Read more

Regarding Mark’s post about participating in private projects, 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. 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!

Read more

As we build towards to the next Ubuntu Developer Summit in a few weeks, we have been getting our blueprints and plans in place to have a comprehensive set of discussions at the event. Unfortunately I won’t be there, fortunately due to an impending bundle of baby joy that will be entering my life, but I will be remotely participating. Be sure to join us there, there is no excuse, people. :-)

As part of these plans I have been having some wonderful discussions with Ivo Weevers who is the head of the Canonical design team and who reports directly to Mark Shuttleworth. Ivo is passionate about helping the design team at Canonical and the community to work closely together, and we have been discussing what problems we need to solve, and how to resolve them. In the past there have been concerns in the community that it is difficult for our community to actively participate in design and Ivo and I are keen to solve these challenges.

There are many topics to be discussed and we are currently fleshing out the schedule for UDS, but I am keen to solicit feedback about one particular piece of this puzzle.

Thankfully we are not trying to figure out the puzzle of opening one of these instruments of frustration.

As many of you will know, Ubuntu is a meritocracy; when people do great work, they have more influence over the project. As an example, our developers who work hard and become approved core-dev or MOTU contributors have more influence over our development operations than those who have not put in this level of development work. Now, before the haters start hatin’, I agree that Ubuntu is not a perfect meritocracy in that some Canonical staff members have direct influence over Ubuntu in a way that the community are unable to contribute. Examples of this include our infrastructure and systems teams, and to a degree this also includes the design team.

In a world in which everyone has a strong opinion about design, I believe that part of solving this challenge is that we need a means in which we can highlight the great designers from not-so-good designers. To be clear, this does not necessarily mean designers who agree with the Canonical design team, but instead designers who are collaborative, talented, contribute significant and sustained work, and bring their expertise forward to improve Ubuntu…the very same criteria we use to judge other areas of expertise in the project.

In the development world we have a pretty well defined way of assessing the cream of the development crop while still providing an opportunity for everyone to be able to ascend and aspire to that level of quality. We have methods of contributing that can build up a body of work that can then be reviewed and direct upload rights can be granted when the quality requirements are met. To do this we have the following:

  1. A clear definition of things that prospective developers can do.
  2. A simple means in which non-uploaders can contribute their work.
  3. Criteria that we can use to assess the quality of this body of work (e.g. technical quality, effectively following our guidelines and principles, providing a significant and sustained body of work etc).

I was chatting to Ivo about this and we would like to define the same three equivalent attributes for the design part of Ubuntu. Namely, we need to be able to point to things that people can do, have a means of reviewing this work effectively, and importantly, define criteria of what makes a great designer. I would propose that we apply these assessments to create an equivalent to core-dev in the development team but for designers. This way everyone can contribute more widely, but we can have a team of reliable, effective, community contributors that works closely with the Canonical design team and a clear means in which anyone can learn how to gain the skills to join this team.

I wanted to open up this discussion to the community to get your feedback and then we can review the feedback and discuss it at UDS and then start formulating a plan for the 13.04 cycle. In putting forward your suggestions, please bear in mind that we need to make the solution light-weight for everyone involved, both new contributors and those who will be reviewing the work of others.

Read more

A few days ago Stuart Langridge and I upgraded a machine from 8.04 LTS to 10.04 LTS and then from 10.04 LTS to 12.04 LTS, all over SSH. Both upgrades ran without a hitch. We simply ran do-release-upgrade and everything worked great.

Upgrading from a four-year old installation to a current installation with no problem was impressive. For everyone who contributed to making the magic happen, thank-you!

Read more

Recently there has been some concerns in our community about the online dash search feature, and these concerns have been orientated around the privacy of your data, the legal requirements for how this data is handled, and the effectiveness of the search.

These concerns have been taken very seriously inside Canonical and there has been extensive work going on to ensure we can tend to any outstanding issues ready for the 12.10 release. It is important to remember that this is the nature of how we develop Ubuntu; we often add features that later require additional focus and work based upon feedback in the community. This is just the nature of collaborative community; our community helps us to refine and improve Ubuntu in many ways based on feedback. I want to offer a sincere thank-you to everyone who has provided constructive, frank feedback about what we need to do to improve this feature and bring it in-line with the needs and expectations of our users.

So far in this story there has been a series of concerns and actions in response to this feedback. This is summarized as:

  • Concern about the usefulness of the feature – to resolve this a toggle switch has been added to the Privacy settings dialog to disable/enable the feature.
  • Concern about the encryption of traffic – traffic is now encrypted.
  • Concern about adult content being displayed via the lens – significant changes have been made to blacklist certain results based on keywords.
  • Concern about the legal requirements of this feature under European law – a Legal Notice link has now been added to the dash to make the terms of use clear for using the dash.

In addition to this, Cristian Parrino, our VP of Online Services at Canonical, who is basically in charge of Ubuntu One, our affiliate schemes, and who is responsible for the affiliate portions of the dash (e.g. Amazon/Ubuntu One Music Store results) has provide some further responses to these concerns.

Cristian published a blog entry – be sure to take a look.

Please feel free to ask any further questions in the comments. Thanks!

Read more

Over the last 24 hours the Canonical Community Team spent an entire 24-hour period together working, interviewing community members, planning further work, and fund-raising for our six charities; Oxfam (Daniel Holbach), Greenpeace (David Planella), Little Kids Rock! (Jorge Castro), Autism Research Trust (Michael Hall), WaterAid (Nicholas Skaggs), and Homeless International (Myself).

I am delighted to announce that at the end of this period we each raised the following for our charities:

  • £1055 – Daniel Holbach
  • £610.50 – David Planella
  • £898 – Jorge Castro
  • £709.13 – Michael Hall
  • £588.68 – Nicholas Skaggs
  • £1272.39 – Myself

…this totaling £5133.70 for charity!

Thank-you to everyone who donated, many of whom donated to multiple horsemen; your generosity is hugely appreciated, not just by us, but also by the many people, families, and neighborhoods that will benefit from your contributions.

Throughout our 24 hours online we were joined by many people for interviews and discussions. Thanks to Stuart Langridge, Gema Gomez, Daviey Walker, Carlos de-Avillez, Chuck Short, Joey-Elijah Sneddon, Laura Czajkowski, Alan Pope, Rick Spencer, Marco Ceppi, Clint Byrum, Ted Gould, Martin Pitt, Mark Shuttleworth, and Didier Roché. Thanks also to everyone in the IRC channel and on Twitter who stayed up to support the marathon and watch the discussions, interviews, see us coordinate projects and UDS work, joke around with each other, and even cook and barbecue together. It was a blast!

Finally, of course, I want to thank Daniel Holbach, Jorge Castro, David Planella, Nicholas Skaggs and Michael Hall for agreeing to take a full 24 hours out of their life, away from their families, and outside of their comfortable beds to take part in this madness. Spending 24 hours with the same five other somewhat-sleep-deprived people could be a recipe for frustration, but I think I speak for everyone in that it was simply a pleasure to spend time together as a team and as friends. I feel blessed to work with such a talented, hard-working, and friendly team, and the last 24 hours was another reminder of why I feel so fortunate to have such a wonderful job and with such a rocking team.

And with that written up…I am going to bed. Night all!

Read more

As part of the 24-hour marathon we are doing lots of interviews, as well as some fun sessions, Q+A sessions on more. Here is the first part of the schedule:

  • 2.00pm UTCGema Gomez – Assuring Quality in Ubuntu – we interview Gema Gomez who is part of the Ubuntu QA Team about how we are growing quality in Ubuntu.
  • 3.00pm UTCDaviey Walker – Ubuntu Cloud in 12.10 and Beyond!
  • 4.00pm UTC – App Developer Showdown – we will explain the plans set in store to provide the best App Developer experience to submit your apps to Ubuntu
  • 5.00pm UTCCarlos – community council and bugsquad
  • 6.00pm UTC – [tentative] Chris Johnston – Getting involved with Summit development, learn how to get the code running locally, how to make contributions, and what the future plans are for the project.
  • 7.00pm UTCChuck Short – Ubuntu and OpenStack – Chuck will be talking about some of the awesome work the Server team is doing to bring the latest from OpenStack into Ubuntu.
  • 8.00pm UTCTeam Q+A – Ask us about Ubuntu! Bring your questions and ask anything you like to any of the horsemen!
  • 9.00pm UTCThe Bacon BBQ Extravaganza – as part of some sessions about what the horsemen do for fun, join Jono Bacon as he starts his six hour smoking session of three racks of Baby Back Ribs. Come and find out how smoking works, check out the pit and the gadgets, and have a little fun!

We will have the schedule for the next part of the 24-hour marathon soon!

Come and join the fun at – thanks!

Read more

Gangnam Style.

At 10am UTC / 11am UK / 12pm Europe / 3am Pacific / 6am Eastern on Thurs 4th Oct 2012 the Canonical Community Team will be working for a solid uninterrupted 24-hour session. The marathon will involve Daniel Holbach, Jorge Castro, David Planella, Nicholas Skaggs, Michael Hall and myself; six horsemen spread across three different countries hitting the Ubuntu pump hard for 24-hours…all in the interests of raising money for charity while improving and growing Ubuntu and Free Software.

The entire session will be streamed live on where you can watch the action and chat to the team as we work and do the marathon.

Importantly, we want to use this as an opportunity for the community to get involved in the marathon too! Let’s use this 24-hour period as a great opportunity to add the finishing touches to Ubuntu 12.10, work on different projects, improve our documentation and translations, and help share knowledge and experience.

Of course, at the core of why we are doing this work is to raise money for charity…let’s see how much money we can generate for the six good causes that we have picked! Please go and DONATE!

So…at 10am UTC / 11am UK / 12pm Europe / 3am Pacific / 6am Eastern on Thurs 4th Oct 2012 be sure to head to and join the fun – also please tweet about the marathon with the #ubuntumarathon hashtag. Thanks!

Read more

Apologies for such a long post, but I want to ensure you all have the necessary information about our focus in 13.04. Please feel free to ask any questions in the comments!

As we edge towards our next release, I have been preparing my team, the Canonical Community Team, for the forthcoming 13.04 cycle and I want to share the process to give you folks an idea of how we decide what to work on. Please note that we are a community management team, so if your favorite feature, bug-fix, or pet peeve is not listed here, don’t be surprised, we are not a normal engineering team who builds features or fixes bugs inside Ubuntu.

The goal of this preparatory work is for me to gather input from our stakeholders, the community, and our team members to get a firm idea of the problems and opportunities that are in front of us. I then take this input into account as I assess what would be the best use of the team’s expertise and resources.

Our team’s mandate is pretty wide…the community is a big place…so it is always difficult to settle on the most critical areas of focus from a wealth of worthy candidates. My apologies that we simply don’t have the bandwidth to focus on more areas, but everyone on the team is always available to help our community leaders and contributors to be successful – if you don’t see your community problems and opportunities listed here, that doesn’t mean we are not here to provide help, guidance, and support – feel free to reach out to us!

You can catch us in #ubuntu-community-team on freenode IRC, and feel free to email us or simply leave your comments on this blog entry.

Please don’t reach out this way.

When I have finished gathering this input I then work with the team to map out in a spreadsheet each of their objectives, goals, success criteria, and an overview of the work required for these items. This spreadsheet provides a good overview of the body of work for each horseman, and then when I approve these objectives and goals I ask each team member to register blueprints for each goal.

These blueprints are public pages on Launchpad that serve a number of important purposes:

  1. They form the backbone of the sessions we have to discuss these objectives and goals at UDS.
  2. They provide a place in which we can track decisions and further work, right down to the work item.
  3. They provide wonderful transparency and an easy way for anyone to see changes and updates to each one of our goals – you can subscribe to a blueprint and you get emails when they change (including changes to the status of work items).
  4. They provide the input to where we can get visibility on this work so I can help ensure everyone stays on top of things.

Today I finalized with my team these core objectives and goals and I want to now provide an overview of them. You should expect to see the team follow up on their own blogs with further details and topics for discussion as well as the specific blueprints for these goals that you can subscribe to.

I will also follow up after UDS with a full listing of all blueprints we are working on so you can see everything in one place. This blog entry is designed more to provide some background to this work.

Please note: even though we have an idea of the objectives and goals, the final solutions, outstanding questions, implementation details, and other content is not finalized; that is the purpose of the Ubuntu Developer Summit…to delve into the details and plan how we achieve those goals together as a community.

Let’s now take a look at these plans, divided up into topic areas.

Quality Assurance

Over the years we have developed standards of practice of not only how we build Ubuntu but also how we strive to encourage the same philosophy in other projects. This has included our focus on cadence and design; both of these underpinnings in how we build Ubuntu have helped improve the final product, and it has been great to see other projects taking similar approaches.

In the last few years we have made quality a core part of these standards of practice, and matched them with neccessary investment from Canonical. This includes the growth of our QA team and I hired Nicholas Skaggs on my team who has been doing a fantastic job growing and building our community of testers and quality engineers.

These additional resources have been focusing on growing our automated testing infrastructure, increasing our manual test coverage, and improving our visibility on defects which will ultimately result in resolving those issues and preventing regression. Many of you will have felt the results of this quality investment in 12.04, and the train is rolling on with 12.10 and through to 13.04.

Quality is a difficult thing to show as a picture, so heck, here’s a duck.

Over the last few weeks Nick and I have been talking a lot about two core goals in 13.04:

  1. Growing our community of testers.
  2. Improving our visibility and predictability so we apply our QA resources and community smarter.

There is important yet subtle distinction in this work. Our goals are to assure quality, not just to ensure things get tested. We want to ensure that the right things get the appropriate level of testing so as to assure they work correctly in Ubuntu.

In Ubuntu we typically have two core types of testing going on…automatic and manual testing. The QA team led by Pete Graner have been building out our automated testing facilities and the goal here is to ensure that everything that can be tested is tested in an automated fashion. For those areas that cannot be tested with an automated test, we lean on Nick to rally our community to help with manual testing of those areas.

Automated Testing

The QA team have been working extensively on our automated testing facilities. The goal here is simple: for us to provide a comprehensive set of automated tests that are regularly run and provide visibility on regressions and other issues. These automated tests provide an effective means of raising red flags that our developers need to focus on fixing.

Having an automated testing infrastructure is one thing, but it is nothing without the tests. With the QA team getting the infrastructure up and running, I have asked Daniel Holbach and Nicholas Skaggs to work with our community to encourage and grow our test coverage. The contribution of automated tests is a wonderful way of assuring the quality of Ubuntu and providing more visibility on where problems may exist so we can fix them, thus producing a better quality Ubuntu.

This work will first involve ensuring that the neccessary documentation is in place, that our community knows which tests are required, and that there is a simple means of contributing tests. We will then have an extensive outreach campaign to encourage our community to participate and write tests; expect outreach about this at UDS and in future community events.

Manual Testing

When something can’t be tested automatically we rely on human-run manual testing. Currently we have two types of testing:

  1. In 12.10 we moved to a twice monthly regular cadence testing (primarily testing the installation experience) – this happens without fault every two weeks with the goal that all tests are run.
  2. We often have a series of reactive test plans to test things such as a new Unity release or problem spots in the distribution.

The challenge with the latter reactive tests is that they sometimes resulted in a bit of a scramble to get things in place. What can sometimes occur is that a new component lands in Ubuntu that either (a) includes significant changes or (b) has problems and Nick works quickly to get out a test plan.

As such in 13.04 I have asked Nick to provide a more predictable manual testing methodology and to provide greater visibility on the state of QA in the distribution. Nick is going to work on a weather report visualization of where quality issues exist in different parts of the platform. On one hand this will be a data-driven view and on the other this will involve some human input.

The goal here is to provide a simple means in which our community can identify problem spots and then we can tie together greater automated and manual testing based on these needs. This quality report will be augmented with community growth campaigns to get more people interested and participating in QA. Nick will also continue to run the cadence testing every two weeks.

It is rumored that the reason for the two week cadence is that it lines up with the next Seinfeld marathon. This cannot be confirmed nor denied.

The culmination of this QA work will result in a growth of automated tests and a community who produces these tests as well as better visibility on where there are quality issues in Ubuntu so we can apply appropriate automated and manual testing and community growth to relieve those issues.


Juju has seen some wonderful growth in the last year. With Ubuntu’s popularity in the cloud, the Devop crowd have been getting increasingly interested in Juju and the team has been continuing to grow and extend Juju to support the needs of our users.

On my team Jorge Castro is there to grow the Juju community. When we started this work the goal was simply to grow the number of charms and active charm contributors. This work involved Jorge flying out and running charm schools, organizing charming competitions, and we spent a lot of time getting the documentation, community governance, review processes and other necessary pieces in place.

Earlier in this cycle we changed gears to really focus on quality applied to a target set of charms. A big chunk of this work involved the creation of the Charm Quality Rating scale that provides a means in which we can determine what an awesome high quality charm looks like. We then applied it to the set of charm targets. Jorge and members of Antonio’s team have been reaching out to upstreams to work together in improving the quality of their software when deployed with Juju.

In 13.04 Jorge will continue to focus his efforts on this quality initiative and working with upstreams around this work. Jorge will also re-focus back on the wider net of charm and community growth to keep our community growth consistent while we focus on quality.

With every new community I always mentally segment the new community member interface into what I call the on-ramp. It looks like this:

Not meant for skateboarding.

This effectively covers the challenges that new community members face when they join a community. First they need to know that they can participate in the first place, second they need to know the skills to participate, thirdly they need to know what to work on, and then finally they need to feel great about their contributions and get the recognition they deserve. This is all part and parcel of how we build a strong sense of belonging in communities which increases the stickyness of contributors who want to stick around and participate in the project.

Over the last year Jorge and others have put together these various pieces of the on-ramp as required, but I have asked Jorge to do a full on-ramp review to ensure we have each of these parts nailed. This is going to involve a blueprint for each part of the on-ramp, a full review of each area, user-testing our resources and community-faces interfaces, and identifying and resolving any deficiencies reported. This will result in a more efficient, more pleasant, and more productive community experience.

App Developers

In recent months my team have been focusing on improving the app developer experience on Ubuntu, and ensuring that we present a simple, powerful, and flexible platform in which developers can build rich, feature-full apps that integrate neatly into the platform and benefit from the flexibility of Ubuntu. David Planella and Michael Hall have been doing wonderful work in this area.

To fulfill the needs of app developers we have a few challenges to overcome. I see the app developer experience involving the following pieces in the pipeline:

  1. Providing the tools, resources, and skills-acquisition to write apps.
  2. Promoting the benefits and opportunities of Ubuntu as a platform for app developers.
  3. Providing a simple and effective means of delivering applications to Ubuntu users.

For the first bullet, we are going to continue to make improvements to ensure that new developers have all the information they need. We have already scoped out some improvements to that will provide these important resources for our app developer community. This will include:

  • Integrated API documentation for our various APIs.
  • A code snippets library that will make it easier to find what you need and get started.
  • A video tutorial section.
  • Ask Ubuntu integration.
  • An outreach campaign to increase the number of recipes we have on the site.

Our goal is that continues to be a hub of information and support for Ubuntu app developers.

For the second area we are going to continue our app developer community growth. Here I have asked David Planella and Michael Hall to continue to grow the number of app developers who are interested in building apps for Ubuntu and ensure they have the skills and opportunity to deliver fantastic apps to our users. In the last cycle we ran the Ubuntu App Developer Showdown and we want to run similar kinds of initiatives. This will include regular Google+ hangouts, an app developer education week, weekly guest hangouts and more.

For the final area, as I blogged about before, we need to improve the ease and pipeline of how developers can get their applications into Ubuntu. Over the last few months we have been working on a spec to solve this challenge. This is a foundational piece of work that will help to significantly ease publishing apps to the Ubuntu Software Center. The spec involves many different pieces of work from many teams. The Security and Foundations teams have already committed to much of this work in the 13.04 cycle, but there will be lots of general coordination of these pieces that we will need to work on. This spec will certainly not be completed in 13.04, but much of the foundational pieces will be worked on.

The new app upload process.


Our developer community has always been important to us, and in 13.04 we will continue to focus on and grow interest and participation in Ubuntu development. As usual, Daniel Holbach will be coordinating this work, and we have identified some important areas of focus.

First and foremost, 13.04 is going to be all about growth. In 12.10 the Developer Advisory Team was put into place and there were significant improvements to our packaging guide, and in 13.04 the focus is going to be on supporting our active contributors in getting through the developer process and becoming active developers.

This work will not just focus on Core Developers but also MOTU. Our MOTU community is incredibly important to Ubuntu and the work they do in maintaining the comprehensive set of packages in Universe is hugely valuable to our users. Daniel will be be priming the pump for every Developer Membership Board meeting and helping to ensure potential candidates have their necessary documentation in place and the DMB are notified of their application.

If you are actively participating in Ubuntu development today and submitting your contributions to the sponsorship queue, get to know this guy, he can help you with anything you need:

if you whisper three times magic happens

As part of this developer growth work Daniel is also going to run a bug fixing initiative in 13.04 to increase the visibility on bugs for our community contributors so our new developers can feel like their work is fixing the right parts of Ubuntu and feel great about those contributions (also fitting in with our quality goals). Daniel will also be working on a series of educational videos for how to participate as a developer and be performing a lot of active developer growth outreach via Google+ hangouts, Ubuntu Developer Week and more.

Ubuntu Accomplishments

As some of you will have seen, a number of us have been hacking on the Ubuntu Accomplishments project in our spare time. The project has made significant progress and is pretty much at a point that is ready for community-wide deployment. This involves moving the validation server over to a Canonical hosted machine, deploying the web interface (which will eventually be, and getting it packaged and into the Ubuntu Software Center.

This work will result in a system that provides context sensitive documentation for how to participate, improves social community connection points (via the web interface), and provides a great method of acknowledging contributions. In a nutshell, Ubuntu Accomplishments makes participation discoverable and acknowledged. I am excited to see the community utilizing the system and continuing to grow support for different types of accomplishment.

I have asked Michael Hall to work with the Canonical IS team to get Ubuntu Accomplishments deployed and to ensure the system is packaged and available in the Ubuntu Software Center ready for the 13.04 release.

Other Topics

The topics covered above are really just the core areas of focus in the cycle, and a typical cycle for our team involves hundreds of other responsibilities and different pieces of work from LoCo Teams to Documentation to Translations to UDS, improving communications and more. When UDS is completed and I provide the update with the full list of blueprints I will expand on these additional topics too.

If you got to this point, thanks for reading…I know this was a long post. Please do let me know if you have any other questions or queries. Thanks!

Read more

…I am willing to do stupid things in exchange for money while fund-raising for my charity at our 24 hour Ubuntu marathon on Thursday. We have raised £1515.95 but we need more!

DONATE HERE and suggestions welcome in the comments!

Read more

The other day I announced our 24-hour horsemen marathon. In a nutshell, we in the Canonical Community Team are going to work for a continuous 24-hour session on Thursday next week. Each of us has picked a charity that we are going to support and I wanted to share some words on why I picked mine…Homeless International.

A few years ago Erica and I were driving through a city and we saw an old guy, bleeding, with no coat, walking along the street in the rain, clearly exhibiting schizophrenia. We both immediately stopped the car and I got out to go and help the guy. I got chatting to him. He was a veteran, he had a son that he had lost touch with, and that day he had given his coat to a lady so she wouldn’t get wet in the rain.

Shortly after I got chatting to a family friend who works with the homeless and he started telling me the true extent of the problems with homelessness and poverty all over the world (he organizes charity events to help the homeless here in the Bay Area). I started looking online more and more into the issue and became more and more passionate about the issue.

Most importantly, homelessness and poverty doesn’t just affect other people. Mental illness, health problems, disability, family issues, escalating drug/alcohol problems and other issues are often the causes of why someone ends up on the streets. It could affect you, your family, or your friends.

Homeless International work to provide support and help to the homeless and poverty stricken all over the world. They do wonderful work in many countries, and they work to provide housing, resources, aid, and other support. They are a truly valuable cause and I am proud to be supporting them.

For more information on the marathon and why you should donate your money to my charity, see the video:

Can’t see the video? Watch it here!


If you donate you will have love, success, and and unlimited supply of bacon (despite the global shortage) in your life. Who could argue with that?

Read more

This photo taken when we toured with Justin Bieber.

See that motley crew above? That is my team, the Community Team at Canonical. I am blessed to have such a wonderful team; not only are they all fantastic community leaders, but they are just a fun bunch of guys in general to be around.

A while ago I suggested to the team that we do something for charity. We spent some time brainstorming, and exploring ideas from the sublime to the ridiculous. We then hit on something we were all fans of…an idea in which lots of Ubuntu work will be done, charities will benefit from, and should be fun and entertaining…

…we are going to have a 24-hour work marathon, streamed live online for your morbid pleasure and amusement.

How It Will Work

In a nutshell, each of us is going to work for a solid 24-hour block, taking breaks where needed (no, a break can’t include an 8-hour nap). Each of us will log on and our entire day will be streamed live on Ubuntu On Air.

In this 24-hour period we will work collaboratively on projects, discuss our work on the stream, answer questions from the community, give tutorials, and more. We are open to ideas of things we can do throughout the day that might be interesting to the community (such as topics for tutorials, discussion topics, work we should do etc). Feel free to share your ideas on this wiki page.

Anyone who knows us knows that we like to have fun. As such we will all try to bring a little something from our personal lives to the marathon too, after all, you are stuck with us for a full day. As an example, I fully plan on smoking a few racks of ribs while I am working, so you can join me for the cook. I am sure that Daniel will make a Tofu sandwich or something. :-)

The reason why we are putting ourselves through this is to raise money for charity. We couldn’t pick a single charity, so each of us have picked a charity that we care about, and we are frankly going to turn this into a flat-out competition for who can make the most money. As we progress though the marathon we plan on having some bets and forfeits if we can outdo each other with our charities. It should be a lot of fun. :-)

The Charities

So which charities are we going to be raising money for? Take a look below…

Nick Skaggs is supporting WaterAid and he says “Water has always played a role in my life. I grew up on the Great Lakes, which are huge reservoirs of fresh water. The lakes, rivers and streams I grew up near at one time were quite polluted — the town I was born in had several dysentery outbreaks in it’s early history. It’s sad to see such waste of fresh water. Water to me is beautiful, and my favorite beverage ;-) There’s nothing like a glass of water to quench your thirst. Provided of course, that water is clean. WaterAid has a mission to deliver long-term sustainable drinking water to the world, via wells and better sanitation efforts to keep local water sources pure. Water is crucial to life, ourselves and nature is highly dependent upon it. Access to clean drinking water is the most basic of all human survival needs. We can go for days with food, get by without shelter, but we cannot survive long without water“. I am supporting Homeless International and because “I have always been aware of homelessness and poverty but it never really touched me until I saw an old man, bleeding, clearly exhibiting schizophrenia, walking through a city street in the rain. Many homeless and those in poverty are our elderly, our veterans, and our sick and vulnerable. No-one is immune to homelessness and poverty…many become homeless or fall into poverty due to health and trauma problems. Homeless International is a wonderful organization who helps provide shelter, aid, and support homeless people across the world. Your donation will provide help the elderly, sick and vulnerable to have shelter. Thanks for your donations!“. David Planella is supporting Greenpeace and he says “Having grown in an environment very close to nature has made me appreciate how big a gift and how fragile this planet we live in is. I’ve chosen to support Greenpeace as an organization whose core values are to “change attitudes and behaviour, to protect and conserve the environment and to promote peace”, with which I very much identify. Help me support an NGO that gives voice and acts to protect the place we all share and spend our lives in“.
Daniel Holbach is supporting Oxfam and he says “Oxfam puts lots of hard work into ending poverty and injustice as part of a global movement for change. Oxfam deeply understand that we all live in this world together and that problems need to be solved holistically. I’ve been supporting them for years and some of my friends have volunteered for them as well“. Jorge Castro is supporting Little Kids Rock! and he says “In Junior and High Schools I played trumpet, tuba, Sousaphone, electric bass, and a double bass. I made lots of friends, got to do great things like play festivals, and expanded my mind by learning to appreciate everything from jazz to classical to rock and roll. I can’t imagine growing up without playing music, and every kid should have the opportunity to do so. Little Kids Rock helps not only by providing disadvantaged schools with instruments, but with a curriculum that’s modern and not boring. Instead of sitting in a room playing scales all day, the students are taught popular songs and are encouraged to learn by just playing together“. Michael Hall is supporting Autism Research Trust and he says “Autism and Autism Spectrum Disorders are developmental disorders that affect a large number of us in the open source community, our friends and our families. Despite it being wide-spread, very little is know about it’s cause, and the only proven treatment is early detection and intervention. The Autism Research Trust funds the ongoing scientific research at Cambridge University into the cause and interventions for Autism“.

Thanks to the team for picking a wonderful range of charities, all of which are great causes!

When, Where, and How

The 24-hour Horsemen Marathon will take place on Thu 4th Oct 2012. We will start the marathon at 3am Pacific / 6am Eastern / 10am UTC / 11am UK / 12pm Europe and finish at the same time the following day.

Be sure to come and join us and provide your support and input. This is an interactive event and we are looking to our community to suggest things we can do, chat to us while the marathon is taking place, and take part. You can do this via the chat and social media facilities that are on our marathon page. Let’s make some epic coin for our charities!

Watch, interact, and donate right from here!

Also, please spread the word about the marathon on Twitter, Facebook and elsewhere. Use the #ubuntumarathon hashtag and be sure to link to – thanks!

Read more