Modeling Wine development and Linux adoption

A while back I found myself facing the question of when we could expect Wine to get substantially better.  Wine has been in development for 16 years, and while it has millions of users there are still a great deal who are unhappy with it.  This is completely understandable – Wine doesn’t yet work perfectly with all their applications, and they shouldn’t be happy until it does.

So, I decided to make a model of Wine development.  That way I could figure out if we were doing something wrong, or if it even mattered which bugs we were solving as long as we were working.

Modelling Wine development and user happiness

Let’s define the Wine project as a set of 10,000 or so bugs yet to be solved.  Maybe these represent API functions, or usability issues, or performance problems – whatever.  Some of these bugs may be harder to solve than others, so we’ll give each one a difficulty rating in terms of time.

Now let’s define an application as some subset of these bugs.  A working application is one that has all its bugs solved.  We can also give each bug a different relative probability of affecting an application – maybe bug x is 10 times more likely to affect an application than bug y.

A user is then defined as a set of applications he needs.  A “happy user” is one who has all his applications working.  Just like with the applications, we can assign relative probabilities to reflect the real world – World of Warcraft is 60 times more likely than CuteCatExploderPro.

Finally, we need some strategy for solving the bugs.  We’ll get to 100% bugs solved in the same amount of time regardless, but the order we do them in will matter.  I was able to come up with about a dozen or so strategies, such as “pick a random unhappy user and solve a random bug in one of his applications”.  I picked the most realistic of these, and told the simulation to alternate between them.

I then turned this all into a python script and combed it with the cairoplot chart generator, generating a picture like this:

Model of Wine development

Output of wine-model with 10,000 bugs, 500 users, and 500 applications simulated

You can download the script and play with it yourself – much of it is easily customizable

Surprising things learned from the model:

  • The strategy we use – the order we tackle various bugs – really does matter.  Every strategy gets to the perfect 100% end after solving all the bugs, but some get you 10 times as many happy users when you’re only half done.  In practice, having far more users likely translates into extra developers and a much faster rate of development.
  • Varying the difficulty of individual bugs didn’t matter much.  The pictures came out pretty much the same
  • Prioritizing the last few bugs in apps that are almost done is one of the most productive ways to increase happy users – in the simulations I ran it even outperformed working on the most popular application.  Unfortunately in the real world it can sometimes be difficult to tell if an application “almost works” in Wine.
  • Similarly, “almost happy users” are the easiest to satisfy.  When we have many to choose from, picking one arbitrarily and ensuring he was happy before moving on to the next user significantly outperformed trying to satisfy almost happy users at random.
  • Instances of “collateral damage” – the fixing of one application causing another application to start working without any extra effort – are rather uncommon until most applications are almost working.  The wintrust API is needed by both Steam and iTunes, however when enough of wintrust was implemented to make Steam work there were still many unrelated bugs causing iTunes to remain broken.
  • Just about every reasonable way of generating bug difficulty, relative bug probability, applications, and users that I could think of lead to the same general picture: something that looks roughly linear for most of it before taking a very sharp upward turn near the very end.  In other words, the model tells us that we should expect to be pleasantly surprised.  At some point, Wine will get very good very fast.

So, when will that point of sudden very rapid growth begin in the real world?  No one can really know – even analyzing statistics like the growth of platinum ratings on AppDB would only give us information after the fact. 

Modeling Linux adoption

We can make a similar model for Linux adoption itself.  Just imagine a few well-known barriers to entry, like driver support and compatibility with existing applications.  Now suppose that a particular barrier affects some large percentage of potential users.

If 80% of users can’t switch until they have working drivers, 80% can’t switch because of some existing Windows application, and 80% can’t switch because they haven’t heard of Ubuntu, then that means we can only expect to get 0.8% of the users.  This is, incidentally, about as many as we have.  As Joel on Software* puts it:

Think of these barriers as an obstacle course that people have to run before you can count them as your customers. If you start out with a field of 1000 runners, about half of them will trip on the tires; half of the survivors won’t be strong enough to jump the wall; half of those survivors will fall off the rope ladder into the mud, and so on, until only 1 or 2 people actually overcome all the hurdles.

So what’s our best strategy then?  Eliminating these barriers to entry – turning the rope ladder into an elevator – is the only way to get new users.  If we fix the driver problem, and the driver problem affects 80% of our would-be users, then we can quintuple our user base.  If we fix the Windows application problem, and make Wine work well, then we can quintuple usage again.

Full article by Joel on Software

13 Comments

yungchinApril 18th, 2009 at 1:04 am

You might like this piece by Joel’s partner (at StackOverflow), which suggests that Wine (or any big project) could use something like Windows Error Reporting facility in order to fix the bugs in optimal order…

David GerardApril 18th, 2009 at 4:11 am

I’d say there was a significant upturn around 0.9. That’s where Wine crossed from being an interesting idea into something good enough to actually use – where it was good enough for actual users, so more users meant more bug reports. Yay bug reports!

I got a similar feeling around Mozilla 0.9 – where this fat, lumbering, bug-riddled, crash-prone browser that was nevertheless very important crossed some line and … was more usable than not. I believe it was the stability push between 0.8.1 and 0.9 that did that. But that’s a magical inflection point too.

Does your simulation have any “good enough to be beta” effect in it?

@yungchin’s suggestion is FANTASTIC. Just knowning that an application has crashed is presently information that has to come from the user bothering to tell us; having Wine report that the app has crashed will give an actual picture of the sorts of things people are trying to run with it.

FlimmApril 18th, 2009 at 5:07 am

