Canonical Voices

Posts tagged with 'community'

Michael Hall

Shortly after the Ubuntu App Showdown earlier this year, Didier Roche and Michael Terry kicked off a series of discussions about a ground-up re-write of Quickly.  Not only would this fix many of the complications app developers experienced during the Showdown competition, but it would also make it easier to write tools around Quickly itself.

Unfortunately, neither Didier nor Michael were going to have much time this cycle to work on the reboot.  We had a UDS session to discuss the initiative, but we were going to need community contributions in order to get it done.

JFDI

I was very excited about the prospects of a Quickly reboot, but knowing that the current maintainers weren’t going to have time to work on it was a bit of a concern.  So much so, that during my 9+ hour flight from Orlando to Copenhagen, I decided to have a go at it myself. Between the flight, a layover in Frankfurt without wifi, and a few late nights in the Bella Sky hotel, I had the start of something promising enough to present during the UDS session.  I was pleased that both Didier and Michael liked my approach, and gave me some very good feedback on where to take it next.  Add another 9+ hour flight home, and I had a foundation on which a reboot can begin.

Where is stands now

My code branch is now a part of the Quickly project on Launchpad, you can grab a copy of it by running bzr branch lp:quickly/reboot.  The code currently provides some basic command-line functionality (including shell completion), as well as base classes for Templates, Projects and Commands.  I’ve begun porting the ubuntu-application template, reusing the current project_root files, but built on the new foundation.  Currently only the ‘create’ and ‘run’ commands have been converted to the new object-oriented command class.

I also have examples showing how this new approach will allow template authors to easily sub-class Templates and Commands, by starting both a port of the ubuntu-cli template, and also creating an ubuntu-git-application template that uses git instead of bzr.

What comes next

This is only the very beginning of the reboot process, and there is still a massive amount of work to be done.  For starters, the whole thing needs to be converted from Python 2 to Python 3, which should be relatively easy except for one area that does some import trickery (to keep Templates as python modules, without having to install them to PYTHON_PATH).  The Command class also needs to gain argument parameters, so they can be easily introspected to see what arguments they can take on the command line.  And the whole thing needs to gain a structured meta-data output mechanism so that non-Python application can still query it for information about available templates, a project’s commands and their arguments.

Where you come in

As I said at the beginning of the post, this reboot can only succeed if it has community contributions.  The groundwork has been laid, but there’s a lot more work to be done than I can do myself.  Our 13.04 goal is to have all of the existing functionality and templates (with the exception of the Flash template) ported to the reboot.  I can use help with the inner-working of Quickly core, but I absolutely need help porting the existing templates.

The new Template and Command classes make this much easier (in my opinion, anyway), so it will mostly be a matter of copy/paste/tweak from the old commands to the new ones. In many cases, it will make sense to sub-class and re-use parts of one Template or Command in another, further reducing the amount of work.

Getting started

If you are interested in helping with this effort, or if you simply want to take the current work for a spin, the first thing you should do is grab the code (bzr branch lp:quickly/reboot).  You can call the quickly binary by running ./bin/quickly from within the project’s root.

Some things you can try are:

./bin/quickly create ubuntu-application /tmp/foo

This will create a new python-gtk project called ‘foo’ in /tmp/foo.  You can then call:

./bin/quickly -p /tmp/foo run

This will run the applicaiton.  Note that you can use -p /path/to/project to make the command run against a specific project, without having to actually be in that directory.  If you are in that directory, you won’t need to use -p (but you will need to give the full path to the new quickly binary).

If you are interested in the templates, they are in ./data/templates/, each folder name corresponds to a template name.  The code will look for a class called Template in the base python namespace for the template (in ubuntu-application/__init__.py for example), which must be a subclass of the BaseTemplate class.  You don’t have to define the class there, but you do need to import it there.  Commands are added to the Template class definition, they can take arguments at the time you define them (see code for examples), and their .run() method will be called when invoked from the command line.  Unlike Templates, Commands can be defined anywhere, with any name, as long as they subclass BaseCommand and are attached to a template.

Read more
Michael Hall

A few weeks ago, Canonical founder Mark Shuttleworth announced a new project initiative dubbed “skunk works”, that would bring talented and trusted members of the Ubuntu community into what were previously Canonical-only development teams working on some of the most interesting and exciting new features in Ubuntu.

Since Mark’s announcement, I’ve been collecting the names and skill sets from people who were interested, as well as working with project managers within Canonical to identify which projects should be made part of the Skunk Works program.  If you want to be added to the list, please create a wiki page using the SkunkWorks/ParticipationTemplate template and send me the link in an email (mhall119@ubuntu.com).  If you’re not sure, continue reading to learn more about what this program is all about.

 What is Skunk Works?

Traditionally, skunk works programs have involved innovative or experimental projects lead by a small group of highly talented engineers.  The name originates from the Lockheed Martin division that produced such marvels as the U-2, SR-71 and F-117.  For us, it is going to focused on launching new projects or high-profile features for existing projects.  We will follow the same pattern of building small, informal, highly skilled teams that can work seamlessly together to produce the kinds of amazing results that provide those “tada” moments.

Why is it secret?

Canonical is, despite what some may say, an open source company.  Skunk Works projects will be no exception to this, the final results of the work will be released under an appropriate open license.  So why keep it secret?  One of the principle features of a traditional skunk works team is autonomy, they don’t need to seek approval for or justify their decisions, until they’ve had a chance to prove them.  Otherwise they wouldn’t be able to produce radically new designs or ideas, everything would either be watered down for consensus, or bogged down by argument.  By keeping initial development private, our skunk works teams will be able to experiment and innovate freely, without having their work questioned and criticized before it is ready.

Who can join?

