Canonical, the Linux vendor behind Ubuntu, is facing growing criticisms about turning its back on the free and open source software (FOSS) community. Critics claim that Canonical is bowing to commercial interests. But is it truly a problem for customers or the Linux community at large? I don't think so.
[ Get the latest insights and news on open source trends with InfoWorld's Technology: Open Source newsletter. Subscribe today! ]
Canonical's rise and fall from grace in the eyes of FOSS users
Bruce Byfield writes about Canonical's rise and fall in the eyes of the Debian and Linux community:
Instead of being the model corporate member of the community that it first appeared, today Canonical increasingly seems concerned with its own interests rather than those of FOSS as a whole. No doubt there are sound business reasons for the change, but many interpret it as proof of hypocrisy. Added to the suspicion toward the corporate world that lingers in many parts of the FOSS community.
Byfield documents several examples of Canonical replacing packages or using internally developed packages in Ubuntu to better align with Canonical's road map and product plans.
Commercial products require planning, tracking, and adjustments
It appears much of the angst toward Canonical can be traced back to a blog post from Canonical founder Mark Shuttleworth in December 2006. In a post describing challenges that Linux must overcome to win the desktop, Shuttleworth wrote:
To a certain extent, this loose coupling is beneficial. Work goes on in one part of the free software universe entirely oblivious to work elsewhere, despite the fact that both pieces of work will ultimately land up on an Ubuntu disk. Keeping everything orthogonal is very nice -- very Unix. It means that people don't have to keep too much in their heads. And that's worked well.
But sometimes I wish it were easier to keep track of changes and have a slightly clearer view of progress across that whole galaxy. For example, it would be nice at the beginning of an Ubuntu release cycle to have a really confident picture of which projects will produce stable releases during those few months when we can incorporate new upstream versions. It would be even better if, during the release cycle, we knew immediately if there was a change in what was going to be released.
As a product manager, I wholeheartedly understand Shuttleworth's desire. And this isn't just my view from a position at a commercial software vendor.