Reading Amber Graner’s post about Tuesday’s meeting of the Community Council, I recognised a feeling that I also had when I stopped being an active member of the community in January this year. At that time I felt depleted of the enthusiasm for the community that once flew through my veins. What made my enthusiasm go away?

Apart from changes in my personal life, I was also affected by a sense of purposelessness. I had no idea what I was doing in the community anymore, so I just quit. I feel that this is a general problem in the community. A successful and happy community needs something to do. It needs a responsibility, something it can focus on. For the greatest part of the five years that I have been an active part of the Ubuntu community, I felt part of a group that was working together on creating the best distribution. There was a clear goal: making the best operating system of them all.

The difference with today is that the primacy of innovation, of change, appeared to be much more in the community back then. We were all excited about the upcoming changes and the direction we were heading towards, because we all knew what those changes and directions were. For people to be excited about something, they need to know what to expect.

Ubuntu has matured enormously. Canonical has acquired so many skilled people that I do not fear for the quality of Ubuntu. It is only going to be better. However, that maturation has come with a price: as Canonical moved more and more to an Apple-style secrecy surrounding its plans, the community has been robbed from the vital basking in the glory of the upcoming changes. Because of the way the plans are announced, the community also doesn’t always feel them to be theirs.

Is this a bad thing? Not necessarily. I believe that Canonical’s approach will probably lead to better designs. However, the atmosphere in the community needs to be improved if we want to keep everyone motivated and give the people a sense of purpose. Currently, the responsibility of the community is quite uncertain. On the one hand, Canonical makes it appear in its communications that the community has more influence than it actually has. It says that all employees are community members, whereas many are in fact not. It decides many things on its own, but then says it involves the community. But Canonical seems to steer the Ubuntu project on its own.

I do not disagree with the way Ubuntu is run. However, I do believe that it is vital that the truth is not denied, like the political ‘leaders’ of Europe currently do when talking about Greece. Saying that Ubuntu is created by the community does not make that true. Stop it. Honesty will improve a lot, because it will reduce unrealistic expectations.

With the fallacy of the community running the project removed, the community does need something to replace that. To return to the beginning of my post, what I believe is causing the leadership lethargy that was mentioned in the Community Council, is uncertainty about the responsibility of the community. It should be made clear exactly what role the community plays in creating Ubuntu. What decisions can it make? What can it contribute? What is the reach of the authority of the Community Council over the project? Once that is clear, the roles of the different leaders can be defined within that responsibility. Then they know what their purpose is. Having a purpose, having influence motivates people.

Somewhat related: maybe it would be a good idea to make in every team somewhat responsible for community and contribution management. For example, if you as a community volunteer contribute code to the desktop, who will look after you? Who will make sure that your work doesn’t go to waste? Such a change would also take of stress from the shoulders of the community team, which should not be used for such wide purposes.

When I started writing this post, the latest bug report on Launchpad was bug #820459. That’s right, since the start of the Ubuntu project there have been 820,459 bugs reported on Launchpad and its Ubuntu Bugzilla predecessor. Though it includes bugs reported against other projects on Launchpad, the majority of those bug reports are related to Ubuntu.

The number of bugs reported every day is huge. It’s a continuous flow of problem reports, Apport crash reports, wrongly placed support requests, trolling, feature requests and distress. Heroically fighting to stem the flood is Ubuntu Bug Squad. Together with specialised bug triage teams for certain packages, like the kernel, they try to process as many useful bug reports as they can. However, there are too little triagers for too many bugs.

The current situation is not good for the people who work so hard to process all the reports; many leave the team soon after joining. It also causes relevant bugs to be lost in a sea of unprocessed or half-processed bogus bugs that clog up the system. It has been proposed before, but maybe we should once again seriously consider discouraging non-technical users from reporting bugs.

If we’d decide to do so, regular users would be kept away from the bug tracker. Only for automatically generated crash reports from Apport should be allowed, because the process is such that bogus reports rarely happen and many triage steps for this particular kind of bug can be automated. We would remove the ‘Help->Report a bug’ everywhere, including alpha releases. Links to reporting a bug should be removed from the documentation and the official sites. Launchpad could be adapted to make the ‘Report a bug’ button less obvious.

All this should lead to less bug reports and a higher average quality of the reports. If we focus only on the technically capable and interested users, then we’d have less clueless reports. It would save the time, energy and motivation of the bug triagers, which could then focus on making sure every bug that would be reported, would be processed quickly.

However, we should not forget that one of the things Ubuntu often is credited for is the large amount of bugs forwarded to upstream. Furthermore, an even more important argument in favour of bug reporting for the masses, is the fact that technical users use their computer different than non-technical users. They might miss bugs that non-technical users do encounter or see no problem in a feature of the system that is terribly confusing for non-technical users.

Limiting bug reporting would deprive us of this and that seems sufficiently bad to me to doubt whether we should limit bug reporting at all. I really don’t know what’d be the best. Making it harder to report bugs would make managing the bugs easier, but wouldn’t that also make the bugs we manage worth less? What do you, oh dear reader, think?