Our Skunk Works is open to anybody who wants to apply, but not everybody who applies will get in on a project.  Because skunk works teams need to be very efficient and independent, all members need to be operating on the same page and at the same level in order to accomplish their goals.  Mark mentioned that we are looking for “trusted” members of our community.  There are two aspects to this trust.  First, we need to trust that you will respect the private nature of the work, which as I mentioned above is crucial to fostering the kind of independent thinking that skunk works are famous for.  Secondly, we need to trust in your ability to produce the desired results, and to work cooperatively with a small team towards a common goal.

What kind of work is involved?

We are still gathering candidate projects for the initial round of Skunk Works, but we already have a very wide variety.  Most of the work is going to involve some pretty intense development work, both on the front-end UI and back-end data analysis.  But there are also  projects that will require a significant amount of new design and artistic work.  It’s safe to say that the vast majority of the work will involve creation of some kind, since skunk works projects are by their nature more on the “proof” stage of development rather than “polish”.  Once you have had a chance to prove your work, it will leave the confines of Skunk Works and be made available for public consumption, contribution, and yes, criticism.

How to join

Still interested?  Great!  In order to match people up with projects they can contribute to, we’re asking everybody to fill out a short Wiki page detailing their skill sets and relevant experience.  You can use the SkunkWorks/ParticipationTemplate, just fill it in with your information.  Then send the link to the new page to my (mhall119@ubuntu.com) and I will add you to my growing list of candidates.  Then, when we have an internal project join the Skunk Works, I will give the project lead a list of people who’s skills and experience match the project’s need, and we will pick which ones to invite to join the team.  Not everybody will get assigned to a project, but you won’t be taken off the list.  If you revise your wiki page because you’ve acquired new skills or experience, just send me another email letting me know.

Read more
Daniel Holbach

For me this Ubuntu Developer Summit (http://uds.ubuntu.com) is going to be very special. As always I look forward to meet all you great people again – it’s like meeting “the other party family” again.

Ubuntu Development
A number of development-related sessions are on my list as always and they are going to be very interesting.

We are going to kick off with Ubuntu Development Videos, a session where we’ll discuss how to update our Ubuntu Development videos. This is long overdue, and it might be especially interesting, because I received this very special request on IRC:

<bobweaver> dholbach, if you or others make video tutorial of how to 
            package a updated one I will make video of me shaving my 
            head

Let’s make it happen together! :-D

The next question we’re going to ask ourselves is “What new devs should be doing“. We had some success in the last cycle with proposing a number of categorised tasks to new contributors. Let’s build on that and figure out how we can tell new contributors which tasks they can focus on to have a seamless experience which eases them into our community.

In the last cycles it has become a tradition to look at our Packaging Guide and figure out how to improve it. We are very glad to have received countless fantastic contributions in the last few cycles. This puts us into a great position to provide newcomers with help and with expert up-to-date articles. Here we’ll talk about phasing out the old packaging guide and how to improve our support for translations.

The Developer Advisory Team is alive and kicking and has reached out to many new contributors the last cycle. Still there’s a bunch of things we can improve further. If we want to welcome new folks with open arms and get the best out of their feedback, we need a strong DAT. Help us out.

One thing which never failed to inspire me was whenever work of new contributors was showcased. It’s important because we not only want to show our gratitude by showing off great work done by new people, but also to show others that doing Ubuntu development is no crazy rocket science.

We also plan to have two Ubuntu Development workshops.
Packaging Guide User Testing
Getting Started with Ubuntu Development

New Exciting Stuff
Readers of my blog have probably figured out by now that I got interested in Automated Testing recently. Personally I think it’s one of the best way to be involved in Ubuntu development, because you essentially ensure (theoretically forever) that a given piece of functionality works. To define how we are going to get more people involved in this initiative, let’s meet at the “Automated Testing Community” session.

Also stay tuned for another special announcement with regard to this. :-D

The Community Track
As Jono is busy becoming a father, (All the best man! Big hugs from here!) I will take care of business at Copenhagen and lead the Community track. We have many many exciting things lined up. The Community Roundtables with huge amounts of interesting topics. And sessions about Ubuntu IRC, Ask Ubuntu, juju, translations, Edubuntu, Lubuntu, the Ubuntu Youth team, Ubuntu Accomplishments, more juju, Ubuntu TV, the Ubuntu Data Mining project, the Debian healthcheck, Ubuntu on Air sessions, the Ubuntu Women team, Xubuntu and many other presentations, discussions and meetings. You can very easily see: the Community Track is where it’s at!

One thing I’d like to highlight is the Ubuntu Leadership Mini-Summit because I feel it’s critical to our success as the Ubuntu project that we figure out how we can lead our respective areas of the community efficiently and learn from each other. Drop by and let’s talk.

You can already see: this UDS is going to be quite busy for me, but it’s also clear that it will kick arse. :-)

Read more
Michael Hall

When the Unity developers introduced Dash Previews in Unity 6, I knew it was something I wanted to add to Singlet.  I didn’t have time to get the feature added in time to get it into Quantal’s Universe archive, but thanks to Didier Roche and Iain Lane, I was able to get it into Quantal’s Backports archive before the actual release date, so it will be available to all Ubuntu users right away.

Previews for all!

One of the main goals of Singlet, second only to making it easy to write Unity lenses and scopes, was to automatically add new features to any lenses and scopes written with it.  Previews are my first opportunity to put this into practice.  Singlet 0.3 will add Preview information for any Scope or SingleScopeLens written for Singlet 0.2!  To do this, Singlet 0.3 will use the same image, title and description used in the search results to populate the preview.  This is a big improvement over having no preview at all, and there is absolutely nothing the developer needs to do. Even better, if you have a custom handle_uri method, it will also add an “Open” button to your preview which will call it.

