Archive for the ‘Ubuntu’ Category


Lucid – thoughts on LTS releases

November 16, 2009

Lucid Schedule

I was interested to read the Lucid Lynx release schedule and see the modifications that have been done due to Lucid being an LTS release. As outlined in the second link, packages will be synced from Debian testing rather than unstable so as to reduce the risk of new bugs being brought in.

Also the alpha period has been reduced, leaving time for two beta releases. The first beta will be 6 weeks before release, with a second release 3 weeks before release. (Normally there is one beta 4 weeks before release). I guess the hope is that there will be more people upgrading earlier, so that more bugs will be found earlier. This sounds good for quality, but I suspect that many will wait for the first point release before considering lucid to be stable and upgrading their important systems.

In many ways the work in the Lucid will be working through many of the issues introduced in Karmic when upstart and other technologies were introduced. No major new technologies (such as gnome-shell) will be introduced with Lucid. I guess this is a lesson learned from the Hardy cycle where the introduction of PulseAudio caused problems for many people as bugs were exposed in the applications that used audio.

However I think the other fresh inclusion in Hardy was a good idea. I’m referring to Firefox 3, which was still in beta when Hardy was released. The key difference relative to PulseAudio is that no software depended on Firefox 3, so it did not break anything. Firefox is also very well tested by the time it is released, so we can have high confidence that it is going to work well.

Application Versions in LTS Releases

Which leads me on to think about how to keep packages up to date for an LTS release. On a recent edition of the Ubuntu UK Podcast they discussed the problems some people had when upgrading to Karmic. On the desktop they thought that users wouldn’t be happy with an old version of applications such as Firefox and Open Office. So the users feel they have to upgrade to non LTS releases. (Indeed another piece of post Karmic discussion noted that the default download is currently Karmic rather than the last LTS – Hardy.)

So how can we improve the situation. Well one thing would be for major applications to be easily available on the current LTS release. At a minimum, new Firefox and Open Office versions should be made available. These are applications that are tested on a range of environments, so no major work should be required to make them available. I was amazed to discover that the hardy-backports repository does not contain Firefox 3.5 (see this package search). (And using PPAs are not a solution for the normal user.) Users of Windows XP or Mac OS X 10.1 are not stuck with the versions of applications available at the OS release time.

The issue seems particularly urgent in light of Mozilla ending support for Firefox 3.0 at the end of 2009. So for the first few months of 2010 the current LTS release will have an unsupported web browser. This is unacceptable.

So how do we do address this? We should certainly not upgrade major versions of software without the permission of the user. Having a backports repository enabled by default would provide packages for new versions of major applications. When they are available the update manager could offer to upgrade to the new release of application X.

Whatever the details are, it should be simple for a user of an LTS release to get up-to-date versions of major applications without having to upgrade the rest of the operating system.


Free software projects and donations

November 4, 2009

The issue of donations to FLOSS projects was discussed with Paul Davis (a developer for the Ardour audio editor project) in an episode of FLOSS weekly and he said that there are a few categories of app with regard to need for donations and source of resources:

  • very important apps that are funded by various companies because it is in their best interest, or because it is their project. eg Linux kernel, apache web server, firefox, java, openoffice … Most server apps probably fall into this category.
  • small apps that can be written quickly and don’t require much development. eg sound juicer
  • big desktop apps that require a lot of work, but don’t have an obvious funder. eg Ardour, inkscape …

So the big desktop apps are the ones that need donations the most. It got me thinking about what would be the best ways of channelling money from users to developers. Some options include:

Donate button in Software Center

The upcoming Ubuntu Software Center application would be a great place for this. At the bottom of the software description, along with the Install and Website buttons there could be an optional Donate button, along with some text saying why donations are important to that project. The Donate button would take people to the donate page of the project website.

It should only require a little bit of extra metadata. I would think it should be an optional thing, off by default so as to channel donations to those projects that really need some money – eg Ardour.

If the software center later has a way of taking money (for selling non-free software) this mechanism could be used to send money to the project without having to set up a new account. Though this should take into account that some upsteams that need serious cash would prefer regular subscription style donations rather than less predictable one off donations.

Note that this is something to do aswell as having a standard place within the app for a donate link.

Donate button in the About box

One standard place for a Donate item would be in the About box (that lives in the Help menu). Apps could put a paragraph in there about why they need donations and a link to their donate web page.

Donate text as a “tip” for the application

Many applications have tips for new users on start up (the gimp, digikam …) One of these tips could be to say that this application requires donations to support it’s developers/to keep the website going/because beer isn’t generally free. There would then be a link to the donate page on the project website.

This could complement the Software Center option. The Software Center option would be good for those who know they want the application and realise the value of the app to them. However those who are just trying the app and may or may not like it are unlikely to donate at that point. But if they see a tip at start up some time down the road, when they are regularly using the app and know that it is valuable to them, they may then be more likely to donate.

As one of a number of tips, most of which are useful to you, it should hopefully be seen by a large number of users and not be seen as too in your face nagware. And as tips can be turned off, so can the reminder, so it won’t get too annoying.

I have written some of this up on Ubuntu Brainstorm.