Canonical Voices

Daniel Holbach

Next video hangouts

So for the last few weeks we have been doing Ubuntu Development video hangouts on Tuesdays and Thursdays and it was a lot of fun. We had quite a number of viewers, some new, some coming back for more info and lots of great questions.

Tomorrow we’ll do another one at 15 UTC, but we will skip the one on Thursday, as it will be the day of our Ubuntu Community Team 24 Hour Marathon, where we will stay up for 24 hours, work on Ubuntu and broadcast the video live on the internet.

If you have topics related to Ubuntu development you’d like me to talk about or something you’d suggest I’d have a look into, please let me know and if you’d like to support Oxfam and me in this event, please consider donating at my donations page. If you should need some further decision making help, check out my other blog post.

Working on Ubuntu is already doing good in the world, but doing good while working on Ubuntu is even more awesome. So have a look and enjoy the spectacle. :-)

Read more
Daniel Holbach

On 4th October everyone on our team at Canonical will work for a solid 24 hours period and stream it live to the internet. It will be hard, but it will also be lots of fun and we do it to raise money for charities. We all picked different ones and you can get more info about each of us on the Marathon page.

So a few friends already asked me: “Why Oxfam?” and there are obviously many many fantastic charities to choose from, but I thought I’d go into a bit more detail about why I love the work they’re doing.

Oxfam’s mission statement is “We believe we can end poverty and injustice, as part of a global movement for change.”, which is something I very much identify with.

I have very early memories of my life in which I had seen reports of injustice, poverty or hunger in the news and asked my mom why we let something like that happen. I was appalled, why isn’t everyone having a good life as I did? Even nowadays I find it hard to explain this to kids, which in my mind is the best way to test how much sense you are making.

Learning about organisations which helped to solve some of these problems reinstated my hope in humanity and I’m glad it did, because you’d probably all know a much less cheerful Daniel if that hope wasn’t reinstated back in my early days.

Oxfam makes long-term commitments to areas, so even when the reporters are gone, they stay and help to make these region less prone to catastrophes. They form local partnerships because they know that locals often know best how to address issues – there is no self-righteous sense of mission involved here.

A common garden

A common garden

Watershed in Balandougou, Mali

Watershed in Balandougou, Mali

Take the Sahel region for example. Life is hard there, rainfall is minimal and with climate change life gets a lot harder. Infrastructure and the medical situation can be problems too. So when there’s a drought hunger relief is important, but it’s not everything. You need to invest into education, you need to make sure people can sustain themselves and can find other venues of supporting themselves and others.

Oxfam’s help and support comes in all the forms mentioned above and many more, which is what I love about them. Sometimes it is seemingly small things like “an oven which needs less wood”, which in turn leads to less deforestation (which is a huge problem anyway) and girls (who do most of the wood collecting) having more time for their studies.

While this is all great work already, Oxfam doesn’t stop there. They deeply understand that some of the world’s problems are not made locally, but globally. So they campaign for policy change in lots of relevant areas, be it related to climate change, speculation on food prices, saving energy, issues related to biofuel and many other issues. Demonstrating against a coal power plant in Germany is connected to problems in the Sahel region. Oxfam get this. We’re in this world together.

Oxfam is also creative and fun. Their Unwrapped Store is a great opportunity to give presents and also make the world a better place. What I love most is the pair of goats (picture below) – there were a few weddings where this was part of my gift.

Pair of goats

Pair of goats

Also have Oxfam been around since 1942 and they picked two very important points: poverty and injustice, which if granted to everyone would put them into a position where they can “exercise their human rights, assert their dignity as full citizens and take control of their lives.”

This got more lengthy than I expected, but as you can see I really like what they’re doing. I have been supporting them for a while, getting their quarterly reports and a few of my friends volunteered from them. I’m quite sure you don’t do anything wrong if you support them.

If you want to support Oxfam and think working for 24h for Oxfam is a good idea, please donate here. Thanks in advance, you’re a hero!