Better, faster, simpler Previews

Getting previews for free is nice, but it does limit the preview to only the information you are giving to the result item.  But the Previews API allows you to do so much more, and Singlet lenses and scopes can take full advantage of them.

The simplest way to add more data to your preview is to add a method to your Scope or SingleScopeLens class called add_preview_data.  This method will be called whenever Unity needs to show a preview for one of your result items, and will be given the specific result item being previewed, as well as a reference to the Unity.Preview object itself.

def add_preview_data(self, result_item, preview):
    if result_item['category'] == self.lens.events:
        url_parts = result_item['uri'].split('/')
        event = self._ltp.getTeamEvent(url_parts[5])
        venue = self._ltp.getVenue(event['venue'])
        if 'latitude' in venue and 'longitude' in venue:
            preview.props.image_source_uri = 'http://maps.googleapis.com/maps/api/staticmap?center=%s,%s&zoom=11&size=600x600&markers=%s,%s&sensor=false' % (venue['latitude'], venue['longitude'], venue['latitude'], venue['longitude'])

The result_item is a Python dict containing the keys ‘uri’, ‘image’, ‘category’, ‘mime-type’, ‘title’, ‘description’, and ‘dnd-uri’, the same fields you added to the results model in your search field. The code above, added to the LoCo Teams scope, sets the Preview image to a Google Maps view of the venue’s location. You can also add additional Preview Actions from within this method.

If you want even more control, you can instead add a method called simply preview to your class, which takes the result_item and the full result_model from your scope, letting you create a Unity.Preview object yourself, and doing whatever you want with it.

def preview(self, result_item, result_model):
    preview = Unity.GenericPreview.new(result_item['title'], result_item['description'], None)
    preview.props.image_source_uri = result_item['image']

    some_action = Unity.PreviewAction.new("do_something", "Do Something", None)
    some_action.connect('activated', self.do_something)
    preview.add_action(some_action)

    return preview

Read more
Michael Hall

Well, we did it.  The six members of the Canonical Community Team stayed awake and (mostly) online for 24 straight hours, all for your entertainment and generous donations.  A lot of people gave a lot over the last week, both in terms of money and time, and every one of you deserves a big round of applause.

Team Insanity

First off, I wanted to thank (blame) our fearless leader, Jono Bacon, for bringing up this crazy idea in the first place.  He is the one who thought we should do something to give back to other organizations, outside of our FLOSS eco-system.  It’s good to remind us all that, as important as our work is, there are still things so much more important.  So thanks, Jono, for giving us a chance to focus some of our energy on the things that really matter.

I also need to thank the rest of my team, David Planella, Jorge Castro, Nick Skaggs and Daniel Holbach, for keeping me entertained and awake during that long, long 24 hours.  There aren’t many people I could put up with for that long, I’m glad I work in a team full of people like you.  And most importantly, thanks to all of our families for putting up with this stunt without killing us on-air.

Upstream Awesomeness

Before we started this 24-hour marathon, I sent a challenge to the Debian community.  I said that if I got 5 donations from their community, I would wear my Debian t-shirt during the entire broadcast.  Well, I should have asked for more, because it didn’t take long before I had more than that, so I was happily sporting the Debian logo for 24 hours (that poor shirt won’t ever be the same).

I wasn’t the only one who put a challenge to the Debian community.  Nick made a similar offer, in exchange for donations he would write missing man pages, and Daniel did the same by sending patches upstream.  As a result, the Debian community made an awesome showing in support of our charities.

All of our donors

The biggest thanks, of course, go out to all of those who donated to our charities.  Because of your generosity we raised well over £5000, with the contributions continuing to come in even after we had all finally gone to bed.  As of right now, our total stands at £ 5295.70 ($8486).  In particular, I would like to thank those who helped me raise £739.13 ($1184) for the Autism Research Trust:

And a very big thank you to my brother, Brian Hall, who’s donation put us over £5000 when we only had about an hour left in the marathon.  And, in a particularly touching gesture of brotherly-love, his donation came with this personal challenge to me:

So here it is.  The things I do for charity.

Read more
Daniel Holbach

So the Ubuntu Community Charity Marathon is in full swing and we are just getting into the 14th hour. We had a number of challenges posted already:

  • Nick is going to write a manpage for Debian for every 5 donations he gets which have ‘Debian’ in the comment.
  • Daniel is going to send patches to Debian for every donation with the word ‘Debian’.
  • Jono is going to shave his beard off if he hits £3000.

This is all very nice and everything, but now we reached a new point in this craziness: Alan Pope, Elvis imitator deluxe pledged to shave off his hair. Shave off his hair. If all of us get more donations in than Jono.

Popey, Elvis imitator deluxe

Popey, Elvis imitator deluxe

An easy fix for the situation above would be for example: if Jono gets 3000 pounds and each of us gets 3001. Tell you friends, help us out. This is going to be awesome and it’s all for a good cause.

Here to help you out:

Read more
Michael Hall

More than a few, actually. As part of our ongoing focus on App Developers, and helping them get their apps into the Ubuntu Software Center, we need to keep the Application Review Board (ARB) staffed and vibrant. Now that the App Showdown contest is over, we need people to step up and fill the positions of those members who’s terms are ending. We also want to grow the community of app reviewers that work with the ARB to process all of the submissions that are coming in to the MyApps portal.

ARB Membership

Two of the existing members, Bhavani Shankar and Andrew Mitchell, will be continuing to serve on the board, and Alessio Treglia will be joining them. But we still need four more members in order to fill the full 7 seats on the board.  ARB applicants must be Ubuntu Members, Ubuntu Developers, and should create a wiki page for their application.

