IBM's new Ubuntu-based desktop offering

My criticism is explicitly about Canonical... not Ubuntu. I think Canonical is doing some things fundamentally wrong as a community managing entity and is setting a bad example for all corporate citizens of the open ecosystem.

I think Canonical's choice to setup launchpad as a closed service to be the backbone of a community distribution such as Ubuntu is fundamentally wrong and it stunting the larger Ubuntu community's ability to interact more directly with upstream projects. Lauchpad's design is fundamentally flawed and does not take external upstream workflows into account. This design flaw is a direct result of Canonical's business interest for a centralized Launchpad service which is in direct conflict with the ecosystem of distributed project development. Launchpad's services as designed maybe compelling for individual upstream projects, but for distribution development where collaboration with external upstream projects is required, the centralized nature of Launchpad isn't necessarily a good approach. Canonical may have turned the corner recently with bug triaging by opening up the Launchpad plugin API, and creating the bugzilla and trac launchpad plugins... but for patchsets including translations.. its not clear that the Launchpad services as designed is helping collaboration with upstream and in fact it maybe hurting collaboration by encouraging people to do their work in launchpad instead of encouraging people work directly in upstream.

Ubuntu translators really do want to work more directly with upstream, but they are hamstrung by how translation development in Launchpad works, and they do not have access to the code to implement changes to the translation tools so they can build a better process. Right now they have to rely on Canonical to make changes to Lauchpad. That's a problem for the Ubuntu translation community and for the upstream projects. A problem created by Canonical's business interest in a proprietary Launchpad service.

I think Canonical's choice to setup a community remix trademark policy, then bend the rules of that trademark policy for Canonical's commerical benefit so Canonical could create the commercial OEM netbook remix images with specialized hardware support is a problem for the Ubuntu community and shows a lack of respect for the volunteer Ubuntu community who isn't getting a Canonical paycheck. As a corporate entity, if you are going to setup a community trademark policy for a secondary trademark, abide by that policy as you would have any other community member and don't twist the rules for corporate benefit just because you are the mark holder and can not be held accountable by the larger community. Canonical is building the OEM specific netbook images and calling them "remixes" in direct conflict of the "remix" trademark policy they established for the non-Canonical employeed Ubuntu community to use. Canonical didn't have to call the commercial OEM offering a "remix", they could have abided by the community trademark policies and called it something else. A 'Do as I say, not as I do' management style, is never a good way to manage a community. This sort of willingness to subvert communicated community oriented policies for business reasons is a problem. It will become a bigger and bigger problem as Canonical adjusts its business focus more narrowly on profitability and less on brand recognition. If they are willing to subvert the community "remix" trademark policy what other policies are they going to be willing to subvert?

I think Canonical's handling of a community ports area as an architecture graveyard that does not include a way for the Ubuntu community to initiate ports of Ubuntu to new architectures is a problem for the Ubuntu community. Is the only way to open up an Ubuntu port to a new architecture is to first have Canonical provide the infrastructure in a failed effort to monetise the architecture? Can motivated Ubuntu community members who are not employed by Canonical add new architectures to the Ubuntu ports area without having to pay Canonical to do provide the build hosts? Are community members really forced to run those sorts of ports as external projects without access to the Ubuntu branding? Isn't that a problem for the wider Ubuntu community? If Ubuntu's build infrastructure was modeled on Debian's decentralized community approach, Ubuntu would already have a community led ARMv5 port up and running inside the Ubuntu ports system.

If Canonical addressed any one of these managerial problems, the Ubuntu community would be stronger for it and Fedora would not directly benefit.
If my motivation was to sabotage the Ubuntu community for my own self-interests, I wouldn't be publicly critical, I would instead take a job with Canonical and reinforce the walled-garden corporate culture from the inside.

-jef