See you all on http://marathon.ubuntuonair.com/ on 4th October.

Read more
Daniel Holbach

Ubuntu Dev hangouts

Last week I did two public video hangouts. The first one got a bit full, because I had not made it a hangout-on-air. Unfortunately Hangouts on Air don’t provide a chat widget, which makes communication a bit hard. So in the second one I used ubuntuonair.com which adds an IRC widget to the live stream. You can see the recorded session here. As you can see from the comment on the video (and others told me too), I should have used the Ubuntu on Air account for this. We are constantly improving. :-)

Now I need your advice, requests and ideas. These hangouts are about Ubuntu development, so about packaging, integration of software into Ubuntu and the like. What would you like to see in the next sessions?

The schedule for the hangouts is:

  • Tuesdays at 15:00 UTC and
  • Thursdays 8:00 UTC.

Please comment below and I’ll try to prepare a bit of content for our next sessions.

Read more
Daniel Holbach

I’m quite happy with the progress the Packaging Guide is making. We managed to fix a bunch of bugs this cycle and most importantly we got it into Ubuntu and made it translatable. We only opened translations a couple of weeks ago, but some language teams have been hard at work:

  1. pt_BR.po (18%)
  2. ja.po (14%)
  3. ru.po (9%)
  4. es.po (5%)
  5. id.po (4%)
    de.po (4%)
  6. nl.po (1%)
  7. sv.po (0%)
    fr.po (0%)
    lv.po (0%)
    zh_TW.po (0%)
    hu.po (0%)
    ca.po (0%)

At UDS we decided that for translations which came to a percentage of completion of >= 70% we would build separate packages for those languages. Up until to that percentage we will only keep the translations in Launchpad.

This means there is still some way to go for all of us, but this is a great great step already. Thanks a lot for your hard work on this!

There are obviously many more bugs to fix and we’d love your help.

Bitesize bugs:

Make it prettier:

One bug we’d love to see some help with is #1043232 Packaging Guide FTBFS – it looks like the build fails due to Japanese translations. Right now all translations are disabled, which serves as a workaround for now.

Thanks again to everyone who helped out with the Packaging Guide. Your help has got many many contributors on their way. Keep up the good work!

Read more
Daniel Holbach

We need some feedback. Can you please leave a comment with the information

  • you wish you had had heard when you got involved with Ubuntu development
  • you want to share with new starters in Ubuntu development
  • you learnt and found invaluable

As you can imagine, your feedback is going to make the experience for new contributors even better. Thanks a lot in advance.

Read more
Daniel Holbach

Hanging out with Ubuntu developers

We want Ubuntu development to be as accessible as possible. Ubuntu Developer Week (logs available on the page if you couldn’t make it) was a lot of fun, but now it’s time to take the next steps.

There are around 7 weeks left until our beloved quetzal is released. Now is the best time to get started, help out and fix a couple of bugs. To help you with this, we’ll start a series of Google Hangouts you can join easily. In the hangouts we’ll show you how to easily fix some small bugs, where to get the bugs from and answer all your questions. This is also a good opportunity to get to know Ubuntu developers a bit better.

This guy will be part of them as well.

I won’t be alone in these hangouts and expect other developers to join in.

To get us started, from next week on we’ll do the sessions at:

  • Tuesdays at 15:00 UTC and
  • Thursdays 8:00 UTC.

Session URL will be announced via the {identi.ca,twitter.com,gplus.to,facebook.com}/ubuntudev. Until then I’d recommend you have a look at these articles:

See you there! :-)

Read more
Daniel Holbach

With UDW over, what’s next?

So Ubuntu Developer Week is over (summaries day 1, day 2, day 3), what’s next?

If you enjoyed UDW and want to learn more about Ubuntu Development, I’d recommend reading the Packaging Guide and finding more information and examples to get a better idea.

Then you obviously need some tasks to work on. We identified a number of tasks on the Bug Fix Initiative page along with instructions. Among them are:

For new contributors:

For more experienced contributors:

