The Many Faces of Wine: Realities of Open Source and Business

By: Dee-Ann LeBlanc
Wednesday, May 15, 2002 09:57:20 AM EST
URL: http://www.linuxplanet.com/linuxplanet/interviews/4202/1/

Looking For Success Stories

Open source advocates spend a lot of time trying to convince people that open source and business can actually go hand in hand. Unfortunately, the idea of giving things away while making a profit really doesn't mesh for a lot of people, and so it behooves us in the community to put our money where our mouths are and show that what we espouse can actually be done.

In my case, this involves keeping an eye out for interesting intersections between open source and the business world to study and write about. Not only does doing so create yet another way to make a living dealing with the world of open source (how's that for irony?), but it gives me a chance to help educate those who say there are no viable business opportunities in our community while helping the community to learn and perhaps be inspired by both the achievements and mistakes of our compatriots.

One area where open source and business not only merge, but actually weave in and out amongst one another, is the Wine (Wine Is Not an Emulator) project, hosted at www.winehq.org. Wine at various times has been developed in conjunction with Corel Corporation (www.corel.com), CodeWeavers (www.codeweavers.com), Lindows.com Incorporated (www.lindows.com), and TransGaming Technologies (www.transgaming.com).

Wine's History and Some Major Players

The Wine project has been around since 1993, longer than many Linux and open source proponents. It started as a way to allow Linux users to run software written for Windows 3.1, and over the years has expanded to include software for newer Windows versions, as well as more Unix flavors that run on Intel architectures. Due to the complexity of the goal and the continual moving target, Wine has a bit of a reputation as, as project member Marcus Meissner puts it, "that neverending alpha project."

Today, there is still no Wine 1.0, meaning that there is still no "final release" available for this project--and don't think for a moment that this is due to laziness: Wine boasts over 1 million lines of C code. However, the 90,000 users claimed on the Wine project's web site is a testament to how far this Windows implementation has come.

There are over 300 individuals who work or have worked on the Wine project, so I'll leave it to the Who's Who listing on the Wine web site (www.winehq.org) to make sure that everyone gets their due credit. However, in any large endeavor there are key players who coordinate development, or have the capacity to make particularly important contributions along the way.

Major players in the Wine project include both volunteers and company employees. Some of the original volunteers now work for some of the companies, but from my understanding, some of the major volunteers are: Uwe Bonnes, Marcus Meissner, Andreas Mohr, Dmitrie O Paun, Eric Pouech, John Sheets, and Martin Wilck. Amongst those who contribute to the Wine project as part of their work (and were likely Wine volunteers before being paid for it) are CodeWeavers' Huw Davies, François Gouget, Alexandre Julliard, Dmitry Timoshkov, and Jeremy White. In TransGaming Technologies the major Wine contributor is Ove Kaaven, and from Lindows.com Michael Cardenas has done his part.

Of course, we're not here just to honor a list of names, as much as we all might like Wine and find it really useful. Let's take a look at how this bevy of commercial and volunteer interests interacts.

How it All Comes Together

The Wine project and its related commercial interests weave together in interesting ways. When the folks at Corel threw their energies into getting their various office suite and graphics programs to run under Linux, they created somewhat of a Wine subfork at the time. The term "subfork" is applicable because it wasn't really a fork. Corel simply would freeze Wine into a particular version and not update it as often as the main tree was updated, and then apply their own changes as they made additions. Much of the Corel alternations to Wine made it back into the main Wine source over time.

With Corel's interest in Linux having waned to non-existence these days, their involvement with the Wine project has faded as well. However, their legacy lives on, as project volunteer Marcus Meissner points out that Corel ultimately gave two major gifts to the Wine project: their assistance brought new energy to the flagging interest in Wine and corporate interest showed that the Wine project had commercial as well as hobby value.

Today's major corporate contributor to the Wine project is CodeWeavers (a unanimous agreement amongst the project members I interviewed). CodeWeavers currently employs many long-time Wine volunteers, including the project head Alexandre Julliard; a factor which many see as a key to allowing these folks to spend a good amount of time working on Wine--even if some of that time ends up being used to build proprietary add-ons for CodeWeavers products.

Here we have one of the sticking points between open source and commercial vendors. Ultimately, a seller must have something unique to offer its clients or people aren't going to bother to purchase their product. Since CodeWeavers' offerings are specifically tied to making various Windows programs work under Linux, there are times when CodeWeavers has to make awkward decisions. According to CEO and Founder Jeremy White, sometimes they're in a sticky situation where announcing a new feature for Wine before announcing it for their own software could pull the wind out of their product sales.

Another problem comes down to just how much code can a commercial company afford to release into the Wine wilds. CodeWeavers in no way claims to release all of their code back into the main Wine stream. The biggest proprietary piece of code CodeWeavers has, according to White, is, in his own words: "With CrossOver Plugin, we have a Netscape plugin program. That plugin translates between the Netscape/Linux world and the Wine/Windows world, making it possible to use Windows plugins on Linux." Notice that here, the proprietary code is not actually considered to be part of Wine. It's an intermediary bit between Wine and Netscape.

However, the core of CodeWeavers' CrossOver Office is under the LGPL and included in the main Wine code stream. This brings us to the ubiquitous question asked by many new to open source: how can CodeWeavers make money if most of their code is publicly available?

White admits that being a free software-based company involves making a lot more sacrifices than one that writes only proprietary software. CodeWeavers has to "share the limelight" with the main Wine project and risk competitors having far too much fun with their own code.

The tradeoff, according to White, is that by making those sacrifices you gain other advantages. He sites having a healthy Wine community with "a legion of great testers and developers" as being key to his company's being able to produce such a focused, highly technical product with a relatively small staff, and therefore smaller overhead than a fully proprietary company would require. White also feels that "a healthy and vibrant Wine also helps to spread the message that what we do is possible," and that as people are drawn to the Wine project, they also tend to learn about CodeWeavers and the products they offer. Most small companies just can't afford the kind of marketing campaign that would require.

Open source proponents also like to point out that the money is often in the service side of things, and White also mentions this aspect: "By being seen as 'the Wine company,' we hopefully insure that businesses that are looking for a company to back them up in their use of Wine come and find us, and pay for our products and services." He adds that of course CodeWeavers isn't trying to be the only company making use of Wine. Just the best one!

White's summary of why CodeWeavers is still around today, and still part of Wine and open source, is: "As I see it, a successful Free software company makes a straightforward bargain: it gives up proprietary control, and stays a smaller, more tightly focused, less well funded company. In exchange, it gets to use the effective power of a much large QA/development and marketing staff than it could otherwise afford."

Some of the CodeWeavers code that doesn't go into Wine is actually not held back by CodeWeavers. While Wine's project head only accepts the best code--as one would hope--sometimes ugly workarounds are required for a company to ensure that all of their customers are able to use their software. So, for example, White himself tells of a horrible bit of code he wrote that enables CrossOver to work with the X Window System 4.1.0 despite a bug that otherwise requires users to upgrade their X version before they can use Wine.

Programmers who saw the code might think it's horrible (and White says they'd be right), but he offered this as another example of how companies working in tandem with open source projects can provide added value. No matter what a CodeWeavers customer is running, the company will do what's necessary to make that software work.

