One may use WINE to either create a native GNU/Linux executable, linked against winelib, or to execute a Windows-native executable. Google chose the latter (emphasis added):
Many people assume that when porting a Windows app to Linuxusing Wine, the best thing to do is link Winelib into theapplication to create a native Linux application. Not so!It’s just as effective, and a heck of a lot easier, to runthe same binary on both Windows and Wine. So that’s what thePicasa team did. Picasa for Linux uses slightly differenttext messages, but the .exe file is identical for both Windowsand Linux.
On the subject of packaging, we continue to see the profound effects of Loki’s free software efforts (emphasis added):
One interesting challenge when shipping commercial apps forLinux is packaging — do you choose RPM or Debian packages,or do you use a WIndows-style installer? The Picasa forLinux team chose all three, in hopes of pleasing everybody.(Let’s see how well *that* works :-) The Windows-styleinstaller was implemented using the open-source Loki installer,and a few patches were contributed back for that, too.
That’s the news. The rest is my opinion.
I’m a fan of Google but I am disappointed that they’ve chosen to go with this form of GNU/Linux support. WINE proponents will say that this is a necessary first step toward native support, and they could be right. However, with the momentum going in this direction, I would argue it will be more difficult to change direction to GNU/Linux-native in the future. Resources that could have been invested in a GTK+ or Qt port of the product are already invested in the WINE code.
Worse, however, is the example that this sets. Any company researching a GNU/Linux port of an application or a game will see what Google did and some will follow the Google example. Is that the long-term solution we really want?