Also do we have a couple of bugs open for the Packaging Guide, a bunch of them are tagged as ‘bitesize‘.

If you look at any of the tasks and find you need some help, talk to us in #ubuntu-motu on irc.freenode.net or send a mail to the ubuntu-motu mailing list.

We’d love to welcome you to our team, hope to see more of you soon!

Read more
Daniel Holbach

I talked many times about getting involved with developing Ubuntu and how it can seem daunting and that there’s much to learn. When I talked to contributors who had reached the critical point where they understood what they can do, who they can talk to and how the processes roughly work, most of them said that three things helped them to get to the point:

Code review

Today I want to talk about code reviews. It’s probably the most straight-forward way to learn by osmosis: you easily pick up conventions, distinctions which are made and which processes to follow.

Everybody has to go through code reviews, no matter which team they are in, which company they work for or when they joined the project. Up until a point they get their developer application approved and get upload rights.

This is the reason why code reviews in Ubuntu are so important and why we should constantly strive for timely replies and decisions on review requests.

Sponsoring Queue

The sponsoring queue is reviewed by developers with upload rights. Sometimes it’s very easy to approve a request and upload the package, sometimes it takes a bit longer, especially when you have a comment ping-pong between the reviewer and the patch author.

We came up with a number of points in our documentation which should help keeping the queue manageable:

For Bugs fixing small details, you could do the following:

  1. Ask the contributor to forward the patch upstream.
  2. Open an empty upstream bug task.
  3. Mark the Ubuntu task as ‘Fix Committed’.
  4. Unsubscribe ubuntu-sponsors, or mark the merge proposal status as “Work in Progress”. (Be sure to tell the contributor to reverse the process.)

This will get the review item off the list for the time being and once we can import the code from upstream, it will get fully closed.

We also get requests which are not suitable for the current release period. In this case you could:

  1. Let the contributor know that the patch is not suitable for the current release period.
  2. Unsubscribe ubuntu-sponsors, or mark the merge proposal status as “Work in Progress”. (Be sure to tell the contributor to reverse the process.)
  3. Subscribe yourself to the bug report.
  4. Milestone the bug to ‘later’.
  5. Visit https://bugs.launchpad.net/people/+me/+bugs/?field.milestone%3Alist=196 once the new release opens and upload the fix.

This are just some points which help to keep things on the queue relevant.

Patch Pilots

From the Bazaar team we borrowed the scheme of “patch pilots”. Here’s how they explain how it works: “The word pilot is in the sense of a maritime pilot: we help patches come through congested waters safely in to harbour. The main thing to watch is the bzr active reviews page in Launchpad. When you’re piloting, put some concentrated effort into helping people have a good and satisfying experience contributing to Bazaar. Just how you do that is up to you.

Instead of trying to review each and every bit in the queue – sometimes there are packages you know less about and where you can’t make a decision for example – you try to help nudge the patch along. You help to talk to upstream about it, try to find somebody who can make a decision, etc.

Canonical engineers with upload rights who work on Ubuntu are expected to spend an hour per week on the Ubuntu sponsoring queue, so everybody’s on the hook for having a piloting shift 4h every four weeks. This usually works much better, as you have an extended period of time where you do nothing else. Current patch pilots can be seen in the #ubuntu-devel channel topic.

Up until now I mostly noticed Canonical engineers who did piloted. If you have upload rights and are interested, let me know and I can add you to a preliminary schedule, so you get a reminder mail and you can try it out and see if you like it.

Please all help making this work even better. :-)

Read more
Daniel Holbach

