Everything Michael posted in the article, I agree with. I'll tack on to that:

-Ubuntu Developers (people with an @ubuntu.com or @canonical.com email) don't take enough interest in helping new developers or "outsiders" to learn the processes needed to contribute new software to Ubuntu, even if that software is already written, tested and functional

-Impossible to get a mentor to help you get a piece of software integrated into Ubuntu

-Cloistered "we do things our way" approach, ignoring the advancements and contributions of other distros, even when other distros are clearly developing what will become standard software across the entire GNU/Linux ecosystem (systemd, gnome3 and gnome-shell, pulseaudio at first, KMS at first, etc)

-The implementations Ubuntu developers come up with are often, frankly, sub-par on a technical level, and are shot down on legitimate concerns by developers elsewhere in the Linux community. Launchpad is perhaps one notable exception, as it doesn't suck nearly as badly as you might expect from Canonical.

-The inflexible, time-based release cycle is completely untenable. Software is late. It will always be late. Always. You have to build flexibility into your release schedule in order to fix the most important bugs (or to detect them in the first place). You can't just pick a time and randomly release whatever you have. You have to demonstrate software quality, not hope for it.

-There is a tendency for the developers to be way too conservative about the package versions they are willing to include in non-LTS releases, and way too liberal about the package versions they're willing to include in an LTS. In other words, I think non-LTS releases should be significantly more unstable and bleeding-edge (about equivalent to a Fedora Beta), and the LTS should be significantly more stable and tested (about equivalent to Debian Stable or RHEL). Non-LTS Ubuntu releases are usually about in the middle of the two extremes: they are not too bleeding-edge, but the packages are just stale enough to be ho-hum boring, while also being chock full of bugs due to the short time-based release cycle and low community involvement in testing.

-Will the latest kernel or Mesa be in the next Ubuntu release? No, you have to wait 6 more months (and by then there will be even newer kernel and mesa, defeating the purpose). Will the kernel and Mesa that are included in Ubuntu be more stable than using git master? No, because they're feature-incomplete to begin with, and intentionally using an old version just means you don't get the latest features and bugfixes.

-So instead of hitting a "new" crash from code just committed, instead you get to hit a crash, and then see that somebody else already reported it on launchpad, and the bug is marked as "NEW", and no developer has even looked at it. By the time they look at it, it's already fixed upstream and being pulled into the next release. This happens almost every time, unless the software is something that (a) Canonical wrote, and/or (b) brings Canonical revenue directly (such as Ubuntu One). In those cases, you get a response within a few minutes from some overzealous Australian developer who works from home for Canonical, trying to make his product perfect, but can't seem to nail down the 100,000 different places where a runtime Python equivalent of a null pointer exception or type cast error shows up. (Did I mention I hate Python with a passion and wish that I could run my system without a python interpreter even installed?)

-They maintain huge patch-sets against certain packages (Rhythmbox, for example), and there is no toolchain to maintain or enhance the patchset, much less to make it work with a new version of the upstream package.

-While they do seem willing to include plugins and functionality not found in upstream packages (this is good), they don't have clear guidelines for whether a given enhancement should be (a) upstreamed, (b) included in the hackset (my new term for the sprawling patchset they maintain against certain packages), or (c) included in its own package entirely. Nor do they document where on launchpad you have to go to check out the latest hackset sources if you want to contribute something.

-Nothing to match Delta RPMs as far as reducing updates download size. And DPKG doesn't use LZMA2 (Xz) compression yet -- unacceptable. Switching to LZMA2 would save thousands of terabytes (or more) each year of public mirror bandwidth, by having package updates and distro updates being distributed with significantly better compression. Throw in Delta RPMs (well the DPKG equivalent) and you'd shave off another 50% bandwidth.

-It might be due to the particular timing of the release cycle itself, but it seems to me that Fedora is able to release newer packages (kernel, mesa, xorg, etc) and kick out a more stable and reliable distribution at the same time. They definitely have Ubuntu beat as far as the timing of their releases; they always ship with the latest stable packages (unless they are released in the last 2-3 weeks before distro release), and manage to stabilize them quickly (or not do anything funky as far as configuration that might screw them up).

-Remember that time someone initialized some pointer to 0 in OpenSSL to fix a Coverity bug, and Debian took the patch, causing everyone's generated private keys to lose a significant number of bits of encryption? Ubuntu does things like that, too. They accepted a patch against libshout a few years ago (and it went into Hardy IIRC) that basically broke all libshout encoding except for MP2. Nobody even bothered to test it, but the gist of it was that the guy who said the patch "worked for him" really wanted MP2 support, which was broken, so he did exactly the wrong thing and completely broke MP3 and Ogg/Vorbis support instead. This stuff makes it into a release how?

-Their automatic bug reporting tool makes bug workflow on launchpad impossible. Newbies always report crashes, even if the crash is their fault (example: switching out a library underneath Firefox during an upgrade, then opening a new tab without restarting the browser, and Firefox crashes. Big surprise; that's unavoidable.) There are way too many false positives, where users report bugs on software they've custom installed (or someone else custom installed for them, or they followed some online tutorial/script to install it, etc). Apport basically encourages false positives so much that most of the developers skip over apport reports as soon as they see them. The standard response is a 6-month followup of "if this bug is no longer reproducible, please mark it as resolved" or something like that. Completely unhelpful.