ARB members help application developers get their apps into Software Center by reviewing their package, providing support and feedback where needed, and finally voting to approve the app’s publication.  You should be able to dedicate a few hours each week to reviewing apps in the queue, and discussing them on IRC and the ARB’s mailing list.

If you would like to apply, you can contact the current ARB members on #ubuntu-arb on Freenode IRC, or the team mailing list (app-review-board at lists.ubuntu.com).  The current term will expire at the end of the month, so be sure to get your applications in as soon as you can.

ARB Helpers

In addition to the 7 members of the ARB itself, we are building a community of volunteers to help review submitted packages, and work with the author to make the necessary changes.  There are no limits or restrictions on members of this community, though a rough knowledge of packaging will surely help.  This group doesn’t vote on applications, but they are essential to helping get those applications ready for a vote.

The ARB helpers community was launched in response to the overwhelming number of submissions that came in during the App Showdown competition.  Daniel Holbach put together a guide for new contributors to help them get started reviewing apps, and you can still follow those same steps if you would like to help out.

Again, if you would like to get involved with this community, you should join #ubuntu-arb on Freenode IRC, or contact the mailing list (app-review-board at lists.ubuntu.com).

Read more
Michael Hall

For the past several week, David Planella, Jono Bacon and I have been drafting a spec that proposes a radically different approach to getting desktop applications into the Ubuntu Software Center.  Now, there’s nothing that annoys me more than somebody proposing radical changes for no reason, and without giving much thought as to how it would actually be done.  So I wanted to write down, here, both the justification for this proposal, and the process that we went through in drafting it.

The current process splits submissions between closed-source and commercial apps, which get reviewed by a paid team of Canonical employees, and non-commercial open source apps which are reviewed by the Application Review Board (ARB).  The ARB consists of 7 volunteers from the Ubuntu community, who will review the source code and packaging of each submission.  Members of the ARB are very smart, very dedicated members of the community, but they also have paying jobs, or are pursuing higher education (or both), so their time is a limited resource.  The ARB process was meant to provide an easier route for app developers than the more rigorous process that distro packages must follow to get into the Universe repository or Debian’s archives, and in that respect it has been a success.  But even with eased requirements, there was a limit to how many apps they could manually review.

The recent App Developer Showdown competition, which resulted in more than 140 new apps being submitted through our MyApps portal, showed us the limits of our current process.  We even drafted a number of new volunteers to help review the incoming apps, and Daniel Holbach provided both instructions and programs to help speed things up.  It took us weeks to give an initial review to all of the apps.  Almost two months later and we still haven’t been able to publish more than a quarter of them.  Android has seen over 9,000 new apps in a month, and I can only assume that iOS has seen similar numbers.  If we can’t even scale to handle 140, something has to change.

The spec didn’t get written down all at once from some grand design. It grew organically, from a short list of general goals to the massive text it is today.  In fact, the spec we ended up with is quite a bit different than the one we initially set out to write.  We took our list of goals and started asking the obvious questions: what work is involved, who will it impact, and what could (will) go wrong?  We could have just throw these questions out to other people, but those people are busy and have their own things they are trying to do.  Before we could ask anybody else to spend time on this, we had to put in some effort ourselves.

So we answered as many of these as we could between the three of us, and those answers changed our spec accordingly.  That raised more questions, and we repeated the process, updating the spec and finding more questions that needed to be answered.  In the process we gained both a clearer idea of what we wanted, and a better understanding of how to get there.  By the time we had answered as many as we could on our own, our list of goals had transformed into a longer list of implementation items and who would most likely be doing them.

At that point, we had a more specific direction and a pretty good idea of how much work it would take.  Having done as much of the leg-work as we could, we took the implementation items, and any unanswered questions we still had, and started talking to the people who would have to implement it.  Unsurprisingly, these conversations had an even bigger impact on the spec, and it underwent some pretty drastic changes as we tried to nail down the details of the implementation.  Just like the previous stage, we iterated over this one multiple times until we had as many details as we could collect, and answered all of the questions that we could.  At the end, we had the massive spec we announced today.

But this is just the next stage, the spec isn’t final.  The three of us have answered as much as we could, the teams who will implement it have answered as much as they could, now we’re introducing it the community to gather even more details and answer even more questions.  The feedback we get in this stage will go back into the spec, and very likely generate new questions and feedback, and we’ll iterate through this stage too.

The final spec, whatever it ends up being, isn’t going to be perfect, and it’s not going to make everybody happy.  But we can be confident that is will be a very well thought out spec, it will be a very detailed spec, and it will allow us to accomplish the goals we set out to accomplish at the beginning of it all.  It will help make Ubuntu a much more attractive platform for application developers, it will make Software Center more useful to developers and users alike, and it will make Ubuntu a better OS for all of our users.

If you have any questions or comments on the spec itself, please send them to the ubuntu-devel mailing list, not the comments section here.

Read more
Michael Hall

As you’ve probably heard already, Ubuntu is running an App Developer Showdown competition where contestants have three weeks to build an Ubuntu app from scratch.  The rules are simple: It has to be new code, it has to run on Ubuntu, and it has to be submitted to the Software Center.  The more you use Ubuntu’s tools, the better your chances of winning will be.  This week we ran a series of workshops introducing these tools and how they can be used.  It all seemed like so much fun, that I’ve decided to participate with my own submission!

Now 2 our of the 6 judges for this competition are my immediate co-workers, so let me just start off by saying that I will not be eligible for any of the prizes.  But it’s still a fun and interesting challenge, so I’m going to participate anyway.  But what is my entry going to be?  Well in my typical fashion of building tools for tools, I’ve decided to write a GUI wrapper on to of Quickly, using Quickly.