Users of Ubuntu 12.10 (Quantal Quetzal) now can easily install the Ubuntu Packaging Guide:
daniel@daydream:~$ sudo apt-get install ubuntu-packaging-guide
Reading package lists... Done
Building dependency tree
Reading state information... Done
The following extra packages will be installed:
ubuntu-packaging-guide-html
The following NEW packages will be installed:
ubuntu-packaging-guide ubuntu-packaging-guide-html
0 upgraded, 2 newly installed, 0 to remove and 0 not upgraded.
Need to get 0 B/488 kB of archives.
After this operation, 1244 kB of additional disk space will be used.
Do you want to continue [Y/n]?
Selecting previously unselected package ubuntu-packaging-guide-html.
(Reading database ... 238890 files and directories currently installed.)
Unpacking ubuntu-packaging-guide-html (from .../ubuntu-packaging-guide-html_0.2.2_all.deb) ...
Selecting previously unselected package ubuntu-packaging-guide.
Unpacking ubuntu-packaging-guide (from .../ubuntu-packaging-guide_0.2.2_all.deb) ...
Processing triggers for doc-base ...
Processing 1 added doc-base file...
Registering documents with scrollkeeper...
Setting up ubuntu-packaging-guide-html (0.2.2) ...
Setting up ubuntu-packaging-guide (0.2.2) ...
daniel@daydream:~$

Of course you can always browse it online here but for all offline use it is now in Ubuntu in PDF, HTML and EPUB formats.

This was only possible through the help of many contributors. Some of them I was able to get together from the bzr log:

  • Alexander Fougner
  • Andrew Starr-Bochicchio
  • Barry Warsaw
  • Benjamin Drung
  • Brian Murray
  • Daniel Holbach
  • Dmitry Shachnev
  • Iain Lane
  • Jamie Strandboge
  • Jelmer Vernooij
  • Jeremy Bicha
  • Jim Campbell
  • Jonathan Jesse
  • Jonathan Riddell
  • Joseph Mills
  • Leo Iannacone
  • Martin Owens
  • Raoul Snyman
  • Ryein
  • Stefano Rivera

Thanks so much for your great work in the Ubuntu Packaging Guide project – you are all heroes!

There is still lots of work to be done. If you want to get involved, because it’s a really nice project, have a look at a list of bugs and please help to get it translated!

Read more
Daniel Holbach

Daunted

… was probably written across my face when I first got involved in Ubuntu and contributed my first patch. I wasn’t quite sure if I had followed the right procedure or if anything else was wrong, but luckily I found a lot of very friendly people who helped me out and got my contribution in.

That was almost 8 years ago. Today it’s a lot easier. There is good documentation, there are more consistent processes and better tools.

If you have pondered getting involved for a while, I’d like to invite you to check out our Bug fixing initiative. We singled out a number of issues in Ubuntu which we feel are appropriate to whetting your appetite and sorted them, so the most easy tasks are at the top.

Let us know how this works for you and ask all the questions you might run into on #ubuntu-motu on irc.freenode.net.

Read more
Daniel Holbach

We’re on day 2 of our apps sprint and made loads of progress. It has been a lot of fun to be in the midst of all this activity, so here goes just a quick list of things we worked on:

  • A number of bugs were fixed in arb-lint, the tool we use to check apps. It learned where we expect files to be put in /opt and we added some examples how to fix some of the issues. Find still outstanding bugs here.
  • Some smaller issues we found in the packaging were related to bugs in python-distutils-extra, which were fixed in the meantime, so we will try to backport it to precise.
  • We noticed some funny problems with apport hooks in apps, so we investigated the issue and filed these two bugs.
  • Allison set up a Trello board and many apps were reviewed. Thanks a lot to Bhavani Shankar, Allison Randal, Andrew Mitchell, Jonathan Carter and Paolo Rotolo.

What I liked most was how everybody who worked on some part of the apps story hung out together and cooperated on issues, so future generations of apps will have a much easier time.

Thanks a lot to Paolo Rotolo who joined the effort and just jumped in to fix issues in apps. Awesome! :-)

Read more
Daniel Holbach

Apps are super-important for Ubuntu. Many of us have blogged about this in a more general sense, but I want to provide an update of what has been happening behind the scenes in the last few weeks.

Before I start, I want to reach out to you to be part of the upcoming Apps Sprint. Join us on #ubuntu-arb on irc.freenode.net from Monday, 2nd July to Wednesday, 4th July to learn more about Ubuntu apps, get involved in reviewing them and bringing more progress to this effort.

