Showing posts with label Canonical. Show all posts
Showing posts with label Canonical. Show all posts

Monday, May 3, 2010

Ubuntu Netbook Remix's New Look for 10.10 (Maverick Meerkat)

Mark Shuttleworth had talked about putting the application in the top panel for Ubuntu 10.10 UNR, and now the first mock-ups have arrived. In addition to that change, the status panel is gone and status messages are transient overlays a la Chrome Browser. Application-specific notification icons ("Windicators ... ahhhh) appear in the titlebar, which is now drawn by the application.

I think this is a lot of work. Ubuntu and Canonical haven't been big on diverging heavily from GNOME or Debian. Since GNOME is moving to Shell and the Mutter window manager, this appears to mean that Ubuntu will be forking. Do the Canonical devs have the dedication to make this happen? How buggy will the first version of this forked window manager be? Will the windicators (I grimace even writing it) provide true benefit.
That was the negative. Now for the positive. If Ubuntu sticks with panels and doesn't move to the GNOME Shell, I think it will be a good decision. Scrapping everyone's understanding of an interface and completely starting again will only hurt Ubuntu adoption where Canonical wants to make money -- the enterprise. As I've said in previous articles, "Don't change the UI." These indicator additions seem like smart and intuitive additions to the WIMP desktop model.

If Ubuntu diverges from GNOME (and probably Debian, since it rarely customizes upstream projects more than necessary) by ditching Mutter and the Shell, does it have the chops to keep up? For Canonical, that seems to be the $20,000 question.

See the full story from Mr. Shuttleworth here: Mark Shuttleworth: Window indicators (markshuttleworth.com)
Reblog this post [with Zemanta]

Monday, January 25, 2010

David Seigel on Improving Launchpad Bug Workflow, or "Developer, Developers, Developers"

Mark Shuttleworth and Canonical Ltd. employees...Image via Wikipedia
David Seigel has a great post, called Improving Launchpad Bug Workflow for Opportunistic Programmers < The Plenitude of Arboreal Beauty. It's not great in that I like the exact solution proposed, but it highlights some important points about Free software development, and the comments are equally interesting.

First, a summary for those not wanting to read the post. David proposes adding a simple link to Launchpad which will help opportunistic programmers fix simple bugs like the ones in 100 Papercuts without having to worry about setting up the proper build environment. Clicking "Quickly fix this bug" installs the proper dependencies and source, opens the preferred editor, and creates a patch when finished.

In effect, David is proposing that Ubuntu prescribe a specific method for bug fixes, including the IDE used. (He proposes using Eclipse.) While this type of policy is likely to rankle many programmers, I believe that having a preferred IDE, language, and toolkit for Ubuntu would be a big step forward. In fact, when Ubuntu started in 2004, I remember Shuttleworth stating that all new work should be done in Python, and that Canonical would be hiring based on this principle. SchoolTool was developed from Zope (IIRC) for this exact reason.

While there certainly have been many new additions to the Ubuntu project which rely on Python since then, we also have GTK-sharp, C, and ECMAScript or JavaScript (e.g. Seed or Gjs). Ubuntu has failed to have a single, defining vision for its product (which Shuttleworth claims he wants) with a preferred development method. I'm not suggesting that there be only one method for development, but both Microsoft and Apple have shown that providing standard tools and languages (VS/.NET and XCode/ObjectiveC, respectively) can create a great developer base. The easier to get involved, the better.

Ubuntu could have a special developers' release which includes all the standard tools necessary to set up and connect to a Launchpad account (for bug fixing and publishing via PPA), an IDE with Ubuntu- and Launchpad-specific plugins, and complete developer documentation. Of course, programmers can continue to use Vim or Emacs or whatever, then use Bazaar from the command line, but new developers would likely just accept the default method Ubuntu provided, and puting "Ubuntu" into the "integrated" part of an integrated development environment would lure many developers. (I had in my notes but forgot to mention that Ubuntu currently is developing Quickly, which appears to be going in the direction I'm proposing. Or it could die like so many other other projects. Wait and see.)

More interesting stuff comes up in the comments section: what is the responsibility for upstreaming? Should bugs be fixed upstream first? Should patches be preferred for upstream? I think these kinds of arguments overlook the strength of FOSS. Ubuntu should fix bugs as it sees fit locally first, and submit those patches or make them easily available (something Launchpad is working hard on). Ultimately, though, many proposed patches will not be accepted by upstream, or they might be delayed by years waiting for a release. If Ubuntu wants to progress, it needs to take responsibility for its own problems and not state that it is waiting on upstream to integrate or fix a patch.