A working application is one that has all its bugs solved.
We all know that there’s no such thing as a perfectly bug free application. Even if wine fixed all its bugs that affected an application, the app itself would still have its own bugs! I think users can be “happy” even if they are quite a few bugs left.
*later* Seems like you already thought of this, as it’s in one of the know shortcomings listed in the source code.

JasonApril 18th, 2009 at 6:28 am

You are soooo right when it comes to this. Drivers and applications bugs, particularly in the area of regression. it the biggest roadblock to Linux, Ubuntu, and Wine.

A perfect example is a very popular OEM chip used in many, many laptop webcams …

— Start quote from Launchpad bug —
Ubuntu 8.04: Worked out of the box
Ubuntu 8.10: Need to compile and install manually a driver
Ubuntu 9.04: Compilation and load work but webcam is unusable

Can it be a regression of the stkwebcam module on ubuntu 9.04?
— End quote from Launchpad bug —

JimCooncatApril 18th, 2009 at 2:01 pm

80% haven’t heard of Ubuntu? I’m guessing much more than that.

I wish National Geographic would do a story on the Ubuntu phenomenon, warts and all. They could do it justice with their excellent filming, and so many more people would get exposure. In return, they get a huge global story of cooperation and social coordination.

Increased exposure would make it easier for those who know it to have it available at work. Coworkers who like using it would bring it home. It’s a cycle that MS beat Apple and Amiga with — instead of marketing with schools, they marketed to people with the checkbook, management and working people.

You keep up the good work with Wine, and your study will help tremendously for your focus. As you improve, we’ll keep moving one app at a time out of our virtual machines.

David GerardApril 19th, 2009 at 4:45 am

@JimCooncat – yeah. We need Linux astroturfers – “yeah, Ubuntu’s a complete pile of garbage! See for yourself – download and try the live CD, you’ll see how terrible it is!” Heh.

Wm FranklinApril 20th, 2009 at 7:44 am

For Linux: (1) All common wireless chips, supported out-of-the box, Fedora, Ubuntu, SUSE distributions – this has stopped me from converting 2 different Dell laptops (Broadcom wireless chips) from Windows to Linux (2) Option to install Samba — preconfigured equiv to Windows networking (XP/Vista/Win 7) — out-of-the-box with Fedora, Ubuntu, SUSE distributions – as in mark a checkbox, give a network name and you’re done (3) one common update format, or *universal* installer, so you don’t have to worry about which distribution produced which update or add-on program

AndyJune 4th, 2009 at 6:04 am

What I don’t understand is why not simply focus on 100% implementation of components. So what is needed is

a. Test what the component does.

b. Test what all known apps do with the component

c. Implement the component.

All of this is very much “contained”. You have one dll, you can outsource and modularise development. The real problem emerges as the issues are not contained. You have 50% components working with 50% components which multiplies the bugs, and hope to get it to 50% and 60% to support an app 90% (but in the next version of Wine it will break). A component wise 100% implementation means: this element is “done”, and for the next application we need to implement this component. II.) There should be an external project which just works on getting a single product or product line work with fine. Like Linux-Xbox you have a project of people interested to get e.g. Microsoft Office run with Wine. You can donate to that project. It is a tangible goal which is not open ended, all results of the project end up in Wine, they test the latest applications, they maybe get financial support of companies, vendors, users, a single hub with a tangible objective which can be achieved 100%, okay, there is always some work. III.) Application feedback. It must be possible to backtrace function in a way that you can find out which real world program call this function with which parameters. IV.) For the test suite you can use reverse engineering but reverse engineering should be better done by another team. Maybe even Microsoft sourcecode can be consulted by those who built the testsuite.

YokoZarJune 4th, 2009 at 10:01 am

The problem with splitting Wine into components is that it’s very inefficient for actually getting applications working.

Most applications only use a subset of any particular component
Most applications use a little bit of many different components
Most applications only need partial (or stub) implementations of components they use

If we tried to do one DLL at a time, even with very good splitting of the labor it would be an exceptionally long time before actual real world applications started working.

If we tried splitting development based solely on particular apps, a substantial amount of time would be spent implementing hacks that make one program work but don’t implement the underlying function correctly. Do that enough and you waste time for everyone as people write wrong code to correctly handle underlying wrong code, ultimately making it take much longer to get to that tipping point where collateral damage works in your favor.

KevinJune 10th, 2009 at 4:09 am

I thought this was a fascinating thought experiment. As a Happy Wine user (except for IE 7 – but to be honest I am un-happy with the company that has locked our accounts web-app to IE only; Wine helps mitigate that) I think there is a lot of truth in what you have found.

Although I wonder if the curves are accurate? The reason I say this is you are assuming a final number of bug of 10,000. Well, Wine must have started with 0 bugs, then 1 then 100 etc. IIRC Wine started off chasing Win 16 then Win32, 95, 98, NT, NT5 etc… onto the joys of Vista and Win 7 on the horizon. I think the sliding target window might make your curve much more shallow.

I think your measurement of Happy Users vs Unhappy Users is a spot on measure!

Cheers, Kevin

PS I personally find Wine to be the most fascinating open source project out there. Mostly because of the David vs Goliath nature of the chase. And I think the head chopping moment will come faster than many think too!

YokoZarJune 10th, 2009 at 12:27 pm

Kevin, the assumption is that all those bugs were there at the start (since Wine didn’t do anything), we just didn’t get around to filing them in Bugzilla yet.

[...] the whole experience reminded me of a blog post I had written over a year ago about modeling Wine development. My model was telling me that what I had just done was a bit inefficient: I made a modest [...]

[...] the whole experience reminded me of a blog pos&#116&#32&#73 had written over a year ago about modeling Wine d&#101&#118&#101lopment. My model was telling me that what I had &#106&#117&#115t done was a bit inefficient: I made a [...]

Leave a comment

Your comment