Getting apps into Ubuntu hasn’t been easy up until now, due to a number of circumstances. The review process takes long, some of the steps involved are cumbersome and the review queue has been filling up. There are reasons for this and there is lots of room for improvement.

Technical requirements
As apps are part of a separate repository, the Technical Board requires us to make some very specific namespace distinctions between “regular packages” and apps. This means that apps install into /opt/ and files which can’t go there (.desktop files, lens specific bits, etc.) have to include the package name to avoid possible file name clashes.

This looks pretty straight-forward and you could just rename files and move things around as part of the packaging, but quite often this means you have to make changes in the code as well (think of file locations, translation files, data directories or file look-ups). For a larger app this results in quite a bit of engineering work to make all the changes and make sure they work as intended.

At this point I want to credit the App Review Board (ARB) for some work they have been doing. They could easily just have said: “Rejected: Your app doesn’t do it right.”, but instead they helped app authors to get their app working. This was time-consuming, but a learning experience for everyone involved.

The good news is: quickly, which is our recommended tool to produce apps, has templates where everybody worked hard to get the templates and the code up to scratch, so that writing code for the extras repository gets easier.

Another piece of good news is: pkgme has progressed nicely and can help with the initial packaging of apps (useful if you don’t use quickly).

I very recently started working on a tool called arb-lint, which automates certain parts of the app review. This will make it possible to collect the knowledge of app policies into it, so new ARB members or app review helpers can easily find out what’s wrong with an app and how to fix it. You could even run it on your own app and find out what needs to be improved.

To sum this up: everybody knows that packaging and policies is quite boring to app authors. They just want to focus on producing great quality apps, they’re not interested in tweaking their build-system to adhere to all the policies. Don’t worry – this is understood. There’s still work to be done, but the tools are all progressing nicely.

App submission
During the 18 months the App Review Board has existed, the submission process has changed a number of times. The tool which is now being used is called myApps and a lot of handy improvements have gone into it in the last weeks and months.

One current problem is that some app authors submit tarballs of their apps, others provide bzr branches, others submit their app in a PPA. While we know how to use all of these tools, it makes the review process fairly inconsistent. This is why we came up with a service called apps-brancher, which downloads the app’s code, sticks it into a bzr branch, attempts to package it if necessary and pushes it to Launchpad.

Staffing
The current ARB members are all volunteers and working hard on apps and other places in Ubuntu. Some weeks ago the Ubuntu App Review Contributors team was set up, so that more active helpers can easily join the effort.

Summary
It is true. There is quite a backlog of apps. Some of them might be reviewed and approved quickly, others will need quite a bit of engineering to get into Ubuntu. Some might not be suitable for the extras repository at all.

As you have read above, there are numerous improvements in the works and there are very likely lots of other things which might result in a nice speed-up. Your help will be appreciated here!

The Ubuntu Apps Sprint
All of the above is why we want to invite you to the Ubuntu Apps Sprint from Monday to Wednesday (2nd-4th July). Join us in #ubuntu-arb on irc.freenode.net to:

Quite a number of experts from the ARB, from the quickly and pkgme teams and lots of others will be around to answer your questions. We hope you will get involved and help us out.

Apps will make Ubuntu even more beautiful. It’s just great to get to see so much creativity first. Contributing here is totally worthwhile.

Read more
Daniel Holbach

In the last few weeks I have been looking into helping the Ubuntu App Review Board and with the help of some of its members I learned a lot about our app submission process and how apps need some special treatment with regards to their installation and package generation.

It’s been lots of fun and I think I have successfully contributed to a few apps. Some of them are up for vote now. What I like best is that you get a sense for the incredible amount of creativity of our apps developers. You really feel ahead of the curve in terms of which great new apps are coming in.

There’s quite a bit of activity right now as we are looking into technologies such as pkgme and see how we can make use of them for getting apps into Ubuntu even more easily.