Friday, December 18, 2009

Shuttleworth Steps Down As Canonical CEO

"In a surprise move (at least, it was surprising to me), Ubuntu founder and Canonical CEO Mark Shuttleworth has announced he's stepping down as the CEO of Canonical, the commercial endeavour behind the Ubuntu Linux distribution. He will continue, however, to play major role in the company and Ubuntu's future.

Jane Silber, the Chief Operating Officer of Canonical, will take over Shuttleworth's role as CEO. His stepping down as CEO does not mean, in any way, that Shuttleworth will disappear from the stage. In fact, his stepping down allows him to focus more on product design and development, his passions. He will also remain as the head of the Ubuntu Community Council and the Ubuntu Technical Board, and he wants to spend more time working with partners, especially in Asia."

...



"'This move will bring about is a clearer separation of the role of CEO of Canonical and the leader of the Ubuntu community,' Silber said, 'It will be two different people now, which I think will be helpful in both achieving their joint and individual goals more quickly.'"

See OSNews for full report. Also reported on Compuworld.

Reblog this post [with Zemanta]

Friday, November 20, 2009

Is Ubuntu Too Big for Its Own Good?

I miei CD di Ubuntu ShipIt!
Image by -= TreviƱo =- via Flickr
After writing my post about the default applications in Ubuntu last night, I had some thoughts which Fieldyweb might agree with:
What they should do, is redesign that, take ALL the apps out of Ubuntu, other than ff add adobe flash and as many codecs, 3g ethernet and wifi drivers as they can get away with, then redesign the app store, so if you want printing, you install it from there, if you want evolution, gimp whatever you install it from there.
My opinion is that the universe and multiverse repositories contain too much software for Ubuntu to QA properly. The number of bug reports during alpha and beta is so large that many of them aren't triaged until long after release. The release bugs aren't triaged until the next version is just around the corner. Invalid is the natural response in that situation.

Ubuntu is a foundation-run project, but the software reflects on Canonical, which sells support. The Self-Appointed Benevolent Dictator for Life needs to take the lead here and move the MOTUs out of the official Ubuntu repositories and into Launchpad, Canonical's code hosting and buid server. Making optional software available in individual PPAs, will mean that Ubuntu becomes responsible for much less and can concentrate on making the applications in main, especially default applications. Canonical can work toward its stated goal of creating a worthy competitor to OS X 10.6 (Snow Leopard) and Windows 7.

What would the process of moving towards more streamlined look like? First, there would be no more mass import from Debian Unstable. Ubuntu would be responsible for the basic application and drivers necessary to run the various projects. MOTUs should be encouraged to move as quickly as possible to PPAs. AptURL should have the prohibition on PPAs removed for Launchpad.net. Finally, the Software Center needs to be reworked into a front-end for Launchpad PPAs. Backports will be responsible only for core applications (and likely only for LTS releases).

In the end, MOTUs and their PPAs would be obviously responsible for third-party package bugs which are now blamed on Ubuntu. Ubuntu development would more closely model its rivals (OS X and Windows), concentrating on the core OS and leaving the extra applications to interested parties. Users would still get one-click installation of software. Users would also stop bitching about having to upgrade in order get the newest software. The default Ubuntu install would just work.

There are some problems with this approach:
  1. Making sure users understand how to get PPA software and that the process is easy. This is solved using AptURL and one-click adding of PPAs and keys.
  2. Enforcing a packaging method in PPAs which limits or eliminates dependency conflicts. This is solved by having the software center only search for MOTU PPAs, where MOTUs are responsible for limited numbers of packages. Python bindings for Coherence (uPnP) are handled by one MOTU and Python programs which use that binding are assigned to other MOTUs.
  3. Ubuntu will definitely get some backlash for supporting fewer applications. Hopefully, this problem is mitigated by the improved quality of the core OS.
Thoughts?

Wednesday, May 13, 2009

About UbuntuOne -- The Post That is Sure to Piss Someone Off

I've been waffling for a couple of days over whether to write this post or not. I finally decided to just speak my mind.