Before I started on any code, I first wanted to brainstorm some ideas about the interface itself.  For that I went back to my favorite mockup tool: Pencil.  I knew I wanted to cover all of Quickly’s functions, both for creating projects and working on them afterwards.  I also wanted something that would keep track of my projects, so I wouldn’t have to find where they are on my disk whenever I wanted to hack on them.

Now, I’ve never been a fan of GUI builders.  Even back when I was writing Java/Swing apps, and GUI builders were all the rage, I never used them.  I didn’t use one for Hello Unity, and I wasn’t planning on using Glade for this project either.  But after Jono’s fantastic workshop session about Glade, I decided to give it another chance.  I found that I was able to get a basic UI built and running in very little time.  I’m still struggling with some, and there’s a point where you need to switch from Glade to code, but all in all it has saved me a significant amount of time.

Quickly also saved me a large amount of time, both in creating the project and adding things too it.  Being able to add an Application Indicator to your app by just running “quickly add indicator” is amazing.  From there is was a simple matter to build a menu based on available Quickly commands and tie them in with callback functions.

But the part I like the best about this app so far, is that it’s useful even when you’re not using it.  Most of the time you spend developing a Quickly app is going to be in some other application, such as your code editor of choice, Glade or something.  Thanks to Unity’s HUD, and the fact that it’s smart enough to check Indicator menus in addition to the focused application’s menus, you can call your Quickly commands any time, simply by tapping ‘Alt’ and the command you want to run.  It’s like having Quickly integrated into all of your other tools.

And thanks to the developer tools available in Ubuntu, I was able to accomplish all of this in only a few hours of work.

Now it’s very, very far from being complete.  For instance, the “active” project is hard-coded to my quickly-gtk working directory, it can’t start a project yet, or support commands that take optional arguments or user input.  But in a short amount of time I was able to go from a mockup to a working layout and even some functional code.  It even packages successfully, something I found out quite by accident when I selected “Share” from the indicator menu and ended up with a package in my PPA.

Building an app in 4 hours then accidentally building a proper package and uploading it to a PPA, who’d have thought we’d ever make it that easy?  I hope you all are having as much fun and success in your showdown applications as I am.

Read more
Michael Hall

Last week we introduced a new ‘Download for Ubuntu’ campaign for upstreams to use on their websites, letting their users know that the app is available in Ubuntu already.  We event generated a list of targeted upstreams we wanted to reach out to in order to spur the adoption of these buttons.  What we didn’t go into much detail about why upstreams should use them.  I hope to remedy that here.

It’s easy

Let’s just get that out of the way, this won’t take a significant amount of work on the part of an upstream.  It’s just a one time change to a website.  You don’t even need to change it every cycle, since the buttons point to the App Directory entry for the application itself, not any specific version of it.

It makes installing your app more appealing

The button isn’t just another way of getting your app, it also tells the user that it will install correctly, all of it’s dependencies are available and will be installed, everything is configured to work with their system, and they will get be getting updates and security fixes to it through a mechanism they already use and trust.  In short, it’s a promise of a good user experience (which I’ll admit we don’t always live up to, more on that below).  Telling 20 million users (and growing) that your app is safe and easy to install is surely worth a few pixels on your website.

It’s good social exposure for your app

By sending users to the App Directory, instead of just immediately installing, new users get to see what others are saying about your app through the ratings and reviews (which will be mostly positive, because your app is awesome right?)  of other Ubuntu users.  Not only does this tell your users that other people like your app, but it’s also telling them that they can add their own ratings and reviews, which will in turn boost your app’s standing.  More reviews leads to more users, which leads to more reviews, it’s a great positive feedback loop.

Users will be looking for it

Not right now, obviously, since we just started this campaign.  But as more upstreams adopt the new button, it’s going to be one of the first things Ubuntu users will be looking for on your website (for all the reasons mentioned above).  With a majority of website visitors leaving in less than a minute (according to a lazy Google search), the promise of a quick and easy install might just be the difference between a new user and a lost opportunity.

This campaign benefits everybody: end users, upstream developers and, yes, Ubuntu too.  So let’s improve these ties, together.  If you’re an upstream, you can copy/paste the following HTML snippet directly into your website (replacing {{pkgname}} with the name of your application’s package in Ubuntu).  If you want to reach out to an upstream developer, please add them to our list so we know who’s contacting them, and what the status is.

<a href="https://apps.ubuntu.com/cat/applications/{{pkgname}}/">
 <img src="http://developer.ubuntu.com/wp-content/uploads/2012/06/downloadonubuntubutton.png"  title="Download for Ubuntu" alt="Download for Ubuntu button" width="122" height="49" />
</a>

Now I know we can’t always give the best user experience possible (see, I told you I’d get to that).  Sometimes our packagin isn’t quite right, or the default configuration of your app is sub-optimal.  Our six month release cadence and package freezes mean that rapidly developing applications will often be out of date in our main repositories.  We’ve taken on a lot of work by distributing apps the way we do, and even though we’re a very large community, it’s still hard to get every package right.  Luckily, you’re not powerless here, if you spot problems with the way we distribute your app, or you need to get a newer version out to Ubuntu users, you can do something about that.

Package fixes

Even though our process locks applications to the version in the archives for that particular release of Ubuntu, we will still allow changes to the packaging itself.  So if we’ve done something wrong on our end that is giving your app a hard time, we’ll fix it and make that available to all of your Ubuntu users as a Stable Release Update.

Backport newer versions

A six-month release cycle means that every Ubuntu release has relatively up to date versions of applications, at least compared to distros that have a longer cadence.  But for rapidly developed applications, where new versions come out more frequently than that, this means their packages can become outdated quickly.  And with the five year lifetime of our LTS releases, most packages will get to be stale by the end.  That’s why we have a special repository just for backporting new versions of packages to stable releases of Ubuntu. And starting with 11.10, this repository is enabled by default.

