Ubuntu Studio, new leadership, and future plans

Over the recent year, while Scott, our project lead, was finding himself having less and less time over for the Ubuntu Studio project, I kind of went in the opposite direction, becoming more and more involved in the development process. So, now that Scott has announced he will be stepping down, there couldn’t be a more suitable time for me to step into his shoes.

For those that don’t know me, I’m Kaj Ailomaa, a musician, with a great interest in computing, using puredata a lot for my own projects, and of course, I’m greatly passionate about free software. I started out using Ubuntu Studio at around 8.04, and have been hooked ever since.

As I don’t have a formal education in software development, there have been many hurdles that I’ve had to get over during the process of wanting to contribute to Ubuntu Studio. I recently became a member of the Debian Multimedia Team, as a part of my strategy to get involved in all of the parts of the development process, and I also have future ambitions with my involvement with Debian, which I feel very strongly about.

I do some coding, enough to read and be able to patch code, but my main goal will be to focus on organizational aspects and future goals for Ubuntu Studio and Debian.

Scotts’ Legacy

Move to XFCE

Scott has made a great job of leading Ubuntu Studio through some big changes. As when Unity came along, and we suddenly weren’t at all sure which way Ubuntu Studio should take. The choice fell on XFCE, and from what I’ve seen, this has been greatly appreciated in the community of Ubuntu Studio users. At the time it seemed risky to use any of the new desktop systems, such as Unity or Gnome3, when not being able anticipate usability issues. XFCE somehow became the obvious choice, as it most resembled gnome2, which our users were already comfortable with.

Xubuntu devs were a big help during this transition, and still are, as we based the desktop on Xubuntu. During that same process, Ubuntu Studio became a live DVD, which added new functionality that didn’t exist before. Being able to do most workflows from the live DVD directly, without the need to install was a great addition.

Defining workflows

Further, Scott put a lot of emphasis on making Ubuntu Studio easy to use, for new users particularly. And, was the driving force behind us establishing clearly categorized workflows, which right now are best reflected in our custom menu.

This has led us to develop the ideas further, and Len who has been mostly involved in applying and designing the custom menu, has also been working on a panel based on these ideas. As one of our goals is now to try increase our team, we’ll be looking to find someone who would like to help us code workflow management tooling.

Len and I have also been looking at freedesktop categorization, and our plans it to see if we can expand or improve it for our workflows, and work with upstream developers and packagers to set new standards for all Debian derivatives. This will make sense for menu-less desktop systems as well, as it will make it easier for people to find the apps they are looking for, with a bigger variety of sane categories for multimedia applications.


Documentation, Team Organization and getting more contributors

During the past months, I’ve spent quite a lot of time on team organization and development documentation This might seem like a weird thing to do, when our team is so small, but what I’m aiming for during the next two cycles is to grow our team, by actively calling for help on different medias and social sites. I’m aiming high, and preparing for it.

A classic problem with few members in a team is that information is all gathered between the team members and not in writing, and for new participants it can be a real challenge to get an overview of what is going on. With a good organization, and plentiful documentation, it should be easier to make new contributors orientate themselves, feeling there’s less of friction in getting stuff done, etc.

And, we’re just like most other distros, looking for all skill levels, not just coders. Coding might actually be the smallest task we do in the end.

I realize there are good resources already out there, and really, this process is not only about gathering the docs, but also learning about all the procedures, to be able to mentor any new participant correctly.

Jack and group policies

There is a problem with jack and realtime privilege, that I would very much like to solve once and for all, preferably across all Debian based distros.

Debian and Ubuntu have different policies with group management, and as the current jack packages depend on the audio group, we should look at trying to change the policy for realtime and multimedia applications and devices. This simply needs to work, just by installing the software you want to use.

Perhaps we need to add new groups, or change how realtime is achieved, as well as how we get access to firewire devices. In any case, it needs to be fixed, one way or the other.

New release manager

