The most important area for Ubuntu to improve if it's going to appeal to a broader user base is in the area of software development. In fact this should have the highest priority over all other projects. Attract the developers, and other issues will be resolved much more quickly. In particular, what's needed is easy to use visual programming tools and much better documentation. However, as far as I can see, this definitely isn't a priority. Let's look, for example, at GTK+, which is the main graphical toolkit for Ubuntu. This is my experience trying to get started creating programming with this tool.
First I tried Anjuta, which is really the only IDE for GTK+. I realize some people like it, but I can honestly say that it's the worst IDE I've ever used. First off, it has a very amateurish feel to it. Most new developers will stop right there, but that didn't deter me. However, the interface very difficult to use. The default arrangement of the panes made no sense, and there didn't appear to be any way to rearrange them. The things that needed the most space had the least, and vice-versa. They could be resized a little bit, but that wasn't very helpful. This may not be an issue on a large screen, but it makes the program almost worthless on anything else. On my laptop I couldn't even view a small widget project without scrolling. Version 3 seemed substantially better than version 2, but I still had the same problems with the interface.
So I gave up that idea and decided to use Glade independently, and do the coding in either Eclipse or a text editor. I'm sure this may seem very simple to anyone who's been doing it for while, but not so for a beginner. After a substantially amount of googling, I was able to find the information I needed to get started scattered across the internet. I started by writing a simple test program, and it seemed to run and create my GUI without any issues. However, the project I was working on was in C++, and I soon discovered that I couldn't use any of the event handlers I'd set in Glade. These could be imported easily into a C program using a special compiler flag, but this didn't work in C++. An internet search revealed discussions on this issue going back ten years. In computer years, that's somewhere around a100 years. A workaround is to enclose the signal handler definitions in an extern “C” statement. That way the C++ compiler treats the codes as C code. But then what's the point of writing a program in C++ if a substantial portion of it ends up being in C. So then what this amounts to is hundreds of lines of manually entered code to designate signal handlers. My question is, didn't we invent computers to automate simple tasks like that? I'd go on describing my adventure with GTK+, but the point is that most developers have already given up and gone to lunch at this point. I concluded that GTK+ is not a good choice of toolkits for a C++ project.
Now I must say that my experience with Qt was an entirely different one. Where I spent a lot of time just trying to find adequate tools and documentation for GTK+, Qt presented me with the dilemma of choosing which tool to use. I decided on the Eclipse plug-in because I like being able to do everything in one place. Qt Creator is also an excellent IDE, and the interface is a bit less overwhelming than Eclipse. Both have a very professional look and feel and are easy to use and customize. Both are also available on multiple platforms. Documentation and tutorials are abundant and easy to find. Qt works very well with C++, and everything can be done in one program. Signal handlers can be easily created with the click of a mouse. If they are created manually using the standard naming conventions, they will be automatically recognized by the compiler.
What's puzzling is that GTK+ is by far the more popular toolkit for Linux, and the default for Ubuntu. And yet the tools available for developing with it are a bit vintage. There are Eclipse plug-ins for just about everything, but not for GTK+. Some of the old Linux hackers may balk at the idea that everything should be done graphically. But certainly a graphical toolkit should be done graphically. Some would say, well GTK+ doesn't have the commercial backing that Qt does, but that's not entirely true. This is the primary graphical toolkit for the what is by far the most popular Linux distribution. A variant of Ubuntu is used widely by Google employees. Gnome is also the default desktop for both CentOS and Redhat.
So why isn't this a priority. Well first off, the experienced programmers who work with GTK+ have gotten by fine without these tools, they're used to doing it a certain way, and so they don't see a reason to fix it. Another possibility is that Canonical plans to transition away from GTK+. After all, one wonders how long it will be feasible to reconcile the two now divergent projects of Gnome and Ubuntu. Oneiric will apparently implement Gnome 3 libraries. However, those libraries are developed for the now tightly integrate Gnome desktop, and continuing to rely on them for the Unity desktop may end up being more trouble than it's worth.
I know a lot of people will respond to this with remarks like, “I think Unity was a stupid move for Ubuntu anyways.” Or “I don't like Gnome Shell or Unity.” Or maybe you think Ubuntu should use Gnome Shell instead. However, it's pretty clear by now that Unity will be the future of Ubuntu and that the old Gnome is gone. Long time Gnome users will either have to adapt or find another option. Unless you build your own system from the ground up you'll never be fully satisfied with it, and you will always be at the mercy of developers, even on Linux.