In order to have your application backported to a stable release, it first has to be accepted into the current development release.  If your new version was in Debian’s unstable repository at the beginning of the development cycle, chances are it’s already there.  If it’s not in Debian you’ll need to submit your package to be included in the development release.  Once it’s there, you can request that it be backported to one more more stable Ubuntu releases.  You can use the requestbackport command line tool (from ubuntu-dev-tools package) to automate much of the process, or if you’re not running Ubuntu simply file a bug to start the request.

Read more
Michael Hall

It’s no secret anymore, we want apps in Ubuntu.  Big app, small apps, shiny apps, cute apps,  apps that play a catchy tune while avian avengers explode porcine poachers.  You name it, we want it in Ubuntu.  And we need your help getting them.

It doesn’t matter if you’re not a programmer, there are plenty of programmers in the world, and they’re making all kinds of really cool apps that you want, that I want, that we all want.  But they’re not putting them in Ubuntu, and that’s why I need your help.

You see I’m just one person, and with David Planella we’ve got, well, two people.  Now, two people can find an awful lot of apps on the internet, that’s true.  Especially when that’s part of your job.  But even still that would hardly amount to a drop in the bucket of apps that have been made.  And we’re not happy with just a drop in the bucket, are you?

No, of course you’re not.  So right about now you’re probably thinking of a bunch of cool apps you’ve used or seen or read about recently (and if you weren’t before, you certainly are now, aren’t you).  And you may be wondering how you can help us get them into the Ubuntu Software Center.   Well wonder no more my friend, because we have a Trello board.

Not terribly impressive, I’ll admit, but it is terribly useful.  You see, David and I will be contacting each and every one of these app developers about submitting their apps to the Software Center, and moving the card from column to column as that conversation progresses.  And while we have a nice long “To Contact” list right now, it’s not going to stay that way without your help.

We’re opening up this board to anybody who wants to add new upstream apps for us to contact.  All you need to do is follow David’s instructions on this wiki page to get started.  It’s quick, mostly painless, and best of all you get to start telling us what to do (at least a little bit).

But wait! There’s more!  Didn’t I say we were just two people?  There’s no way we could contact all these upstreams on our own.  And hey, you’ve just signed up to join the Trello board (you did do that, right?), which means you can start contacting them too, and moving their cards, and make Ubuntu even better.  We’ve even created a reusable email template that you can use for that initial contact.

If you contact one of the app developers, make sure you move their card to the “Conversation Started” column, assign it to yourself, and add comments about who you contacted and any other relevant information.  This of course requires that you joined the board, which you definitely should do if you are going to be working on this.  And please note that is says “Started”, not “Finished”.  Once you contact the developer, keep that line of communication open and help them through the process of submitting their app.  If you get to a point where you can’t help them, let David or I know and we’ll be happy to pick it up.

Read more
Michael Hall

With the Ubuntu TV port to Unity 3d currently underway, the project team is looking towards future feature development and they want the community’s input on what the product should do.  Specifically they are gathering a list of use cases that consumers might want in a Smart TV in five key areas:

  • Local/networked media
    • How should Ubuntu TV interface with media on the local device or local network?
  • Online media
    • How should Ubuntu TV find and play online media?
  • Control from another device (smartphone, tablet etc.)
    • How can you use your existing phone or table to interface with your TV?
  • Broadcast (LiveTV, PVR)
    • How should Ubuntu TV list, store and playback live TV?
  • Applications
    • What types of applications would be useful on a TV?

So here’s your chance to get involved and be heard, go to this wiki page and start adding your use cases to the list.

 

 

Read more
Michael Hall

Expanding on my previous post calling for pkgme backend contributors, here’s a list of the backends we would like to see added, and who in the community you can contact for help in making them. If you can act as a mentor for one of these backends, please say so in the comments and I will add your name to the list.    For any questions about pkgme itself, and what options are available to backends, your best bet is to ask James Westby (james_w) in the #pkgme channel on freenode.

Qt/qmake

QMake is a Makefile-generator. It uses information that the application author puts into a project file to build the Makefile for a project. A qmake backend would need to either use qmake to extract the information requested by pkgme, or parse the same project file that qmake uses in order to provide that information.

Information about qmake: http://qt-project.org/doc/qt-4.8/qmake-manual.html

Help Contact: Angelo Compagnucci

Flash

Flash applications can be packaged for Ubuntu by wrapping them in a GTK window that contains a Webkit browser widget, and an index.html file for it to load that embeds the given flash file.

The Quickly Flash template currently does much the same thing. To do the same in pkgme, you will need to pass the necessary wrapper files to the extra_files request. extra_files should return a JSON object where the key is the file path relative to the root of the target application, and the value is the contents of that file.

Help Contacts: Michael Terry and Stuart Langridge

HTML5

A backend for an HTML5 application would also require wrapping the target application in a GTK window with embedded Webkit widget. Only instead of creating an index.html, you would just point the Webkit widget to the target application’s HTML files.

Help Contact: Didier Roche

Java

The Java backend would need to parse ant’s build.xml files to extract information about the target application or an already built jar file’s manifest.

Help Contact: James Page

Read more
Michael Hall

pkgme is a small utility created by James Westby, its purpose is to create a Debian package for any unpackaged applications.  It’s currently used when applications are submitted through the Ubuntu Developer Portal as tarballs, inspecting the contents of the application to determine how to build a package from it.  In order to support many different types and configurations of application, James built pkgme to support any number of different backends.