We would benefit from an improved testing procedure during the development cycle. Many bugs slip by our fingers, which could have very easily been caught, and also fixed early in the process.

Testing and active bug reporting/fixing is something that always could be improved. If we in deed get more people involved, this area of development would greatly benefit from a bit of organization, documentation, and scheduled testing.

Luckily, we have  Howard Chan, who is now our Release Manager. And, though we don’t want to keep him too much from his school duties, his drive in managing testing and making releases is truly a great help to us.

Public relations

ttoine and holstein are both continuously being helpful, holstein on the IRC channels, giving user support and picking up problems that occur for our users, and ttoine, who is active with out public relations, lately begun a process of getting and selling merchandise.

ttoine also recently interviewed one of the most prominent people in pro audio development, and will publish an article about that shortly. Public relations is something that we also should try to increase, and the more who are contributing, the better. We simply need an active community.

New Artwork Lead

We recently got a new addition to our team with madeinkobaia, who is now our Art lead. He’ll be leading the artwork design for us, and has already whipped up some really nice banners for our social sites. It will be exciting to see where we end up with that.

Gui control tool

For 14.04, or earlier, I really would like to see us adding a gui tool for setting system configs, mainly for audio. Some would like to easily be able to do things like disable PA, or run jack by default as the main audio server.

If group administration is not solved yet, the tool could also handle that. This, and the inclusion of a system startup check script, for making sure the system is fine for multimedia. There’s already a lot of effort done on this, but no finished application.

A developer who has been quite close to Ubuntu Studio development, known as falktx on IRC, has been working on a similar tool, so we’ll of course want to look at the possibility of including his.

Final Release

Currently, I’m planning no further ahead than 14.04. I’ll try to aim high, but we’ll just need to see where we land.


/ Kaj Ailomaa

Future Ubuntu Studio changes

The first UDS (Ubuntu Developer Summit) of the year has just started. It’s now an online event, held every three months, where Ubuntu developers and contributors meet and discuss future development goals.

UDS used to be a physical event, held every 6 months, just after a new release of Ubuntu. Traditionally participants is a mix of Canonical employees, sponsored participants, and volunteers. It’s free and open for anyone to attend. Usually at least the project lead of each of the official Ubuntu flavors would attend. In October I attended when it was held in Copenhagen, and the year before, in US, Scott Lavender, the project lead of Ubuntu Studio attended.

Many things are being discussed during UDS that might radically change how Ubuntu Studio, and other community Ubuntu flavors will be developed and supported in the future.

Moving Towards Rolling Release?

One of the major topics for this UDS is the discussion on whether or not Ubuntu should start using the rolling release model. The LTS(Long Term Release) will still continue, as Canonicals clients value that,  while the interim release is proposed to be dropped.

Many ideas are floating around how to make this work. So far, northing’s conclusive, but it seem sto me, reading mail lists and such, that many people want it to happen, even if this does cause quite a bit of disturbance among flavor developers, who have been planning for a release in April for the last six months.

X Window to be replaced by MIR

Many things were announced at the same time, and while the rolling release is still up for discussion, it seems that the move towards replacing the X window system with MIR is already decided. Of course, at this point nothing is for sure, since MIR still needs to be developed, and the change will not come instantly. The goal is for a full change by the release of 14.04 LTS.

This will be a huge change for the community, as it means either all of the desktop systems on Ubuntu will need to support MIR, or the current X window system will need to be fully supported by the community developerst, since Unity – the Ubuntu desktop system will not be using X, and thus, they will not be supporting it.

What will this mean for Ubuntu Studio?

Right now, we don’t really know. In many ways, Ubuntu Studio itself is quite flexible, as we do not actually depend on any specific windowing or desktop system (as long as our applications are able to run on it, though we prefer to stay with XFCE), and our main concern about the rolling release is really just will it be stable enough for users? Some of our users don’t need anything but a LTS, but that is a minority of our users. A potential rolling release will be our main release, and it needs to be good and usable.