UbuntuOne is a new service from Canonical that's currently in Beta testing. It doesn't differ in any important way from similar services like DropBox or Box.net, except that it's integrated and designed specifically for Ubuntu (9.04 Jaunty is required). The client is still immature, but it will probably eventually include useful services like integration into Conduit Sync and desktop settings. Once that kind of integrated functionality appears, people will probably line up to pay the USD10 for 10GB of storage.

Unfortunately, Canonical is playing this on-line service the same way they play their others -- closed source. Just like Launchpad, the server software isn't open (though the client is). Why does it choose to do that?

It's not necessary to keep either closed, you know. Launchpad offers a great way for teams to work together, but its value isn't in the code as much as it's in the community behind it. Facebook could open its code, too without any worry of someone building a copy. Launchpad links teams and code. Nobody is going to replace it.


UbuntuOne will eventually be integrated into Ubuntu. Users will be able to share files with others on the service. It will be half backup and half social. No matter whether there's an open version of the server or not, the vast majority of users will be on UbuntuOne instead of WannabeOne because that's where everyone else is and getting set up is much more convenient to use the included client than downloading a different client setting it up with the other service.

In both cases, Canonical gains little by playing both sides of the fence, offering closed-source solutions as an open-source business, but it loses a lot of community support. Red Hat, on the other hand, is a pure open-source company, and has no problem:
  1. Offering amazing platforms like the Fedora Directory Server completely openly, and
  2. Making money off of the software service.
Very few FOSS advocates have a problem with dual-licensing projects like MySQL or QT (before the acquisition) selling licenses to closed-source projects, but that's not what we're talking about here. This is more like SUSE's old model of keeping YaST closed (it was GPLed in 2004). That, too, kept a lot of people off balance with regard to SUSE. The open source business isn't one that you can stick one foot into -- you have to jump in all the way.

Most Ubuntu users aren't aware of the FOSS philosophical arguments, but that doesn't change the business arguments. You can't promote open source while holding some of your cards close to your chest. How can I trust you when you say one thing and do another?

Ulitimately, it's Canonical's call and it's their code. They get to license it any way they want to. I still think they're shooting themselves in the foot.


Reblog this post [with Zemanta]

Friday, April 24, 2009

The Big Picture: Timed Release Failures

Ubuntu DVD Case RenderImage by Andrew Mason via Flickr
Jaunty should be out today (this post is scheduled), and I think  this is a good time to talk about whether timed releases are a good idea. I'll put my opinion out here at the beginning and say that, from a project management standpoint, hard release schedules are really not the way to go. Let's look at Ubuntu 9.04 Jaunty as an example.

There's a giant bug in Brasero that doesn't let a user create a video CD or DVD. Brasero claims to have this function; it appears to have this function by virtue of there being a button for it; but attempts fail because it claims that it's not possible with the available plugins. This also breaks Totem VCD/DVD writing, one of the bullet points for this release. A fix is available and in a PPA, but it's apparently (as of T minus one day) not going to be included because of the package freeze. They can't test the package and get it included in the CD on time.

That leaves a choice: push the release back a couple of days, or ship with a major bug.

Canonical used to be a little more flexible with its shipments: 6.06LTS (Dapper Drake) was delayed two months because they wanted to hammer out a few bugs. About the time that 8.04LTS came out, though, Canonical became much more serious about the day they were to release on. Countdown clocks were part of the marketing effort, and if they're showing a release but one doesn't appear, that looks really bad for the project.

As a result, 8.04LTS (Hardy Heron) shipped with a bug which prevented F-Spot from launching a second time on AMD64. The first time worked, but a late change in mono left the default photo application for the OS segfaulting on startup when run the second time. It didn't get fixed for a couple of weeks. Ubuntu 9.04 (Jaunty Jackalope) will likely have a similar (but not quite as serious) bug in the shipping version because of Brasero.

There's the other side of the argument which says that there'll always be bugs and that you just need to ship, anyway, but that's why some bugs are called  "release critical" and you need to correct them if at all possible. That "posible" thing includes delaying the release for a week.

Timed releases are fine, but don't shoot yourself in the foot. Be flexible enough to put out a good product. You can't be taken seriously by real users if you ship non-functioning product regularly. That's the big picture.

Reblog this post [with Zemanta]

Other I' Been to Ubuntu Stories

Related Posts with Thumbnails