Currently there is support for apps using Python and Distutils, apps compiled by cmake, and apps written in Vala.  But there are still many, many applications out there that aren’t covered by these backends, including Qt apps, HTML5 apps, Flash apps and more.  That’s where you, dear contributor, come in.

UPDATE: Here is a list of desired backends and mentors to help you with them.

But I don’t know how to create packages!

That’s okay, you don’t need to know how to make packages to create a pkgme backend.  It already knows how to make packages, what it doesn’t know is where to find the information it needs to do that.  This is what backends are, just one or more small scripts that extract enough information about a project to let pkgme do its thing.

Ok, I’m interested, how do I start?

First of all, get a copy of the latest pkgme code from its bazaar branch in Launchpad:

bzr branch lp:pkgme ./pkgme

Then, create a VirtualEnv environment to install it into:

virtualenv ./env

Then, install it into the Virtualenv:

source ./env/bin/activate
cd ./pkgme
python setup.py develop

Now you’ve got a working pkgme installed and running in your virtualenv. You can leave your virtualenv by running ‘deactivate’.  Time to get started on your backend!

Where do I put my new backend code?

Since we’re going to submit your new backend to the pkgme branch, we can just create it there:

cd ..
mkdir ./pkgme/pkgme/backends/<your backend name>

Great, now I have an empty Backend, what do I put here?

The first thing your backend needs is a ‘want’ file.  You see, in order for pkgme to know which backend it should use on any particular application, it needs to ask every backend how much they want it.  It does this by executing a script named ‘want’ in each backend.

Your want file is executed from the target application’s directory, so in your script ./ will be the root of the target application’s directory.  This lets you script easily browse through the files in the application to determine how well it can provide packaging information for it.

In order to tell pkgme how much your backend wants to handle the target application, your ‘want’ file simply needs to print a number to STDOUT.  The backend with the highest number is the one pkgme will use.  These are the suggested ranges for your ‘want’ value:

  • 0 – no information can be provided about the project (e.g. a Ruby backend with a Python project).
  • 10 – some information can be provided, but the backend is generic (e.g. Ruby backend).
  • 20 – some information can be provided, and the backend is more generic than just language (e.g. Ruby on Rails backend).
  • 30 – some information can be provided, and the backend is highly specialized.

Now I have what I want, what do I do with it?

Once pkgme has chosen your backend to use against an application, it will call one or more scripts from your backend to get information about the application.  As the backend author, you can choose to provide separate scripts for each piece of information, or you can provide just a single script called ‘all_info’ that will provide everything.

Lots of scripts

For separate scripts, you will need to provide an executable in your backend directory for each of the pieces of information that pkgme might request.  Each script should print that information to STDOUT, or exit with an error if it can not provide it.

Just one script

However, if looking up bits of information one at a time is a time-consuming task for your backend, you can do it all in one shot.  If you want to do that, then the only script you need is one called ‘all_info’.  When this script is called, it is also given a JSON list on STDIN.  This list contains the keys for all the pieces of information that pkgme needs from your backend.  As output, this scripts needs to print a JSON dictionary to STDOUT.  This dictionary should contain a key for each of the fields sent as input, along with its corresponding value.  If your backend can’t provide a value for one of those fields, it should be left out of the dictionary.

You can test your new backend by switching to the directory of a project your backend is made to support, and running:

pkgme

Make sure your virtualenv is still activated, or pkgme won’t be found. If everything works, you should have a ./debian/ directory in the application’s root folder.

Hurray, my backend works.  Do you want it?

Of course we want it!  What a silly question.  And it’s already in your local branch of pkgme too!  Well, it’s in the directory anyway, you still need to add it to the workingset:

cd ./pkgme/pkgme/backends/
bzr add <your backend name>

Then commit your changes and push them back to Launchpad:

bzr commit -m "Added backend for <your backend name>"
bzr push lp:~<your lp username>/pkgme/add-backend-<your backend name>

Then head on over to https://code.launchpad.net/pkgme, click on your new branch name, and then click the “propose for merging” link.  Fill out the description of what your backend adds, and submit it.  From there it will get reviewed by one of pkgme’s maintainers, and either get merged into the main branch, or sent back to you for fixes.

Read more
Timo Jyrinki

A couple of photos from the Ubuntu release fest in Tampere yesterday.

People gathering up before presentations

Tieto's Markus Mannio

Again, continuing on how Ubuntu is used at Tieto

A cut to the end of presentations, Trine 2 game licenses from Frozenbyte being raffled. A great game available on Linux.

Tablets running KDE Plasma, and Ubuntu for Android being demoed.

Someone else probably has photos of my generic Ubuntu 12.04 LTS presentation (what's new, what's next), and likewise for the other presentations (Ubuntu for Android, uTouch) held. Those will be available as slides and videos later on, although do note the whole event was in the crypto-language called Finnish.

Thanks to the organizers, sponsors and everyone I met, it was a great event with nice little dinner and wine served at the end!

Read more
Timo Jyrinki

Ubuzen in the Bay Area

Enough said.


You can reach me most probably at the UDS on the Oakland side, and most directly via IRC if you don't see me.

Edit: Launch!

Read more
Michael Hall

My big focus during the week of UDS will be on improving our Application Developer story, tools and services.  Ubuntu 12.04 is already an excellent platform for app developers, now we need to work on spreading awareness of what we offer and polishing any rough edges we find.  Below are the list of sessions I’ll be leading or participating in that focus on these tasks.

And if you’re curious about what else I’ll be up to, my full schedule for the week can be found here: http://summit.ubuntu.com/uds-q/participant/mhall119/

Read more
Michael Hall