CodeWeavers also provides the web and CVS space that the Wine project uses, an important contribution to any open source effort.

There are other companies that, while they haven't released their code yet for public consumption, have benefited the Wine project in other ways. Lindows.com, for example, states that they will open source their code once their product is finally released, so obviously none of their code has gone back into Wine yet--and industry observers are waiting to see which license the Lindows.com code will be released under.

However, one major contribution Lindows.com has already delivered is that they helped to put on the first Wine developer's conference in 2002, by both hosting it and paying travel expenses for many major Wine developers.

How Sometimes It Doesn't Come Together

Not all is roses and perfume in the Wine project, however, any more than it is behind proprietary closed doors. TransGaming Technologies got themselves into a bit of a bind with other members of the Wine community by withholding both the initial code that made the Windows InstallShield program run properly with Wine and the DirectX components. The problem here is that Wine moved from the X11 licensing scheme to the LGPL, which is more restrictive.

While it's easy to get mad at the company for this, let's look at some of the issues. TransGaming's WineX is designed to work properly with the copy protection that comes built into the games it supports. This means that their code must know how to interact with the game's copy protection scheme, and it means that if they release that code to the public, they're basically handing out a free ticket for everyone to copy and play the game without buying it. Not only is this unethical but it's a violation of the US Digital Millennium Copyright Act (DMCA), which could get key members of the company thrown into prison.

