Scott Ritchie wrote:
Reece Dunn wrote:
2009/4/18 Kai Blin kai.blin@gmail.com:
On Saturday 18 April 2009 05:21:20 Dan Kegel wrote:
The one that worked out best was to pick some random user who's almost happy, fix the last few bugs that are keeping his apps from working, and then once he's happy, move on to the next such user.
The problem seems to be identifying these people. The model assumes that you can tell which piece of software almost works, and that you know the almost happy users. In reality, you only seem to hear from the pretty unhappy users and the occasional really happy user. Susan Cragin is about the only user I can think of off the top of my head who's almost happy and could be made completely happy by fixing all of the remaining bugs in DNS.
You could also pick some games as well. A lot of the Oberon Media casual games work (probably around 50-60%), but there are bugs in the launch page that means you don't get a seamless experience. The Game Socks versions of the games have a seamless experience with the splash loader (not sure about purchasing games there, though).
Other popular games and games platforms like WoW and Steam will also help your gamer users.
The one trouble with gamer users is that they tend to have a lot of games that they want working. Probably the major exception is WoW -- and it's a very wise choice for us to make sure it works really well, since many users want that and only that.
CodeWeavers are doing this to some extent - now branching out to fix other applications. There was a big push a while back to get Photoshop usable.
AppDB or something similar is useful for determining the most popular applications that people are using. This does not cover the users, though -- a user may be happy with one app, but unhappy with another because that one is obscure/unpopular (think in-house applications).
Also, reality has us deal with the fact that new applications are added while we're working on the old ones, and looking at the graphs, we're only going to make a significant number of users happy when we're about 98% done fixing the bugs. I realize that it's a bit hard to model "rate of new applications with new bugs being added", but that's what happens in real life.
Not just new applications, but upgrades as well. iTunes is a constantly shifting landmark, from what I understand. IE6, 7 and 8 use more of the Windows API. Photoshop only works with earlier versions. There have been updates to fix Office 2007 SP1 issues.
Some of the major pain points I can see in the future for getting Wine to run applications are:
- applications that use the newer Windows Vista and 7 APIs -- this
is ok if the application is also designed to run on XP or earlier, but applications will start targetting XP and later or Vista and later. 2. applications that use .NET, WinForms and/or WPF -- these should be ok on Wine if the Microsoft and/or Mono runtimes can support these. 3. applications that start using more (unimplemented or partially implemented) of the XP and earlier APIs.
So a happy user today could be an unhappy user tomorrow if they try and upgrade one of their applications. But such is the nature of playing continual catchup.
Perhaps this implies we shouldn't try so hard to get the apps that are about to break on upgrade, even if they are big ones. We've spent a lot of effort chasing Photoshop, but if only the Photoshop of three years ago works then we haven't really gained much directly.
There are big bugs and smaller ones. If an app is in the high 90's for working and there is an active use of it in wine, smaller programs and utilities come to mind, then concentrating on those would seem to have a bigger satisfaction payback. All the little glitches and problems are magnified as the users are expecting that if it is not a word or a photoshop then it should be small enough to work in wine. Another way of looking at it is that these bugs and lack of functionality need to addressed sometime and if the effort is put in early then we do start to get happy users.
Jeff