Ubuntu 12.04, the Precise Pangolin, is scheduled to be released in a little over a week.  This is a very exciting release for us, not only is it an LTS release with 5 years of support, but it also brings some major improvements to Unity and other areas of the desktop.  It’s also going to see a very big focus on independent application developers.

Developers, Developers, Developers!

During the last six months we’ve spent a lot of time building tools and documentation for app developers.  In September of 2011 we launched the Ubuntu Developer Portal, a site dedicated to helping application developers target the Ubuntu platform, and for getting their applications distributed through Ubuntu.

The developer portal provides all the information an app developer needs to write apps for Ubuntu.  It will get you started with tools like Quickly, tell you what languages, toolkits and IDEs are available, and introduce you to the tools and workflows that make developing for Ubuntu a joy.

Once your app is ready, the Developer Portal will walk you through packaging it and submitting it to be published in the Ubuntu Software Center.  The MyApps section lets you upload and manage all your applications, provide branding and screenshots, and set your purchase price.

Going Native

In the past couple of months we’ve added extensive documentation on Unity integration, which allows your application to become part of the desktop experience.  The Unity APIs give your application a presence in multiple areas of the desktop, letting you to add extra information to the Launcher, indicators in the panel, search results in the Dash and more.

All about the Apps

Everybody knows that “Apps” are the big thing now.  No longer relegated to tablets and smartphones, “App Stores” are coming to both major proprietary desktop operating systems as well.  The Ubuntu Software Center already supports independent free and paid app downloads, and with 12.04 we want to grow that segment exponentially.

Not only do we provide a rich platform for app developers to target, we also have the means of delivering those apps directly to over 12 million users worldwide.  With Unity, your app isn’t just visible in the Ubuntu Software Center, but we put it right in the Dash!  Your app will show up whenever the user searches their system for something similar, giving it a level of visibility that no other platform offers.

Join the conversation

Developing applications for Ubuntu doesn’t have to be something you do in isolation.  Having a strong community is an important aspect in today’s software market, and Ubuntu provides you with the tools for collaborating with the existing Ubuntu user community and for growing a strong user community around your own application.    These users can help grow your app by add translations, identify bugs, and even submitting patches.

We’re also building a vibrant community of app developers, and we want you to be a part of that.  Learn tips and tricks from other app developers, share your own expertise and build professional connections.  Here you will also find a number of Ubuntu and Canonical developers who will take your suggestions and feedback for making app development on Ubuntu even better.

Read more
Michael Hall

Hello Unity is now open for translations!

Please help me make this technology showcase is available to application developers in your native language.  Translations are done through Launchpad, and will be built into the Hello Unity package.

Read more
Michael Hall

When the topic of contributions to FOSS come up, it usually happens that people focus entirely on the aspect of creation, specifically code creation, to the exclusion of all others.  In the context of software, this makes a certain amount of sense, since the primary product is the code itself, either in source or binary form.  Even the more broadly-focused, who make a point to expand their definition to include things like documentation and artwork, will still focus exclusively on the creation of those works.  And yet perhaps the single biggest factor towards increased creation of code is in the distribution of what is being created.

There are a number of reasons for people to write new code.  We often talk about a developer “scratching their own itch”, but other times it can be a matter of personal improvement, monetary gain, or even just plain fun.  While there are many reasons to write code, there are not so many reasons for releasing it under a Free or Open Source license.  By choosing such a license, the author explicitly wants his or her creation to be used by others, as many others as possible in fact.  The use of their creation is what motivates them, and it stands to reason that the more it is used, the more motivating it becomes to create.  The underlying reason why this is motivating can vary, but the fact is that creators of FOSS are motivated by the use of FOSS, and the more users there are, the more motivation there will be for creating it.

The number and variety of potential consumers of FOSS is larger than any single developer can hope to reach.  Even a group of developers, even a large group of them, will find it impossible to make their creations available to the widest possible audiences.  And the more effort they put into making their creation available, the less time and resources they have to put back into creating new things.  Likewise the smaller the pool of potential consumers, the less reason developers have to improve on or create something in the first place.  But by choosing an open source license, developers separate the work of distribution from that of creation.  The desire for their creation, then, will naturally lead to a much larger number of individuals and groups bringing these creations to the people who want them.  More importantly, by focusing exclusively on the task of distributing, these new groups are able to afford not just one project, but a multitude of projects, with an increase in the consumption of their creation.  And with an increase in consumption, it is reasonable to expect an increase in contributions.

The default application selection for each Ubuntu release is often the subject of much discussion and advocacy.  People called for the inclusion of Banshee long before Ubuntu made the switch.  It’s unimaginable that people who like a project and appreciate it’s developers would actively seek to have it used by an organization that contributed nothing back.  Likewise when it was announced that Ubuntu would switch back to Rhythmbox, those same advocates genuinely believed that they had lost something, again something unimaginable if they weren’t gaining something valuable from the distribution.  When PiTiVi was selected as a default application, advocates for Openshot made a very strong case for why their preferred application should be included, again because they knew that the project would gain something of value from the increased distribution.  The same happened with F-Spot and Shotwell, with the removal of the Gimp, the various boot splash systems, and more.  I can only assume that the same happens in other distributions.  The only reason why this would happen is if, whether consciously or not, people see a real value, as real as the value of code contributions, in being distributed as widely as possible.

By relieving the developers of the need to put resources into distribution, distributors allow them to create more using the same commitment of time and resources.  Likewise, by increasing the number of people who will be using it, the distributors multiply the motivating value, whatever it may be, that the developer gets in return.  And as the motivation for creating increases, the number of people who participate in creating also increases.  In this way, every distributor of Free and Open Source software contributes towards increasing the total number of creators and creations (including lines of code written), and they do so in direct proportion to the expansiveness of their distribution.

Read more