As I said in an earlier blog post, we need some additional help to make more progress, so if you are interested, have packaging experience and would like to help, you can join

Read more
Daniel Holbach

Some of you might remember when Andrew Starr-Bochicchio send out the Developer Advisory Team’s analysis of the feedback new contributors gave us. It was a great read, told us a lot about how new contributors get involved, but it was a also quite a bit of work.

As we conducted most of our interviews via mail, we had lots of answers in our inbox. As a team, we put them into a Google Doc and after the release cycle had passed, we had amassed 6 months worth of feedback. Sometimes just a few lines which concentrated on just one topic, but sometimes heaps of text covering each and every point of their developer experience.

As we feel this was quite a bit of work, but also worth doing, we want to continue this effort. Still we are looking for ways to improve this. If you have ever done anything along these lines, we’d love to learn from your experience. How can we optimise this process?

A few requirements we have:

  • No surveys. When we reach out to new contributors we are interested in a conversation with them and not necessarily interested in getting them to rate and judge each and every bit they might have interacted with. By reaching out to them, we already ask them to spare us some of their time, a long survey would likely give us more structured feedback, but less responses.
  • No expensive text analysis software.

If you have any ideas how we can optimise the process, please let us know.

Also if you are interested in helping out the Developer Advisory Team, please get in touch.

 

Read more
Daniel Holbach

For more than once cycle I have been involved with the Developer Advisory Team and it’s been a fantastic time. I’ve blogged about it before, but if you need a short intro, you could watch the lightning talk from last UDS about it. Think of it as a team of people who help to make the development experience of Ubuntu more social.

We welcome new contributors to the community, we collect feedback, we help with applying for upload rights and the atmosphere in our team is great.

If you would like to work together with us (here’s the team in its full glory), please get in touch with me or just comment below. If you enjoy interacting with people and have sufficient insight into the Ubuntu development process, we’d be delighted to have you.

Read more
Daniel Holbach

I’ve rambled about this before and still feel strongly about the importance of apps in Ubuntu. We all need to put some work into this to make apps in Ubuntu truly rock. The good news is: you can help and you’re not alone!

The App Review Board has been hard at work, but they need help. So how does this work? If you have packaging experience and would like to help, you can join

The ARB have documented their guidelines and responsibilities. These docs you might want to review before joining to truly see if this is for you.

So what has been happening lately? The ARB team and helpers have been busy reviewing their queue, helping app authors to get their packages ready and perfecting the documentation and tools.

I have put together the apps-brancher, a tool which downloads apps and pushes branches to Launchpad. If you check out the status update I sent to the mailing list earlier, you can see where things currently stand. The wiki page explains how to use it. The great thing about this tool is that it makes use of pkgme, so even if a submitted app does not contain any packaging, we might have a good chance that pkgme can do the job for us.

As you can see, these are very exciting times. We not only review apps and make Ubuntu shine with new gems, but also work on infrastructure and tools which will make the tasks easier for future generations.

We hope to see you on the IRC channel and mailing list and help making apps in Ubuntu truly rock!

Read more
Daniel Holbach

This morning I woke up and found the sponsoring queue at 103 items! I mailed the ubuntu-devel and ubuntu-motu lists and the current count is down to 81. This is great, but I’m sure we can get it down to 0.

Jani Monoses also filed these bugs to discuss how we can improve our sponsoring strategy:

You might want to join the conversation.

What we need most though is that if you can review code and upload changes, you head over to the sponsoring queue and help reviewing. It’s understandable that after UDS everybody is busy doing merges or jumps head-first into work items, but we also need to help newcomers get their changes reviewed. If you need some help, review our sponsorship best-practices.

If you should want to help on a regular basis, ping me or drop me an email and I’ll add you to the patch pilot schedule and you’ll get monthly reminders.

Rock on everybody! We can be happy we have so many new contributors, let’s don’t let them down! :-)

Read more
Daniel Holbach

… for planning things, but also for getting things done.