Watching the news of Apple’s release of OS X Lion and the cheering reviews that followed, the huge quality of what we are up against becomes very clear once more. If you look at the operating system that Apple is delivering, you see not only the polish that it is so famous for. It also delivers functionality underneath that polish. You can make your operating system as user friendly as you want, but you will still lose if you cannot do much with it.

The large success of Ubuntu we’ve seen in the recent years has come mostly due to the fact that Canonical is very good at adding polish to the functionality that was already there. It made the great tools of the free desktop software usable by everyone. They still do this wonderfully and I have full confidence that the Canonical Design Team will continue to make Ubuntu suit its users even better.

Now, I don’t mean this in a demeaning way. I have great respect for the vision that speaks from Unity. However, I would like to emphasise that working within GNOME would be much better for Ubuntu on the long-term, no matter how hard it will be in the short-term.

When comparing Unity and GNOME Shell, I noticed right away how clearly a philosophy speaks from GNOME Shell. When using GNOME 3, you can really notice how its developers have purposely worked together to create a coherent experience. It feels nicer than Unity. Plus: it uses GNOME technologies and that improves its integration in the rest of the desktop tremendously.

But after a while you start noticing a few things. GNOME Shell is less stable than Unity and it feels less solid and responsive. Moreover, whereas Unity’s rough edges are at its rough edges, GNOME Shell has rough edges spread equally all over. GNOME 3 looks less slick and sharp than Unity, GNOME 3’s default theme is less crisp than Ubuntu’s Ambiance.

It is a terrible shame that the huge effort Canonical made to get Unity to the high level it currently is, was not spent on making GNOME Shell even better. Canonical may be stubborn, but the company has great ideas and it could have done so much to make GNOME Shell really slick.

Canonical is not a very huge company. It does not have enough employees to create and maintain a whole desktop. This is already showing in the stalled innovation of Notify OSD and friends; I am absolutely jealous of GNOME Shell’s notification area. While GNOME is working on expanding and improving its GNOME 3 desktop, Canonical is still very busy with its own shell. The consequence of this is that the shell does not integrate as much in the rest of the applications as you’d hope. There is a lot to improve in the GNOME project, but when you improve it, you are sure that it fits with the rest of the desktop and that it will look and behave the same.

The Documents and Media file browsers I mentioned earlier can be great ways to give users access to their files. However, every time you implement a way to access stuff like this, you make a paradigm choice. If you want to satisfy the user, it should be consistent. Unity also gives the user access to files, but it does so in a different way. This causes a collision of paradigms. If Canonical wants to do it right, it should ensure consistency across all applications. This is a lot of work and will probably require the development of its own file manager, etc, in the long term.

Canonical does not have the workforce to fully maintain its own desktop. By creating its own shell, it may improve things in the short term, but it will only make things worse in the long run. While GNOME progresses along a different path, the two desktops will diverge even further. In the end, if we ever want to beat Mac OS X, Ubuntu will have to to get rid ofGNOME and Canonical will have to have grown substantially.

GNOME needs Canonical as well. There is no other company in the Linux distribution world that focusses on regular consumers and regular consumers are the target group that shape the OSes of today. I’m not sure how much longer Novell’s remains will stay around, Nokia seems to be on a suicide mission and Red Hat is a business oriented company. GNOME 3’s magnificent user interface philosophy is in need for a good set of clothes and proper manners and of all companies that are in existence today, Canonical is the best candidate to look after that.

My ego is not so large that I believe this blog post can change Canonical’s company policy—which naturally wasn’t thought out in one hour—but I do wish to add my voice to the chorus that say: Ubuntu should return to GNOME 3!

Yesterday I bought myself a shiny new toy: a Midiplus Audiolink. With this USB-device you can connect your guitar to your computer. (According to lsusb the chip is a ‘Texas Instruments Japan PCM2904 Audio Codec’.) I may not have an electric guitar, but my wonderful Crafter TC035/N does have an element pick-up and built-in preamp. With this device I can record and play-back without having to buy an expensive amplifier.

When I bought it, I got a driver CD as well as warnings for Windows Vista. I hadn’t checked for Ubuntu compatibility, so I did expect some troubles and braced myself for hours and hours of fiddling with JACK to make it work. So I started with installing Ardour and trying if I could get anything recorded there. Nothing.

Then I remembered my system was sporting the flexible PulseAudio. So, I went to volume control, saw the Audiolink listed under input devices. After I had selected it, I opened the GNOME Sound Recorder, pressed record and started to play. Bingo! Everything just worked. No fiddling needed. All you have to do is to select a different input, using the default volume control.

This really demonstrates the power and user-friendliness of PulseAudio. I know that with JACK it is possible to do quite a lot with input sources, but that is too much for what I want. I just need something simple and this is working great for me! Thank you PulseAudio developers!