TransGaming's reluctance in becoming a legal test cases is certainly understandable, especially since the first test case is still underway and there haven't been even any small victory parties yet. There are other, smaller issues that most would consider more open for debate. The LGPL, according to Gavriel State, the TransGaming Technologies CEO and CTO, "would also lock TransGaming into the long-term support of Wine even in a situation where our subscription objectives are not fulfilled."

TransGaming is now supporting an effort to take most of the Wine code and place it back under the X11 license, making a new project called ReWind (http://rewind.sourceforge.net/). While TransGaming and CodeWeavers don't see eye to eye on this issue and so are not participating in both trees, many Wine developers are offering their additions to Wine (since it moved to the LGPL) to be made available under the X11 license as well.

How this situation will shake out, only time will tell. Developers and managers interested in all of the details and discussions, can find more information at the WineHQ site and others in a column by State on the TransGaming site.

CodeWeavers' Jeremy White's reflections on the issue come as a set of advice to other open source projects, whether commercial entities are involved or not:

• "Have a well understood process for making project wide changes
• "Have a moderated discussion list where only project contributors are permitted to post (with, of course, a parallel open discussion list)."

White's concern is that the people who added the most heat and flames to the discussion were in fact folks who had never contributed to the Wine project and that in fact all of the vitriol may have prevented better discussion from occurring in the end. If this is the case, then perhaps there is indeed hope that everyone involved can come to some kind of agreement.

Where it's All Going

While it's important to learn lessons from the past and present, it's also instructive to look to the future. On the CodeWeavers front, they're going to release a major update with bug fixes for one of their products in the next week, including a vast improvement in non-English support.

For the Wine project itself, within a year they hope to finally reach version 1.0. The conference sponsored by Lindows.com helped by letting the developers talk face to face and set the specifications for the first official release, and as developer Eric Pouech points out, "with lots of bug reports to handle." With the 1.0 release project, members hope that companies that need Linux and Windows to work together will begin deploying Wine.

Within five years--always a shaky prediction--the hope is that Wine will be at least somewhat integrated into the Linux kernel and a solid part of the Unix desktop experience. How will they get there? In part by doing what they've always done: working at it to make more and more Windows applications run properly under Wine and Linux.

Pouech feels that more targeted efforts might be required with such a broad goal. Since most of the biggest contributors are somehow involved in commercial efforts this could create complications, since obviously the companies involved are going to work on the features that they most require at the moment. However, perhaps those folks who are purely volunteers can step in to fill the gaps.

He also feels that non-regression and performance metric testing are both needed so the project can determine code quality and robustness faster, but says that writing tests is the type of work that most developers really don't want to deal with. So if your thing is writing tests, the Wine project could certainly use your efforts!

Other items identified as needing to be done to bring Wine to the 1.0 stage include making the entire Wine experience more user friendly. A simple installation tool and more complete suite of documentation would go far toward achieving this goal, and for the business and educational crowds that need to install in a distributed environment, a suit of monitoring and other tools are required.

The Wine project has been around almost as long as Linux has, and the fact that it's still going at all is a testament to how determined open source developers can be. With hopefully under a year left before Wine 1.0 is finally released, the exhausted marathon runners behind the code a very likely focused on the finish line and quite ready to throw their arms up as they break the finishing ribbon together.

Hopefully at that same time there will still be useful exchanges between Wine and the commercial software industry. If nothing else, the Wine Project and its many commercial cousins have shown that open source and feeding one's family really can mix.