In-between sessions I had discussions with many many folks and I’m happy to say there was renewed and much interest in the Packaging Guide.

Heroes like Andrew Starr-Bochicchio, Leo Iannacone, Joseph Mills and others have contributed suggestions, code, ideas and text bits to improve the packaging guide, and that’s on top of what was discussed in the session we had.

During the session we identified a number of areas of focus. In no particular order, there’s:

  • Include the Packaging Guide in Ubuntu
  • Translate it in as many languages as possible
  • Merge the Wiki documentation into the guide
  • Do user-testing of the guide
  • Do an editorial review of all the content

Also in many other sessions, the Packaging Guide was usually deemed the best place to educate new contributors about how things work, which is great.

What happened this week (outside of sessions) already was:

This level of activity is fascinating and bodes well for a great 12.10 cycle.

What I love most about the guide is that everybody can help us if you have just a little bit of interest in Ubuntu Development. Let’s have a quick look at some bugs you could help out with, if you’re interested.

Here’s some ‘bitesize’ bugs, I hope we can you interest in:

Obviously, there’s more bugs and there’s a blueprint to subscribe to. Feel free to grab a bug and help out, or catch us on IRC and find out how you can get involved.

Update: I forgot to mention John Kim, who has contributed a bunch of bug reports with his experience. Great work, John!

Read more
Daniel Holbach

Congratulations everyone, we got a fantastic LTS release out, some of the reactions of our users you can see here. Well done! :)

At the same time understandable, but also worrying is the look at our sponsoring page:

Silently with all the release freezes in place, the number of open sponsorship items has crept up to ~70 again.

If you are an Ubuntu developer or can help out with reviewing patches, please head to the sponsoring queue and help out. Many contributors and Ubuntu users are going to appreciate it. (Docs can be found here.)

Read more
Daniel Holbach

Jono blogged about the importance of application developers to Ubuntu earlier and I wanted to echo some thoughts and add some of my own.

I have been in the Ubuntu Developer camp for most of Ubuntu’s life as a project, so the mindset of “App developers? Why don’t they just set up an open source project and get it packaged?” or “Apps? We have packages.” is what I have heard a couple of times already and is what I would probably have answered some years ago myself.

The power of the Open Source community and having open projects is immense. We all have seen it many times: a thought, a great idea, some dedicated contributors, good communication and a friendly community can achieve amazing things. This happens every single day.

We are well aware of how things work in the Open Source world and we have recently seen the success of our great work: millions of users, who have never dabbled in Open Source before, today enjoy Ubuntu (or other pieces of Free Software) and rely on it. We have managed to reach out to an entirely new demographic and continue to grow our user base.

With new demographics there are new expectations and new responsibilities. Consider my father for example. He follows what’s going on in the Ubuntu world, but will occasionally point out to me that an app he’s interested in buying does not exist for Ubuntu. The last I remember him talking about was a good language learning course.

With new form factors and devices running Ubuntu (you know, TVs, tablets, phones, watches, cars, coffee machines, hoverboards and the like), there are going to be thousands of useful helper tools out there which might not be available for Ubuntu yet. Add to that the growing number of content providers (magazines, books, maps, music, etc.) which users yet can’t easily get “for Ubuntu”.

This is the world we are looking at today and it becomes obvious that apps should be a first-class citizen in Ubuntu. Don’t get me wrong. I’m all for making everyone who shows the slightest interest in working on Ubuntu itself an Ubuntu developer and member of our community, also because I feel that everyone who is part of this has a lot to gain, personally and for their particular project. It just shouldn’t be a strict requirement because it won’t scale.

A number of teams have been working very hard on making seamless apps in Ubuntu a reality and that’s just great to see. It’s a hard problem to solve because it involves so many different important pieces. Keep up the good work everyone!

At UDS I’m definitely going to (among other sessions, I’ll blog about later on) attend these sessions to see what we can do about making apps in Ubuntu more exciting and something that just works:

Hope to see you there!

Read more